The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e7688b584abb5808ec3c1390c40380b4a35225ae

commit e7688b584abb5808ec3c1390c40380b4a35225ae
Author: Xida Chen <xidachen@chromium.org>
Date: Thu Jan 04 18:46:13 2018

Mark test_resource_timing.html fail on Mac

TBR=skyostil@chromium.org
NOTRY=true

Bug:  799127 
Change-Id: Ib5e99e16a5f49eea7e51fa34b9f901c9c143df76
Reviewed-on: https://chromium-review.googlesource.com/850541
Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527047}
[modify] https://crrev.com/e7688b584abb5808ec3c1390c40380b4a35225ae/third_party/WebKit/LayoutTests/TestExpectations

This also seems related:
https://ci.chromium.org/buildbot/chromium.mac/Mac10.10%20Tests/27741

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eb0c49746e7222bd8dd9d472cd2f1644987ab4e8

commit eb0c49746e7222bd8dd9d472cd2f1644987ab4e8
Author: Xida Chen <xidachen@chromium.org>
Date: Thu Jan 04 20:25:26 2018

Mark Event-timestamp-high-resolution.html failure on Mac

TBR=skyostil@chromium.org
NOTRY=true

Bug:  799127 
Change-Id: Ic432554bdc50e3e2b438fc78115d939c96fa0e08
Reviewed-on: https://chromium-review.googlesource.com/851156
Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527081}
[modify] https://crrev.com/eb0c49746e7222bd8dd9d472cd2f1644987ab4e8/third_party/WebKit/LayoutTests/TestExpectations

This test just flaked inside site_per_process_webkit_layout_tests on linux_chromium_rel_ng:

https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/617751

Per layout test results:
https://storage.googleapis.com/chromium-layout-test-archives/linux_chromium_rel_ng/617751/site_per_process_webkit_layout_tests%20%28with%20patch%29/layout-test-results/external/wpt/resource-timing/test_resource_timing-actual.txt

PASS PerformanceEntry has correct order of timing attributes (img)
PASS PerformanceEntry has correct network transfer attributes (img)
PASS PerformanceEntry has correct protocol attribute (img)
PASS window.performance.getEntriesByName() and window.performance.getEntriesByNameType() return same data (link)
PASS PerformanceEntry has correct name, initiatorType, startTime, and duration (link)
FAIL PerformanceEntry has correct order of timing attributes (link) assert_greater_than_equal: connectEnd after connectStart expected a number greater than or equal to 63.40000000272994 but got 63.39999999909196
PASS PerformanceEntry has correct network transfer attributes (link)
PASS PerformanceEntry has correct protocol attribute (link)
PASS window.performance.getEntriesByName() and window.performance.getEntriesByNameType() return same data (script)
PASS PerformanceEntry has correct name, initiatorType, startTime, and duration (script)
FAIL PerformanceEntry has correct order of timing attributes (script) assert_greater_than_equal: requestStart after connectEnd expected a number greater than or equal to 64.10000000323635 but got 64.09999999959837
PASS PerformanceEntry has correct network transfer attributes (script)

This needs to be fixed, or the test disabled. Another failure, in site_per_process_webkit_layout_tests:

https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/622456

from unrelated CL:

https://chromium-review.googlesource.com/861257

Notifying sheriffs.

Happened again:
https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/623853

Marking the following failing on Linux too:
external/wpt/resource-timing/test_resource_timing.html

Marking the following failing on Linux and Mac:
external/wpt/service-workers/service-worker/navigation-preload/resource-timing.https.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cef716067a84bb7f36bff44c6d0361995c384439

commit cef716067a84bb7f36bff44c6d0361995c384439
Author: Kenneth Russell <kbr@chromium.org>
Date: Sat Jan 13 04:59:01 2018

Marking two flaky resource timing tests failing on both Mac and Linux.

external/wpt/resource-timing/test_resource_timing.html
external/wpt/service-workers/service-worker/navigation-preload/
    resource-timing.https.html

TBR=skyostil@chromium.org

Bug:  799127 
Change-Id: Ic33582def383537ee74cea4953de3053c110b2c0
Reviewed-on: https://chromium-review.googlesource.com/865573
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529161}
[modify] https://crrev.com/cef716067a84bb7f36bff44c6d0361995c384439/third_party/WebKit/LayoutTests/TestExpectations

Removing the label since an owner looks assigned.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/874bac6e00e5b0b5fe291cc51518e5fd1e83c69d

commit 874bac6e00e5b0b5fe291cc51518e5fd1e83c69d
Author: Sami Kyostila <skyostil@chromium.org>
Date: Tue Jan 16 12:23:57 2018

Ensure clamped time always moves forward

This patch fixes a problem where performance.now or Date.now can in rare cases
move slightly backwards due to a loss of arithmetic precision.

BUG= 801341 , 799127 ,798964

Change-Id: I3618933e9697319bb0c2ffb1e7917078d418b488
Reviewed-on: https://chromium-review.googlesource.com/867062
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529407}
[modify] https://crrev.com/874bac6e00e5b0b5fe291cc51518e5fd1e83c69d/gin/v8_platform.cc
[modify] https://crrev.com/874bac6e00e5b0b5fe291cc51518e5fd1e83c69d/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/874bac6e00e5b0b5fe291cc51518e5fd1e83c69d/third_party/WebKit/Source/platform/TimeClamper.cpp
[modify] https://crrev.com/874bac6e00e5b0b5fe291cc51518e5fd1e83c69d/third_party/WebKit/Source/platform/TimeClamperTest.cpp

Test looks happy now:

https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=webkit_layout_tests&tests=test_resource_timing.html

Requesting a merge to M64 as https://crrev.com/a77687fd89adc1bc2ce91921456e0b9b59388120 introduced this regression to M64 too.

This bug requires manual review: We are only 5 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We're already a week away from M64, and there are no Beta's remaining. Can you please comment on why this bug is critical, how safe this is, and why we need it for M64 vs waiting until M65?

Fair point. This fix is safe, but the issue should only really be hit by synthetic test cases like layout tests. The main reason for backporting would be that https://crrev.com/a77687fd89adc1bc2ce91921456e0b9b59388120 was also fast-tracked to M64 for Spectre and ideally this fix should go in together with that. Given the short deadline and the low severity, let's not backport this one.

Per comment #16, rejecting merge.

This behavior may also be the cause of issues with Inbox (b/72049267). If so then we should reconsider merging to M-64.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/82e59a071fab3d257d2ffba88e565354a5d980cd

commit 82e59a071fab3d257d2ffba88e565354a5d980cd
Author: Matt Falkenhagen <falken@chromium.org>
Date: Tue Jan 23 07:44:45 2018

NetworkService: Gardening: Some service worker tests are passing.

- resource-timing.https.html is flaky but due to a different issue
- The other tests are passing in NetworkService locally. I'm not sure
if they pass all the time because Flakiness Dashboard isn't working
for NetworkService LayoutTests, so if they fail again just readd
them.

TBR=kinuko@chromium.org

Bug:  804682 , 799127 , 715640 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I28af3819788364fc08194dfa87cd550fcc5f967e
Reviewed-on: https://chromium-review.googlesource.com/880249
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531175}
[modify] https://crrev.com/82e59a071fab3d257d2ffba88e565354a5d980cd/third_party/WebKit/LayoutTests/FlagExpectations/enable-features=NetworkService
[modify] https://crrev.com/82e59a071fab3d257d2ffba88e565354a5d980cd/third_party/WebKit/LayoutTests/TestExpectations

Given b/72049267 I think we should merge this to M64.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this only Linux / Mac?  If we have a bad timer, couldn't that affect all platforms in different ways?

Approved for M64 branch 3282.

I will merge c#11, https://chromium.googlesource.com/chromium/src.git/+/874bac6e00e5b0b5fe291cc51518e5fd1e83c69d, to 3282. It looks like this is the only code change commit in the bug. Let me know ASAP if there are other commits that need to be merged.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/50e671d0abbcaa3b4013a229c9759b33c77daf25

commit 50e671d0abbcaa3b4013a229c9759b33c77daf25
Author: Matt Falkenhagen <falken@chromium.org>
Date: Wed Jan 24 02:15:37 2018

M64: Ensure clamped time always moves forward

This patch fixes a problem where performance.now or Date.now can in rare cases
move slightly backwards due to a loss of arithmetic precision.

BUG= 801341 , 799127 ,798964
TBR=skyostil@chromium.org

(cherry picked from commit 874bac6e00e5b0b5fe291cc51518e5fd1e83c69d)

Change-Id: I3618933e9697319bb0c2ffb1e7917078d418b488
Reviewed-on: https://chromium-review.googlesource.com/867062
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#529407}
Reviewed-on: https://chromium-review.googlesource.com/882783
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#588}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/50e671d0abbcaa3b4013a229c9759b33c77daf25/gin/v8_platform.cc
[modify] https://crrev.com/50e671d0abbcaa3b4013a229c9759b33c77daf25/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/50e671d0abbcaa3b4013a229c9759b33c77daf25/third_party/WebKit/Source/platform/TimeClamper.cpp
[modify] https://crrev.com/50e671d0abbcaa3b4013a229c9759b33c77daf25/third_party/WebKit/Source/platform/TimeClamperTest.cpp

Thank you Matt!

Is cl listed at #19 need to be merged to M65? If yes, pls request a merge. Thank you.

c#27: np (actually I was asked to do the merge since I was around :))
c#28: No, #19 is just a test expectations update. It has no effect on the Chrome binary.

Had an offline chat with Sami (skyostil@) and confirmed that the above merge is working fine on Latest M64 Beta/Stable RC#64.0.3282.119.

Sami, thank you so much for the quick help!

@skyostil & xidachen,  
We need to verify the fix on ChromeOS/M64.  Could you provide verification steps or verify the fix on latest M64 (10176.61.0/64.0.3282.122)  
thanks,

@songsuk: this is a test that doesn't run on any chrome os bots.

@skyostil: can we safely assume that it should be fixed on chrome os, given that the fix has been verified on other platforms.

I don't think we need Chrome OS specific verification here. In any case, here's how I tested it:

1. Go to https://inbox.google.com and sign in with an account that has a bunch of email.
2. Navigate around the UI, opening and collapsing messages.

Before the fix this would eventually make the page stop responding to clicks.

@skyostil & @xidachen,
Thank you so much for your help.   

Unable to reproduce the issue,comment#35, on chrome 64.0.3282.122/10176.61.0 (Kip/Reks), 10176.62.0/64.0.3282.132(Eve). Inbox works fine without the UI issue. 

Just to provide my observations, Tested this issue across all OS platforms using chrome latest stable #64.0.3282.119 and also on #64.0.3282.100 ie. before fix has landed on latest M64 by following the steps mentioned in comment #35 but no luck in reproducing it.

Thanks!