Closed Bug 1263416 Opened 6 years ago Closed 6 years ago

Intermittent test_basic_pan.html | check that the div scrolled - got +0, expected 50

Categories

(Core :: Panning and Zooming, defect)

48 Branch
Unspecified
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: RyanVM, Assigned: kats)

References

Details

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

Attachments

(1 file)

https://treeherder.mozilla.org/logviewer.html#?job_id=25474229&repo=mozilla-inbound

15:17:25     INFO -  306 INFO TEST-START | gfx/layers/apz/test/mochitest/test_basic_pan.html
15:17:25     INFO -  307 INFO TEST-PASS | gfx/layers/apz/test/mochitest/test_basic_pan.html | check that the window scrolled
15:17:25     INFO -  308 INFO TEST-UNEXPECTED-FAIL | gfx/layers/apz/test/mochitest/test_basic_pan.html | check that the div scrolled - got +0, expected 50
15:17:25     INFO -      SimpleTest.is@SimpleTest/SimpleTest.js:268:5
15:17:25     INFO -      checkScroll@gfx/layers/apz/test/mochitest/helper_div_pan.html:27:3
15:17:25     INFO -  309 INFO TEST-PASS | gfx/layers/apz/test/mochitest/test_basic_pan.html | check that the iframe scrolled
15:17:25     INFO -  310 INFO TEST-OK | gfx/layers/apz/test/mochitest/test_basic_pan.html | took 69130ms
Note to self: RyanVM suspects this might have been "caused" by a chunking change that was made shortly before this started happening. And I just noticed that ./mach mochitest has a handy-looking --bisect-chunk option which might be helpful in confirming that, assuming the failure is reproducible.
Whiteboard: [gfx-noted]
Version: Trunk → 48 Branch
I've retriggered this a lot of times and so far this failure hasn't shown up. I found a couple of instances of a different failure, but the logging I have in this try push probably won't help diagnose that one.

... and I just noticed that my try push used an opt build but this seems to only happen on debug builds, according to orangefactor. I'll add some debug jobs and see if it turns up.
Ok, so I got a log for this, but it's kind of puzzling. The APZC gets all the touch events and processes them, gets to the right scroll offset, but then doesn't actually send a repaint request back to the main thread. It does the displayport calculation, so it must be bailing at [1] but I don't know why, since as far as I can tell the scroll offset in mFrameMetrics is (0,50) and it should be (0,0) in mLastPaintRequestMetrics.

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/AsyncPanZoomController.cpp?rev=1fd853200c99#3036
Oh, I guess the other option is that mGeckoController is null at that point, which might happen because of the displayport expiry timeout being 15s.
Yeah I think that's what's happening. I'll extend the timeout.
Assignee: nobody → bugmail.mozilla
Comment on attachment 8744005 [details]
MozReview Request: Bug 1263416 - Disable displayport expiry for test_basic_pan.html. r?botond

https://reviewboard.mozilla.org/r/48241/#review45219
Attachment #8744005 - Flags: review?(botond) → review+
In theory this was introduced by bug 990916 but the failures probably didn't start showing up until the chunking change happened.
Blocks: 990916
https://hg.mozilla.org/mozilla-central/rev/8dc88a0d88bb
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.