Closed Bug 544537 Opened 14 years ago Closed 14 years ago
random failure of toolkit/content/tests/widgets/test
_mousecapture _area .html
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
14 years ago
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.
Try the setTimeout thing first.
Assignee: nobody → tnikkel
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
Attachment #425546 - Flags: review+
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.
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.
Pushed that patch http://hg.mozilla.org/mozilla-central/rev/d2687c5046e2 Let's see if it works.
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
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
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.
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.