Make PageLoadMetricsWaiter more resilient

Make PageLoadMetricsWaiter more resilient

Our current test infrastructure exposes timing update callbacks at a layer just
above the IPC processing layer, in MetricsWebContentsObserver via the
TestingObserver interface.

This works fine when timing updates are dispatched synchronously to
PageLoadMetricsObservers as part of the IPC processing flow.

However, this strategy no longer works if updates are buffered before
being dispatched. We may buffer updates in the browser process to allow
for correct processing of out of order inter frame timing updates. This would
require observing callbacks at a higher level than the MWCO timing update
processing flow.

The simplest way to address this is to allow the test infrastructure
to inject a PageLoadMetricsObserver that can be used to wait for timing
updates. This guarantees that our waiting logic is waiting on the same logic
as other observers, which makes the tests more resilient.

In addition, we can restrict waiting to a single page load - there have been
some subtle browsertest bugs in the past where waiters waiting on a timing
from one page load incorrectly stopped waiting too early because a
previous page load dispatched a matching timing update. By observing
at the PLMO level, and only starting waiting once a load commits, we have a
page load level view of updates and can more precisely guarantee we are
waiting on the right page load's updates.

BUG=725998
NOTRY=true
NOPRESUBMIT=true
TBR=csharrison

Review-Url: https://codereview.chromium.org/2903693004
Cr-Original-Commit-Position: refs/heads/master@{#474996}
Review-Url: https://codereview.chromium.org/2911983002
Cr-Commit-Position: refs/branch-heads/3112@{#21}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
Committed: https://chromium.googlesource.com/chromium/src/+/c2ee5a4fd342deb46068e5eb31fc9023e799c4bc

[Bryan McQuade, 2017-05-30 01:23:12]

Description was changed from

==========
Make PageLoadMetricsWaiter more resilient

Our current test infrastructure exposes timing update callbacks at a layer just
above the IPC processing layer, in MetricsWebContentsObserver via the
TestingObserver interface.

This works fine when timing updates are dispatched synchronously to
PageLoadMetricsObservers as part of the IPC processing flow.

However, this strategy no longer works if updates are buffered before
being dispatched. We may buffer updates in the browser process to allow
for correct processing of out of order inter frame timing updates. This would
require observing callbacks at a higher level than the MWCO timing update
processing flow.

The simplest way to address this is to allow the test infrastructure
to inject a PageLoadMetricsObserver that can be used to wait for timing
updates. This guarantees that our waiting logic is waiting on the same logic
as other observers, which makes the tests more resilient.

In addition, we can restrict waiting to a single page load - there have been
some subtle browsertest bugs in the past where waiters waiting on a timing
from one page load incorrectly stopped waiting too early because a
previous page load dispatched a matching timing update. By observing
at the PLMO level, and only starting waiting once a load commits, we have a
page load level view of updates and can more precisely guarantee we are
waiting on the right page load's updates.

BUG=725998

Review-Url: https://codereview.chromium.org/2903693004
Cr-Commit-Position: refs/heads/master@{#474996}
(cherry picked from commit ab243857c7a70b2c42c521896c588f01ac2eae46)
==========

to

==========
Make PageLoadMetricsWaiter more resilient

Our current test infrastructure exposes timing update callbacks at a layer just
above the IPC processing layer, in MetricsWebContentsObserver via the
TestingObserver interface.

This works fine when timing updates are dispatched synchronously to
PageLoadMetricsObservers as part of the IPC processing flow.

However, this strategy no longer works if updates are buffered before
being dispatched. We may buffer updates in the browser process to allow
for correct processing of out of order inter frame timing updates. This would
require observing callbacks at a higher level than the MWCO timing update
processing flow.

The simplest way to address this is to allow the test infrastructure
to inject a PageLoadMetricsObserver that can be used to wait for timing
updates. This guarantees that our waiting logic is waiting on the same logic
as other observers, which makes the tests more resilient.

In addition, we can restrict waiting to a single page load - there have been
some subtle browsertest bugs in the past where waiters waiting on a timing
from one page load incorrectly stopped waiting too early because a
previous page load dispatched a matching timing update. By observing
at the PLMO level, and only starting waiting once a load commits, we have a
page load level view of updates and can more precisely guarantee we are
waiting on the right page load's updates.

BUG=725998
NOTRY=true
NOPRESUBMIT=true
TBR=csharrison

Review-Url: https://codereview.chromium.org/2903693004
Cr-Commit-Position: refs/heads/master@{#474996}
(cherry picked from commit ab243857c7a70b2c42c521896c588f01ac2eae46)
==========

[Bryan McQuade, 2017-05-30 01:23:47]

The CQ bit was checked by bmcquade@chromium.org

[commit-bot: I haz the power, 2017-05-30 01:23:58]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-30 01:24:21]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1496107427388650, "parent_rev":
"acf6afccbfe8fc0ddb9a616a6286f336e0204761", "commit_rev":
"c2ee5a4fd342deb46068e5eb31fc9023e799c4bc"}

[commit-bot: I haz the power, 2017-05-30 01:24:30]

Description was changed from

==========
Make PageLoadMetricsWaiter more resilient

Our current test infrastructure exposes timing update callbacks at a layer just
above the IPC processing layer, in MetricsWebContentsObserver via the
TestingObserver interface.

This works fine when timing updates are dispatched synchronously to
PageLoadMetricsObservers as part of the IPC processing flow.

However, this strategy no longer works if updates are buffered before
being dispatched. We may buffer updates in the browser process to allow
for correct processing of out of order inter frame timing updates. This would
require observing callbacks at a higher level than the MWCO timing update
processing flow.

The simplest way to address this is to allow the test infrastructure
to inject a PageLoadMetricsObserver that can be used to wait for timing
updates. This guarantees that our waiting logic is waiting on the same logic
as other observers, which makes the tests more resilient.

In addition, we can restrict waiting to a single page load - there have been
some subtle browsertest bugs in the past where waiters waiting on a timing
from one page load incorrectly stopped waiting too early because a
previous page load dispatched a matching timing update. By observing
at the PLMO level, and only starting waiting once a load commits, we have a
page load level view of updates and can more precisely guarantee we are
waiting on the right page load's updates.

BUG=725998
NOTRY=true
NOPRESUBMIT=true
TBR=csharrison

Review-Url: https://codereview.chromium.org/2903693004
Cr-Commit-Position: refs/heads/master@{#474996}
(cherry picked from commit ab243857c7a70b2c42c521896c588f01ac2eae46)
==========

to

==========
Make PageLoadMetricsWaiter more resilient

Our current test infrastructure exposes timing update callbacks at a layer just
above the IPC processing layer, in MetricsWebContentsObserver via the
TestingObserver interface.

This works fine when timing updates are dispatched synchronously to
PageLoadMetricsObservers as part of the IPC processing flow.

However, this strategy no longer works if updates are buffered before
being dispatched. We may buffer updates in the browser process to allow
for correct processing of out of order inter frame timing updates. This would
require observing callbacks at a higher level than the MWCO timing update
processing flow.

The simplest way to address this is to allow the test infrastructure
to inject a PageLoadMetricsObserver that can be used to wait for timing
updates. This guarantees that our waiting logic is waiting on the same logic
as other observers, which makes the tests more resilient.

In addition, we can restrict waiting to a single page load - there have been
some subtle browsertest bugs in the past where waiters waiting on a timing
from one page load incorrectly stopped waiting too early because a
previous page load dispatched a matching timing update. By observing
at the PLMO level, and only starting waiting once a load commits, we have a
page load level view of updates and can more precisely guarantee we are
waiting on the right page load's updates.

BUG=725998
NOTRY=true
NOPRESUBMIT=true
TBR=csharrison

Review-Url: https://codereview.chromium.org/2903693004
Cr-Original-Commit-Position: refs/heads/master@{#474996}
Review-Url: https://codereview.chromium.org/2911983002
Cr-Commit-Position: refs/branch-heads/3112@{#21}
Cr-Branched-From:
b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
Committed:
https://chromium.googlesource.com/chromium/src/+/c2ee5a4fd342deb46068e5eb31fc...
==========

[commit-bot: I haz the power, 2017-05-30 01:24:31]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/c2ee5a4fd342deb46068e5eb31fc...