Closed Bug 1213043 Opened 4 years ago Closed 3 years ago
.html | load failed: timed out waiting for pending paint count to reach zero (waiting for Moz After Paint)
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1950629b85e031319e32032a61a795da4c00e8e9 Based on the logs I think we just end up starting painting of the gif soon enough so that we never get out of STATE_WAITING_TO_FIRE_INVALIDATE_EVENT state
FYI the QuantumRender opt R-e10s-4 and Ru-e10s-4 jobs are practically permafailing with this error right now (it was intermittent but the frequency seems to have gone up significantly recently). I'm happy to do a try push with your patch to see if it fixes the problem, if you like.
Try push with your patch applied to the graphics branch tip: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a5eba82fb9c49eacea4f5e4da9f7f30a186cf5d2
kats, I think I have a fix that better address the problem. Perhaps you could kick off a Try push for web-render with this too? https://treeherder.mozilla.org/#/jobs?repo=try&revision=ea65464ceabeca8e7d40d291ad36c8075daab2ee (I suppose I don't get those by default with a regular Try push.)
smaug's patch didn't seem to fix the failure for QR builds. Mats, I pushed yours to https://treeherder.mozilla.org/#/jobs?repo=try&revision=3716a6e44e33dc28ef3583fa1159ac3e5ab05bfc
Looking good so far. I retriggered the job a bunch of times to confirm.
The retriggers are all green too. I'd say the patch is good.
Great, thanks kats.
Comment on attachment 8837410 [details] [diff] [review] Alternative fix >Bug 1114526 - Make sure we kick off a paint in MozReftestInvalidate to ensure mozPaintCount is incremented eventually (to avoid test timeout). r=tn There should be a animated gif on the page that loops forever. So there shouldn't be any lack of paints happening. I could buy that animated gif causes painting to happen so fast that there is always a paint pending and so MozReftestInvalidate never fires though. The thing we are trying to test here is that the hidden animated gif causes the moz-element to redraw. So since we are adding another paint (toggling the visibility) to the paints we count we need to increase the number of paints we expect for success from 2 to 3.
I think that MozReftestInvalidate means that the content is loaded, reflowed and painted at least once. So getting one more paint after the one associated with the 'visibility' change should be good enough to prove the effect you describe. But sure, one extra doesn't hurt. :-) https://treeherder.mozilla.org/#/jobs?repo=try&revision=0e9130f45a0c1d2259571e2a5469885b7facc90d
fwiw, https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-searchStr=android%20reftest-19&tochange=a29047e422cb991495f2b6ff90d313fb742256db&fromchange=b3ec4674a7fe3492b101fca47ce3c6cc36327b1a suggests this bug re-started with https://hg.mozilla.org/integration/mozilla-inbound/rev/910ceca7e8637c4c3ea963fd054e6c449eeff6a7.
(In reply to Mats Palmgren (:mats) from comment #20) > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=0e9130f45a0c1d2259571e2a5469885b7facc90d You can ignore the R8 failures on this, I have a patch on bug 1331357 that fixes it by changing the asserts-if clause.
Attachment #8838002 - Flags: review?(tnikkel) → review+
can we land this patch?
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/3625486cc6f5 Make sure we kick off a paint in MozReftestInvalidate to ensure mozPaintCount is incremented eventually (to avoid test timeout). r=tn
Whiteboard: [stockwell fixed]
You need to log in before you can comment on or make changes to this bug.