Open Bug 1242362 Opened 9 years ago Updated 13 days ago

Intermittent scroll-behavior-6.html | image comparison (==), max difference: 255, number of differing pixels: 100

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
firefox46 --- affected

People

(Reporter: cbook, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed:product])

https://treeherder.mozilla.org/logviewer.html#?job_id=20416913&repo=mozilla-inbound 00:00:23 INFO - REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/test/build/tests/reftest/tests/layout/reftests/scrolling/scroll-behavior-6.html | image comparison (==), max difference: 255, number of differing pixels: 100
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
The recent spike in linux64-qr failures of this test is almost certainly due to enabling APZ on QR. I'll steal this bug and repurpose it for tracking down the fix. We can open a new bug if we get the original intermittent back after I fix this issue.
Assignee: nobody → bugmail
Blocks: wr-apz
Component: Layout → Graphics: WebRender
Whiteboard: [stockwell needswork]
I can reproduce this locally. There's a couple of problems here. The first is that the test kicks off a smooth scroll animation and expects that it will be done within 500ms. However that may not be the case because there might be arbitrary stalls or delays in the pipeline. In one instance I logged, the APZ animation only got around 300ms of runtime, probably because it took 200ms for the "animation start" notification to arrive to the APZ code from the main thread. AFAICT this is why the test was intermittently failing to begin with. The second problem is WR-specific. What's happening is that the call to FlushApzRepaints is always returning false, so we never take a fresh snapshot of the page after doing the flush. That means we often end up with a stale snapshot, which might show some previous state of the animation. This is a bug in the FlushApzRepaints code that I introduced in bug 1367837. I'll file a new bug with the fix.
I filed bug 1375897 with a patch, and that should fix the spike in linux64-qr that happened recently. I'll leave this bug open to catch the remaining intermittents, which are caused by the timeout not being long enough. We could increase the timeout but given the low frequency of this intermittent it's probably not worth it.
Assignee: bugmail → nobody
Component: Graphics: WebRender → Layout
:kats, this has increased in the last week
Flags: needinfo?(bugmail)
Whiteboard: [stockwell needswork] → [stockwell fixed:product]
I apologize, I saw the last comment but not the date- this appears to be fixed.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(jmaher)
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Your link doesn't show any jobs, please make sure the filters are set appropriately before copying the url. In a situation like this you probably want the url to have the fromchange/tochange parameters so that the link remains valid forever instead of always showing the tip of the branch. And you probably want to filter by job name rather than job status and unclassified state. I'm sure we can look this up in OrangeFactor if the failures get starred with this bug, but in the future please make sure the links show what you intend them to show. Thanks!
Flags: needinfo?(cbrindusan)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.