544537 - random failure of toolkit/content/tests/widgets/test_mousecapture_area.html

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A new random failure from a new test:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265391512.1265392241.18291.gz
OS X 10.5.2 mozilla-central debug test mochitests-5/5 on 2010/02/05 09:38:32
s: bm-xserve07
7937 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_mousecapture_area.html | setCapture works on areas mousemove event fired - got false, expected true

Comment 1

[Timothy Nikkel (:tnikkel)]

It looks like the primary frame for the area hasn't been set yet. The primary frame for areas usually gets set during the first paint of the associated image. The test uses processUpdates() to force a paint. The expected "Losing track of existing primary frame" assertion tells us when the primary frame for the shared area gets set to the second image, and that happens after we start sending mouse events to the area. So the question is why hasn't processUpdates caused a paint to happen yet when we start the real test.

We could try running the rest of the test after the processUpdates call on a setTimeout, or start the images as display: none, then remove the display: none when we are ready to run the test and listen for a MozAfterPaint event. As a last resort we could poll the getBoundingClientRect of the area, and setTimeout until its something other than a zero width, zero height rect.

Comment 2

[Timothy Nikkel (:tnikkel)]

Attachment: patch

Try the setTimeout thing first.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 425546 [details] [diff] [review]
patch

r=dbaron, though it seems like it's worth at least getting bugs filed on (and possibly fixing) various issues here that we're working around... and that sites could also just as easily be forced to work around

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hmmm.  Not sure how clear my last comment was.  However, the point is that the stuff we're working around here may well be stuff that can break Web pages too, so it's worth having bugs on and fixing.

Comment 5

[Timothy Nikkel (:tnikkel)]

The main problem with image maps is covered by bug 135040. I'll add a comment there about image maps setting up during painting, as it would make sense to fix that at the same time.

Comment 6

[Timothy Nikkel (:tnikkel)]

Pushed that patch
http://hg.mozilla.org/mozilla-central/rev/d2687c5046e2
Let's see if it works.

Comment 7

[Boris Zbarsky [:bzbarsky]]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1266601528.1266602290.10990.gz
OS X 10.5.2 mozilla-central opt test mochitests-5/5 on 2010/02/19 09:45:28
s: bm-xserve09

Comment 8

[Timothy Nikkel (:tnikkel)]

The processUpdate call looks like it doesn't really do anything on OS X because nsCocoaWindow::Update and nsChildView::Update are no ops. So there isn't a way to force painting to happen on OS X.

In both failures only the first mousedown-mousemove-mouseup series fails, and then it seems a paint has happened, so maybe it is the mouse event series that causes the painting to happen?

I added some unneeded mouse events before the real test starts to see if this helps. I also bumped the setTimeout to 100 ms.

http://hg.mozilla.org/mozilla-central/rev/518c1de21d68

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://hg.mozilla.org/mozilla-central/rev/2900b1afa3d4 landed for this bug.

Would it have been sufficient to send a mousemove to each image to get it to set up its image map?  I would certainly hope so.

Comment 10

[Timothy Nikkel (:tnikkel)]

Thanks for pasting that, I was just waiting for all test results to be in before doing that.

Yes, now that you mention it, a mouse move probably would have been sufficient, just something that gets into the nsImageFrame event code so that it searches for and sets up its areas before we start capturing on an area.

Marking this fixed because this seems to be understood now.