Closed Bug 1213043 Opened 4 years ago Closed 3 years ago

Intermittent 1114526-1.html | load failed: timed out waiting for pending paint count to reach zero (waiting for MozAfterPaint)


(Core :: Layout, defect, P3)




Tracking Status
firefox52 --- unaffected
firefox53 --- unaffected
firefox54 --- fixed


(Reporter: KWierso, Assigned: mats)



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


(1 file, 2 obsolete files)

Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Attached patch possible fix (obsolete) — Splinter Review

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.
Attached patch Alternative fix (obsolete) — Splinter Review
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?
(I suppose I don't get those by default with a regular Try push.)
Flags: needinfo?(bugmail)
smaug's patch didn't seem to fix the failure for QR builds. Mats, I pushed yours to
Flags: needinfo?(bugmail)
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.
Attachment #8837410 - Flags: review?(tnikkel)
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.
Attachment #8837410 - Flags: review?(tnikkel)
Duplicate of this bug: 1339876
Attached patch Alternative fixSplinter Review
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. :-)
Assignee: nobody → mats
Attachment #8836653 - Attachment is obsolete: true
Attachment #8837410 - Attachment is obsolete: true
Attachment #8838002 - Flags: review?(tnikkel)
(In reply to Mats Palmgren (:mats) from comment #20)
> 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+
Yes, please.
Keywords: checkin-needed
Pushed by
Make sure we kick off a paint in MozReftestInvalidate to ensure mozPaintCount is incremented eventually (to avoid test timeout).  r=tn
Keywords: checkin-needed
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Whiteboard: [stockwell fixed]
You need to log in before you can comment on or make changes to this bug.