1245830 - Intermittent e10s test_layerization.html | inner3 becomes layerized after scroll

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

This started popping up on Linux debug builds after I landed bug 990916, and is almost definitely a regression from that. Bug 1245285 took the heat for it and got backed out. I'm filing this as an intermittent because I'm pretty sure the backout won't actually fix the intermittent, and anyway I need somewhere to put the patch to fix this intermittent.

I'm pretty sure (at least in the "inner3 becomes layerized after scroll" case) what's happening is that it gets inner3 gets layerized and then the displayport expires and it becomes unlayerized, all before our 100ms setTimeout expires. This is quite plausible on a debug build, because they are slower. Not yet sure about the "test timed out" scenario.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Some samples:

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

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Attachment: Don't assert inner3 layerization

So what's happening with the "inner3 becomes layerized after scroll" failure is that it gets layerized and expires before the setTimeout in the test expires. It's basically a race condition. I think we don't really need to ensure that inner3 gets layerized, because the first half of the test already ensures that the layerization machinery works. Additionally, if outer3 becomes unlayerized then we know that this code is working as intended.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

For the "test timed out" cases (e.g. [1]) it looks like the scrollWheelOver call on inner3 isn't triggering a scroll event. From the screenshot it looks like inner3 didn't even get scrolled. I'm not sure why that happens, it should be no different than the scrollWheelOver(inner4) that happens earlier in the test and that hasn't been failing.

[1] https://treeherder.mozilla.org/logviewer.html#?job_id=21078772&repo=mozilla-inbound

Comment 4

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #2)
> Created attachment 8716331 [details] [diff] [review]
> Don't assert inner3 layerization
> 
> So what's happening with the "inner3 becomes layerized after scroll" failure
> is that it gets layerized and expires before the setTimeout in the test
> expires.

I'm not following this - the assertion that inner3 is layerized happens *before* any setTimeout calls in that part of the test.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Err sorry - basically the waitForAllPaints/flushApzRepaints block can take arbitrarily long. It imposes a minimum bound on the time, but no upper bound. Another way of looking at it is that the setTimeout at [1] is the one that takes a really long time. There's other places in that waitForAllPaints/flushApzRepaints block that could also eat up time because of async messages.

[1] http://hg.mozilla.org/mozilla-central/file/c1e7b164b6f5/gfx/layers/apz/test/mochitest/apz_test_utils.js#l109

Comment 6

[Botond Ballo [:botond]]

Comment on attachment 8716331 [details] [diff] [review]
Don't assert inner3 layerization

Review of attachment 8716331 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, that makes more sense.

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/43099ff72249

Comment 8

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/43099ff72249

Comment 9

[Intermittent Failures Robot]

13 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 5
* fx-team: 4
* mozilla-central: 3
* try: 1

Platform breakdown:
* linux32: 10
* linux64: 3

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1245830&startday=2016-02-01&endday=2016-02-07&tree=all

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I'm trying to uplift this to aurora to fix up e10s tests on that branch. Hitting conflicts with this one, likely because bug 990916 wasn't uplifted. Happy to come back to this if that gets uplifted, though.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

This is a regression from bug 990916, so you probably don't need it on aurora. If you are seeing this intermittent on aurora let me know because I'd be interested to figure out why it's happening there.

Comment 12

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

It was just one on a list of bugs relman put together for things that might need uplifting. If 990916 isn't on 46, I'm happy to leave this on 47 with it.