Closed Bug 1387894 Opened 8 years ago Closed 6 years ago

Intermittent /dom/events/Event-timestamp-high-resolution.html | Constructed (FocusEvent|GamepadEvent|WheelEvent) timestamp should be high resolution and have the same time origin as performance.now()

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla70
Tracking Flags:
Tracking Status
firefox70 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: tjr)

References

Details

(Keywords: intermittent-failure, Whiteboard: [wptsync upstream][stockwell unknown])

Attachments

(8 files, 2 obsolete files)

Bug 1387894 - Resolve timer intermittents when reduceTimerPrecision is disabled
47 bytes, text/x-phabricator-request
Details | Review
Bug 1387894, 1476950 - Fix test_restyles.html for unconditional clamping
47 bytes, text/x-phabricator-request
Details | Review
Bug 1387894 - Fix browser_animation_setCurrentTime.js for unconditional clamping
47 bytes, text/x-phabricator-request
Details | Review
Bug 1387894 - Fix animation WPTs
47 bytes, text/x-phabricator-request
Details | Review
Bug 1387894 - Remove expected failure from Event-timestamp-safe-resolution.html
47 bytes, text/x-phabricator-request
Details | Review
Bug 1387894 - Disable unconditional clamping for two CSS tests
47 bytes, text/x-phabricator-request
Details | Review
Bug 1387894 - Move all Resist Fingerprinting/Reduce Time Precision prefs to StaticPrefs
47 bytes, text/x-phabricator-request
Details | Review
Bug 1387894 - Avoid Double-Reducing Performance Duration objects r?baku
47 bytes, text/x-phabricator-request
Details | Review
Summary: Intermittent /dom/events/Event-timestamp-high-resolution.html | Constructed FocusEvent timestamp should be high resolution and have the same time origin as performance.now() - assert_less_than_equal: Event timestamp should be less than performance.now() t → Intermittent /dom/events/Event-timestamp-high-resolution.html | Constructed (FocusEvent|GamepadEvent|WheelEvent) timestamp should be high resolution and have the same time origin as performance.now()
See Also: → 1427918
Component: web-platform-tests → DOM: Events
Product: Testing → Core
Version: Version 3 → Trunk
In the last 7 days, there have been 32 failures. All of the failures are on osx-10-10 platform, debug type. An example of a recent log file: https://treeherder.mozilla.org/logviewer.html#?job_id=205158637&repo=autoland&lineNumber=5105 And the relevant part of the log: 13:50:23 INFO - TEST-PASS | /dom/events/Event-timestamp-high-resolution.html | Constructed GamepadEvent timestamp should be high resolution and have the same time origin as performance.now() 13:50:23 INFO - TEST-UNEXPECTED-FAIL | /dom/events/Event-timestamp-high-resolution.html | Constructed FocusEvent timestamp should be high resolution and have the same time origin as performance.now() - assert_less_than_equal: Event timestamp should be less than performance.now() timestamp taken after its creation expected a number less than or equal to 393.14 but got 393.14085 13:50:23 INFO - @http://web-platform.test:8000/dom/events/Event-timestamp-high-resolution.html:13:9 13:50:23 INFO - Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1561:20 13:50:23 INFO - test@http://web-platform.test:8000/resources/testharness.js:544:21 13:50:23 INFO - @http://web-platform.test:8000/dom/events/Event-timestamp-high-resolution.html:8:5 :overholt As you are the triage owner of this component, could you please take a look at this? Thank you!
Flags: needinfo?(overholt)
Whiteboard: [stockwell needswork]
(In reply to Cristina Coroiu [:ccoroiu] from comment #65) > 13:50:23 INFO - TEST-UNEXPECTED-FAIL | > /dom/events/Event-timestamp-high-resolution.html | Constructed FocusEvent > timestamp should be high resolution and have the same time origin as > performance.now() - assert_less_than_equal: Event timestamp should be less > than performance.now() timestamp taken after its creation expected a number > less than or equal to 393.14 but got 393.14085 I'm willing to bet at least CAD1 that this is due to the throttling we did for Spectre mitigation. Tom, what do you think?
Flags: needinfo?(overholt) → needinfo?(tom)
(In reply to Andrew Overholt [:overholt] from comment #67) > (In reply to Cristina Coroiu [:ccoroiu] from comment #65) > > 13:50:23 INFO - TEST-UNEXPECTED-FAIL | > > /dom/events/Event-timestamp-high-resolution.html | Constructed FocusEvent > > timestamp should be high resolution and have the same time origin as > > performance.now() - assert_less_than_equal: Event timestamp should be less > > than performance.now() timestamp taken after its creation expected a number > > less than or equal to 393.14 but got 393.14085 > > I'm willing to bet at least CAD1 that this is due to the throttling we did > for Spectre mitigation. Tom, what do you think? https://searchfox.org/mozilla-central/source/testing/web-platform/meta/dom/events/__dir__.ini#1 I think you owe me 77 cents. ;) Actually, what I think is happening is the event timestamp is super high res, and we unconditionally perform 20ns clamping of performance.now(): https://searchfox.org/mozilla-central/source/dom/performance/Performance.cpp#105 *Almost* everything goes through nsRFPService::ReduceTimePrecision (and the things that don't are ns resolution) so maybe what we should do is have that function unconditionally clamp to 20ns so everything gets that behavior/safety net. But this might make new intermittents which we are less used to, so maybe it should be done after branching?
Flags: needinfo?(tom)
(In reply to Tom Ritter [:tjr] from comment #68) > (In reply to Andrew Overholt [:overholt] from comment #67) > > (In reply to Cristina Coroiu [:ccoroiu] from comment #65) > > > 13:50:23 INFO - TEST-UNEXPECTED-FAIL | > > > /dom/events/Event-timestamp-high-resolution.html | Constructed FocusEvent > > > timestamp should be high resolution and have the same time origin as > > > performance.now() - assert_less_than_equal: Event timestamp should be less > > > than performance.now() timestamp taken after its creation expected a number > > > less than or equal to 393.14 but got 393.14085 > > > > I'm willing to bet at least CAD1 that this is due to the throttling we did > > for Spectre mitigation. Tom, what do you think? > > https://searchfox.org/mozilla-central/source/testing/web-platform/meta/dom/ > events/__dir__.ini#1 > > I think you owe me 77 cents. ;) Ha! I will happily pay up when we're next in the same place :) > Actually, what I think is happening is the event timestamp is super high > res, and we unconditionally perform 20ns clamping of performance.now(): > https://searchfox.org/mozilla-central/source/dom/performance/Performance. > cpp#105 Ah. > *Almost* everything goes through nsRFPService::ReduceTimePrecision (and the > things that don't are ns resolution) so maybe what we should do is have that > function unconditionally clamp to 20ns so everything gets that > behavior/safety net. > > But this might make new intermittents which we are less used to, so maybe it > should be done after branching? Probably. I was mentioning this situation to Olli who said he wanted to check it out later so I'll just needinfo him here.
Flags: needinfo?(bugs)
(In reply to Tom Ritter [:tjr] from comment #68) > and the things that don't are ns resolution) Typo: I meant to say they *aren't* ns resolution.
(In reply to Tom Ritter [:tjr] from comment #68) > > Actually, what I think is happening is the event timestamp is super high > res, and we unconditionally perform 20ns clamping of performance.now(): > https://searchfox.org/mozilla-central/source/dom/performance/Performance. > cpp#105 Yeah, that is bug in Performance. We shouldn't unconditionally clamp (we don't clamp for chrome code. Very of inconsistency).
Component: DOM: Events → DOM
Flags: needinfo?(bugs)
(In reply to Olli Pettay [:smaug] from comment #71) > (In reply to Tom Ritter [:tjr] from comment #68) > > > > Actually, what I think is happening is the event timestamp is super high > > res, and we unconditionally perform 20ns clamping of performance.now(): > > https://searchfox.org/mozilla-central/source/dom/performance/Performance. > > cpp#105 > Yeah, that is bug in Performance. We shouldn't unconditionally clamp (we > don't clamp for chrome code. Very of inconsistency). On the contrary: the spec recommends clamping (unconditionally): https://www.w3.org/TR/hr-time/#clock-resolution The previous agreed-upon plan was "performance.now() gets clamped to 5us, and everything else is not-our-problem-right-now." Post-Spectre every browser went a different way: 20us, 100us, 1ms and nothing could be agreed upon in the spec. Partly because the old style had established the precedent of "everything else was not-our-problem-right-now" and partly because no one made a POC demonstrating Spectre attacks without performance.now(): other browsers inconsistently clamp (and jitter) time sources focusing only on performance.now() and leaving other high resolution timers active. Firefox applied Spectre timing mitigations consistently; clamping (and jittering) all time sources. This test is intermittent because we disable our consistent clamping+jittering leaving only the old (inconsistent) style. But the intention of the old style was clear: don't expose too high resolution of a timer to the web platform. It just never got applied to anything except performance.now() because no one went around to clean up all the other places the information was exposed.
Ok, then this is still a regression from the bug doing the clamping in one place but not consistently everywhere.
I can take this and make Event.timestamp work like performance.now(), but in general timestamp handling is atm very error prone.
Assignee: nobody → bugs
(In reply to Olli Pettay [:smaug] from comment #74) > I can take this and make Event.timestamp work like performance.now(), but in > general timestamp handling is atm very error prone. I think the best approach is what I outlined in Comment 68; which would clean this up for all places, including Bug 1429233. I can do that easily, but I wanted to wait until after the branch.
yeah, ok, that is probably better approach than fixing this one by one.
Unsurprisingly, this caused a bunch of tests to fail. Correcting them shouldn't be too much work though. https://treeherder.mozilla.org/#/jobs?repo=try&revision=c9192015449721e5d46d499c9ee0b28557dda8c6
Priority: -- → P2
I categorized the failures here: https://docs.google.com/spreadsheets/d/18q1ePvu0-oPjkafEpXHiuFO7qMw8CYjd9i2-zd7Hh-8/edit#gid=0 Unfortunately several failures are in WPT. While I could edit the WPT to succeed and still meaningfully test things; I don't think we want to edit in-tree WPT. What's the best course of action here?
It is totally fine to edit in-tree wpt. We do that all the time. And that is the point of synchronizing wpt automatically.
Component: DOM → DOM: Core & HTML

There are 35 total failures in the last 7 days: https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?startday=2019-07-10&endday=2019-07-17&tree=trunk&bug=1387894

Recent failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=256977928&repo=mozilla-central&lineNumber=2924

[task 2019-07-17T16:49:00.871Z] 16:49:00 INFO - TEST-START | /dom/events/Event-timestamp-high-resolution.html
[task 2019-07-17T16:49:00.871Z] 16:49:00 INFO - Closing window 2147483751
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO -
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - TEST-PASS | /dom/events/Event-timestamp-high-resolution.html | Constructed MouseEvent timestamp should be high resolution and have the same time origin as performance.now()
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - TEST-PASS | /dom/events/Event-timestamp-high-resolution.html | Constructed KeyboardEvent timestamp should be high resolution and have the same time origin as performance.now()
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - TEST-PASS | /dom/events/Event-timestamp-high-resolution.html | Constructed WheelEvent timestamp should be high resolution and have the same time origin as performance.now()
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - TEST-PASS | /dom/events/Event-timestamp-high-resolution.html | Constructed GamepadEvent timestamp should be high resolution and have the same time origin as performance.now()
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - TEST-UNEXPECTED-FAIL | /dom/events/Event-timestamp-high-resolution.html | Constructed FocusEvent timestamp should be high resolution and have the same time origin as performance.now() - assert_less_than_equal: Event timestamp should be less than performance.now() timestamp taken after its creation expected a number less than or equal to 31.2 but got 31.205513
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - @http://web-platform.test:8000/dom/events/Event-timestamp-high-resolution.html:13:9
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1594:25
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - test@http://web-platform.test:8000/resources/testharness.js:544:30
[task 2019-07-17T16:49:01.124Z] 16:49:01 INFO - @http://web-platform.test:8000/dom/events/Event-timestamp-high-resolution.html:8:5
[task 2019-07-17T16:49:01.333Z] 16:49:01 INFO - TEST-OK | /dom/events/Event-timestamp-high-resolution.html | took 468ms
[task 2019-07-17T16:49:01.973Z] 16:49:01 INFO - Closing logging queue
[task 2019-07-17T16:49:01.973Z] 16:49:01 INFO - queue closed
[task 2019-07-17T16:49:01.981Z] 16:49:01 INFO - Setting up ssl
[task 2019-07-17T16:49:01.996Z] 16:49:01 INFO - certutil |
[task 2019-07-17T16:49:02.012Z] 16:49:02 INFO - certutil |
[task 2019-07-17T16:49:02.027Z] 16:49:02 INFO - certutil |
[task 2019-07-17T16:49:02.027Z] 16:49:02 INFO - Certificate Nickname Trust Attributes
[task 2019-07-17T16:49:02.027Z] 16:49:02 INFO - SSL,S/MIME,JAR/XPI
[task 2019-07-17T16:49:02.027Z] 16:49:02 INFO -
[task 2019-07-17T16:49:02.027Z] 16:49:02 INFO - web-platform-tests CT,,
[task 2019-07-17T16:49:02.028Z] 16:49:02 INFO -
[task 2019-07-17T16:49:03.732Z] 16:49:03 INFO - adb Granting important runtime permissions to org.mozilla.geckoview.test
[task 2019-07-17T16:49:04.974Z] 16:49:04 INFO - adb launch_application: am start -W -n org.mozilla.geckoview.test/org.mozilla.geckoview.test.TestRunnerActivity -a android.intent.action.MAIN --es env9 MOZ_CRASHREPORTER_NO_REPORT=1 --es env8 MOZ_DISABLE_NONLOCAL_CONNECTIONS=1 --es args "-no-remote -profile /sdcard/tests/profile --marionette about:blank" --es env3 MOZ_HIDE_RESULTS_TABLE=1 --es env2 R_LOG_VERBOSE=1 --es env1 MOZ_WEBRENDER=0 --es env0 MOZ_CRASHREPORTER=1 --es env7 R_LOG_DESTINATION=stderr --es env6 MOZ_CRASHREPORTER_SHUTDOWN=1 --es env5 MOZ_LOG=signaling:3,mtransport:4,DataChannel:4,jsep:4 --es env4 STYLO_THREADS=4 --ez use_multiprocess True --es env11 R_LOG_LEVEL=6 --es env10 MOZ_PROCESS_LOG=/tmp/tmpvtzImIpidlog
[task 2019-07-17T16:49:05.799Z] 16:49:05 INFO - Starting runner

Oli, could you take a look at this?

Flags: needinfo?(bugs)
Whiteboard: [stockwell unknown] → [stockwell unknown][stockwell needswork:owner]

I was waiting for https://bugzilla.mozilla.org/show_bug.cgi?id=1387894#c68 to happen.

Flags: needinfo?(bugs) → needinfo?(tom)

Yeah; I've had this in the back of my mind as the (few) failures came in but I had lost steam with the test corrections. Let me dust off the patches and see how things look today.

Flags: needinfo?(tom)

We unconditionally clamp all times to 20us and not just performance.now()
This will consistently apply a 'safe' minimal clamping (it's not safe but
I guess it's safer than ns-level precision) to all timestamps, and remove
intermittents that are caused by comparing a clamped performance.now() to
an unclamped [something else].

We fix this by clamping the requestAnimationFrame timestamp in the test before comparing it.
We don't clamp the requestAnimationFrame timestamp normally because it would be meaningless:
rAF fires on a regular frequency and someone perfoming a fine-grained timing attack will be
able to determine the timestamp from when it fires.

We need to use parseFloat to knock off any extra epislon we gain.

This shouldn't cause any major blow-ups because timelines are disabled in release and beta,
so at least any potential fallout would be constrained.

Depends on D38806

To ensure that there is a marker, we can't wait until exactly 200ms
have elapsed, we have to make sure we cross that threshold and go greater
than 200ms.

Depends on D38807

This has to do with double imprecision. The test originally had toPrecision(6) to
account for this imprecision. It'd round up 499.9999 into 500. When we send
double(500) (which is an epsilon below 500) into ReduceTimePrecision we wind up
coming out with 499.98. By reducing our precision requirement in this test
we can handle that and round 499.98 back up to 500

Depends on D38808

I believe these intermittents is caused by double imprecision. When unconditional clamping is enabled
it gets multiplied out and causes animation.currentTime to occasionally go to 50000.02 which causes
the test to fail. We can reduce the precision back down to ignore that.

Depends on D38809

We're hiitting double imprecision here.

Example: Given 86.68392200000000 and 86.67999999999999 we want to see
if they're equal with two significant digits. (They are, they're 86.68)

However, when we reduce them, 86.68 (which is represented as an epislon lower)
gets reduced to 86.66 and they no longer match. We disable unconditional clamping
on these tests to confirm they behave the way they shoud... excepting the clamping
which may introduce imprecision.

Depends on D38811

Alright here's a first stab at things. We'll see what's still failing...

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ef8c8ae1556b33bad026cd39b7a010958b02d64e

See Also: → 1476950
Attachment #9079588 - Attachment description: Bug 1387894 - Fix test_restyles.html for unconditional clamping → Bug 1387894, 1476950 - Fix test_restyles.html for unconditional clamping

Okay, reviews requested. I'm still a little surprised we can just directly edit web platform tests but if you say so...

Alright, let's give this a shot and see if it sticks...

Assignee: bugs → tom
Keywords: checkin-needed

Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fcfe77fab0ec
Move all Resist Fingerprinting/Reduce Time Precision prefs to StaticPrefs r=smaug

Keywords: checkin-needed
Pushed by rmaries@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d49cd8ef0825 Resolve timer intermittents when reduceTimerPrecision is disabled r=smaug https://hg.mozilla.org/integration/autoland/rev/de538a48f455 Fix the WPT and mochitest test_document-timeline.html for unconditional clamping r=birtles https://hg.mozilla.org/integration/autoland/rev/d1f09b772bac 1476950 - Fix test_restyles.html for unconditional clamping r=birtles,hiro https://hg.mozilla.org/integration/autoland/rev/c5e16646ddb1 Fix browser_animation_setCurrentTime.js for unconditional clamping r=birtles https://hg.mozilla.org/integration/autoland/rev/01e5b31bcc17 Fix animation WPTs r=birtles,jgraham https://hg.mozilla.org/integration/autoland/rev/05728160b89e Remove expected failure from Event-timestamp-safe-resolution.html r=smaug https://hg.mozilla.org/integration/autoland/rev/09785dc4c5aa Disable unconditional clamping for two CSS tests r=birtles

I'm sorry; that was a stupid warning I missed. Fixed.

Flags: needinfo?(tom)
Keywords: checkin-needed
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/18172 for changes under testing/web-platform/tests
Whiteboard: [stockwell needswork:owner] → [stockwell needswork:owner][wptsync upstream]

Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/02814f69872d
Move all Resist Fingerprinting/Reduce Time Precision prefs to StaticPrefs r=smaug

Keywords: checkin-needed
Pushed by apavel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/80040c0a275e Resolve timer intermittents when reduceTimerPrecision is disabled r=smaug https://hg.mozilla.org/integration/autoland/rev/0bff9ba4237c Fix the WPT and mochitest test_document-timeline.html for unconditional clamping r=birtles https://hg.mozilla.org/integration/autoland/rev/4a75f2556242 1476950 - Fix test_restyles.html for unconditional clamping r=birtles,hiro https://hg.mozilla.org/integration/autoland/rev/75c0249b594a Fix browser_animation_setCurrentTime.js for unconditional clamping r=birtles https://hg.mozilla.org/integration/autoland/rev/ef7b589d751b Fix animation WPTs r=birtles,jgraham https://hg.mozilla.org/integration/autoland/rev/a51919fb2062 Remove expected failure from Event-timestamp-safe-resolution.html r=smaug https://hg.mozilla.org/integration/autoland/rev/cd58aae7d47b Disable unconditional clamping for two CSS tests r=birtles
Upstream PR was closed without merging
Pushed by apavel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/998582bf083d Followup: tabs to spaces for lint CLOSED TREE
Whiteboard: [stockwell needswork:owner][wptsync upstream] → [stockwell needswork:owner][wptsync upstream error]
Whiteboard: [stockwell needswork:owner][wptsync upstream error] → [stockwell needswork:owner][wptsync upstream]
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Upstream PR was closed without merging

Depends on D38812

While in theory
ReducetimePrecision(x) == ReducetimePrecision(ReducetimePrecision(x)
this is not always the case. Sometimes ReducetimePrecision(x) is only representable
as an epsilon below the target rounding; resulting in a second call causing
an unintentional additional reduction.

A performance entry's duration was one such place we were calling the reuction
function twice. We can remove one of those calls and just ensure that the original
entries are reduced. (They mostly were, except for one instance.)

Depends on D39968

Attachment #9081788 - Attachment is obsolete: true

Let's try it again.

Please land D39212 first; then D38806-D38812, then D39969

Flags: needinfo?(tom)
Keywords: checkin-needed

I've got the following error when landing the first patch (D39212), can you please take a look?

Your request to land D39212 failed.
See https://lando.services.mozilla.com/D39212/ for details.

Reason:
We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again.

applying /tmp/tmpth2OB0
modules/libpref/init/StaticPrefList.yaml
Hunk #2 FAILED at 5478.
1 out of 3 hunks FAILED -- saving rejects to file modules/libpref/init/StaticPrefList.yaml.rej
abort: patch command failed: exited with status 256

Flags: needinfo?(tom)
Keywords: checkin-needed
Flags: needinfo?(tom)
Keywords: checkin-needed

Hi tom, D39969 is blocked for landing: Has an open ancestor revision that is blocked.

Flags: needinfo?(tom)

On Fri, August 2, 2019, 2:07 AM GMT+3, by apavel@mozilla.com.
Revisions: D39212 diff 140216
Details: We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again. applying /tmp/tmpp9WJbY modules/libpref/init/all.js Hunk #1 FAILED at 1149. 1 out of 1 hunk FAILED -- saving rejects to file modules/libpref/init/all.js.rej abort: patch command failed: exited with status 256

On Fri, August 2, 2019, 2:08 AM GMT+3, by apavel@mozilla.com.
Revisions: D38806 diff 140217 ← D38807 diff 140218 ← D38808 diff 140219 ← D38809 diff 140220 ← D38810 diff 140221 ← D38811 diff 140222 ← D38812 diff 140223
Details: We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again. applying /tmp/tmpHhWSvc toolkit/components/resistfingerprinting/nsRFPService.cpp Hunk #4 FAILED at 546. Hunk #5 FAILED at 559. Hunk #7 succeeded at 790 with fuzz 1 (offset 15 lines). 2 out of 8 hunks FAILED -- saving rejects to file toolkit/components/resistfingerprinting/nsRFPService.cpp.rej modules/libpref/init/StaticPrefList.yaml Hunk #1 FAILED at 5602. 1 out of 1 hunk FAILED -- saving rejects to file modules/libpref/init/StaticPrefList.yaml.rej abort: patch command failed: exited with status 256

Keywords: checkin-needed

Okay; rebased to fix conflicts. Let's try again :)

As before, D39212 first; then D38806-D38812, then D39969

Flags: needinfo?(tom)
Keywords: checkin-needed

Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/20d0d6970c9c
Move all Resist Fingerprinting/Reduce Time Precision prefs to StaticPrefs. r=smaug
https://hg.mozilla.org/integration/autoland/rev/e14289843f52
Resolve timer intermittents when reduceTimerPrecision is disabled. r=smaug
https://hg.mozilla.org/integration/autoland/rev/cae99e27ccdd
Fix the WPT and mochitest test_document-timeline.html for unconditional clamping. r=birtles
https://hg.mozilla.org/integration/autoland/rev/e73d900b1dcf
1476950 - Fix test_restyles.html for unconditional clamping. r=birtles,hiro
https://hg.mozilla.org/integration/autoland/rev/f07ba3e1ae0d
Fix browser_animation_setCurrentTime.js for unconditional clamping. r=birtles
https://hg.mozilla.org/integration/autoland/rev/2c84f4806f91
Fix animation WPTs. r=birtles,jgraham
https://hg.mozilla.org/integration/autoland/rev/e238e9722df0
Remove expected failure from Event-timestamp-safe-resolution.html. r=smaug
https://hg.mozilla.org/integration/autoland/rev/38e17f634ce4
Disable unconditional clamping for two CSS tests. r=birtles
https://hg.mozilla.org/integration/autoland/rev/d8b7756a6888
Avoid Double-Reducing Performance Duration objects. r=baku

Keywords: checkin-needed

For future landings, please prepare the stack to be able to get landed with Lando, e.g. remove obsolete changesets with hg histedit and push again to Phabricator, rebase one stack on top of the other.

The Phabricator urls mentioned in the comments contained two slashes (...//D12345). Could this be from your phabricator client?

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Sorry for the trouble...

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #158)

For future landings, please prepare the stack to be able to get landed with Lando, e.g. remove obsolete changesets with hg histedit and push again to Phabricator, rebase one stack on top of the other.

This is a moz-phab bug; that's exactly what I had done, but moz-phab doesn't support fixing the stack up... Bug 1569966

The Phabricator urls mentioned in the comments contained two slashes (...//D12345). Could this be from your phabricator client?

Maybe? I'm using moz-phab; and all my local commits that I pushed for this bug look like Differential Revision: https://phabricator.services.mozilla.com/D39969

Regressions: 1571226
Regressions: 1571227
Regressions: 1571038
Regressions: 1476950

I don't think we should backport this; as it's a fairly expansive, subtle patchset.

This is going to be annoying to live with on esr68 for the next year-ish. Would you be heartbroken if we skipped the relevant tests on OSX debug there?

Flags: needinfo?(tom)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #166)

This is going to be annoying to live with on esr68 for the next year-ish. Would you be heartbroken if we skipped the relevant tests on OSX debug there?

Heck no.

Flags: needinfo?(tom)
Regressions: 1577243
Regressions: 1571219
Attachment #9079587 - Attachment is obsolete: true
See Also: → 1602665
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: