Closed Bug 565245 Opened 15 years ago Closed 12 years ago

Intermittent failure in test_bug493251.html | Wrong number events (16 through 21, one short on each)

Categories

(Core :: DOM: Events, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla17

People

(Reporter: philor, Assigned: masayuki)

References

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled on Linux])

Attachments

(3 files)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1273640222.1273640706.6354.gz WINNT 5.2 mozilla-central opt test mochitests-1/5 on 2010/05/11 21:57:02 s: win32-slave25 33340 INFO TEST-PASS | /tests/content/events/test/test_bug493251.html | Wrong number events (20) 33341 ERROR TEST-UNEXPECTED-FAIL | /tests/content/events/test/test_bug493251.html | Wrong number events (21) - got 1, expected 2 33343 INFO Running /tests/content/events/test/test_bug502818.html...
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1275911972.1275912546.9163.gz WINNT 5.2 mozilla-central opt test mochitests-1/5 on 2010/06/07 04:59:32 s: win32-slave36
philringnalda%gmail.com http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276227146.1276227604.18318.gz WINNT 5.2 mozilla-central opt test mochitests-1/5 on 2010/06/10 20:32:26 s: win32-slave25 34459 ERROR TEST-UNEXPECTED-FAIL | /tests/content/events/test/test_bug493251.html | Wrong number events (21) - 1 should equal 2
So, looks like something broke this test in May on Windows, and we didn't care, and then something fixed it in July, and now something has broken it in a different way on Linux, and we still don't care. Should we just disable the test?
OS: Windows Server 2003 → Linux
Summary: Intermittent failure in test_bug493251.html | Wrong number events (21) - got 1, expected 2 → Intermittent failure in test_bug493251.html | Wrong number events (16 through 21, one short on each)
Attached patch disable on Linux — — Splinter Review
Haven't really seen any sign since comment 102 that anyone plans on doing anything about this, and it's starting to break into the top 5 failures.
Attachment #498954 - Flags: review?(Olli.Pettay)
Attached patch log more details — — Splinter Review
We should log more details of this bug before disabling on Linux.
Attachment #504407 - Flags: review?(Olli.Pettay)
Attachment #504407 - Flags: review?(Olli.Pettay) → review+
Looks like there are two bugs: 1. like comment 192, mouse events in continueTest2() dispatches no mouse events. 2. like comment 210, fails to suppress event handling in contunueTest2() for mousedown and mouseup events.
Attachment #498954 - Flags: review?(Olli.Pettay) → review+
Whiteboard: [orange] → [orange][test disabled on Linux]
Masayuki, did you do more investigation on this bug?
smaug, as test author of this top 3 orange, do you have any ideas? It is pretty much only occurring on Windows: http://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=565245&entireHistory=true&tree=trunk
Besides "why only Windows?" that chart asks another, more interesting question: "what landed on June 30th, was backed out on July 3rd, and relanded on August 13th?" Answer: dlbi.
Blocks: dlbi
Attached patch Patch — — Splinter Review
I guess that sometimes reflow or something hasn't been finished at onload. https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=a8cb0d5ba8b0
Matt, please can you take a look at this - DLBI regressed this test substantially - making it a top 3 orange. (Nice spot philor :-D)
(In reply to Ed Morley [:edmorley] from comment #619) > Matt, please can you take a look at this - DLBI regressed this test > substantially - making it a top 3 orange. (Nice spot philor :-D) see comment 615 ;-)
Ah, serves me right for replying when being only halfway through the bugmail. Thank you for the patch :-)
Comment on attachment 653244 [details] [diff] [review] Patch It seems that this fixes this bug completely. https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=a8cb0d5ba8b0 I think that positioned events must be tested after reflow. At onload event, sometimes it's not finished yet. We should use waitForFocus() for kicking the doTest().
Attachment #653244 - Flags: review?(bugs)
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Comment on attachment 653244 [details] [diff] [review] Patch So now we call SimpleTest.waitForExplicitFinish(); twice. The one in the original file should be enough. But this could indeed help. Push this to try and run several times before pushing to m-c.
Attachment #653244 - Flags: review?(bugs) → review+
(In reply to Olli Pettay [:smaug] from comment #624) > Comment on attachment 653244 [details] [diff] [review] > Patch > > So now we call SimpleTest.waitForExplicitFinish(); twice. > The one in the original file should be enough. > But this could indeed help. I don't understand well about the SimpleTest APIs... > Push this to try and run several times before pushing to m-c. See the link in the previous comment, I've already tried to test for a whole day: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=a8cb0d5ba8b0 I'll land it soon.
So far, there is no this orange in inbound after the landing.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Whiteboard: [orange][test disabled on Linux] → [test disabled on Linux]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: