Closed Bug 1298084 Opened 3 years ago Closed 3 years ago

Intermittent gfx/layers/apz/test/mochitest/test_interrupted_reflow.html | The scroll position did drop to 0 and then get restored properly - got 1, expected 3

Categories

(Core :: Panning and Zooming, defect, P3)

51 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox48 --- unaffected
firefox49 --- fixed
firefox50 --- fixed
firefox51 --- fixed

People

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

References

Details

(Keywords: intermittent-failure, Whiteboard: [gfx-noted])

Attachments

(1 file)

Priority: -- → P3
Version: unspecified → 51 Branch
From the output I see this:

Got scroll offsets: [{"x":0,"y":9700},{"x":0,"y":9700},{"x":0,"y":9700},{"x":0,"y":9700},{"x":0,"y":9700}] 

Since the scroll position remained at y=9700 the whole time, the test didn't exercise the codepath it was meant to exercise. So it's a bug in the test, not in the code.
Whiteboard: [gfx-noted]
This is basically permafailing on Aurora.
If it's really bad, rs=me to disable the test on Aurora and/or Beta since it's a bug in the test. Note that if the error message shows up as "got 2, expected 3" rather than "got 1, expected 3" then please make sure that gets filed separately since that's likely to be a bug in the code rather than the test.
I caught this in rr chaos mode after many attempts. In the failure cases it looks like when the waitForAllPaints at [1] runs, there's no pending paints. The line above seems to only queue up a restyle, and I presume the paint gets queued up asynchronously, and in some cases that doesn't happen until later. So maybe we need to do a waitForAllPaintsFlushed instead?

[1] http://searchfox.org/mozilla-central/rev/f80822840bc5f3d2d3cae3ece621ddbce72e7f54/gfx/layers/apz/test/mochitest/test_interrupted_reflow.html#620
Also to note - in the failure case, the restyle and reflow happens when the test reads scrollTop a few lines down - when that happens the reflow is non-interruptible. The same thing happens if I try to flush manually - the reflow is non-interruptible. I might need to take control of the refresh driver and ensure it ticks...
That seems to work. Try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=eeff902b54fe

I ran the patch locally in rr chaos mode 100+ times and it was green, so hopefully this does the job.
Assignee: nobody → bugmail
The patch seems to fix it on desktop, but on Android for some reason the interrupted reflow doesn't push a layers transaction over to the compositor. Not yet sure why, maybe it's an e10s vs non-e10s thing?
Comment on attachment 8786077 [details]
Bug 1298084 - Manually tick the refresh driver to ensure the interrupted reflow happens when we want it to.

https://reviewboard.mozilla.org/r/75040/#review72936
Attachment #8786077 - Flags: review?(tnikkel) → review+
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/29f27e5ab217
Manually tick the refresh driver to ensure the interrupted reflow happens when we want it to. r=tnikkel
https://hg.mozilla.org/mozilla-central/rev/29f27e5ab217
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
The fix seems to be working, I don't see any new failures of this kind on any branch that has the fix.

Uplifted to aurora as well: https://hg.mozilla.org/releases/mozilla-aurora/rev/a163da3582e3
You need to log in before you can comment on or make changes to this bug.