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

RESOLVED FIXED in mozilla1.9.3a5



10 years ago
3 months ago


(Reporter: dbaron, Assigned: tnikkel)



Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)



(1 attachment)

A new random failure from a new test:

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
Blocks: 517737

Comment 1

10 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.

Comment 2

10 years ago
Posted patch patchSplinter Review
Try the setTimeout thing first.
Assignee: nobody → tnikkel
Comment on attachment 425546 [details] [diff] [review]

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.

Comment 5

10 years ago
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

10 years ago
Pushed that patch
Let's see if it works.
OS X 10.5.2 mozilla-central opt test mochitests-5/5 on 2010/02/19 09:45:28
s: bm-xserve09

Comment 8

10 years ago
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/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

9 years ago
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.
Closed: 9 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Target Milestone: --- → mozilla1.9.3a5
Whiteboard: [orange]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.