Closed Bug 592882 Opened 9 years ago Closed 9 years ago

Intermittent fail in test_videocontrols.html | Test timed out

Categories

(Core :: Audio/Video, defect)

x86_64
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b7

People

(Reporter: sicking, Assigned: tnikkel)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1283377157.1283378003.21629.gz

17776 INFO TEST-START | /tests/toolkit/content/tests/widgets/test_videocontrols.html
17777 INFO TEST-PASS | /tests/toolkit/content/tests/widgets/test_videocontrols.html | ----- test #1 -----
17778 INFO TEST-PASS | /tests/toolkit/content/tests/widgets/test_videocontrols.html | checking event type - "canplaythrough" should equal "canplaythrough"
17779 INFO TEST-PASS | /tests/toolkit/content/tests/widgets/test_videocontrols.html | checking video play state - true should equal true
17780 INFO TEST-PASS | /tests/toolkit/content/tests/widgets/test_videocontrols.html | checking video mute state - false should equal false
17781 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_videocontrols.html | Test timed out.
Duplicate of this bug: 592886
Blocks: 438871
What changed that caused this to start timing out frequently?  There haven't been changes to the content/media code for a week or so.
After "checking video mute state", the test calls synthesizeMouse to click on the video control's play button.  Either that's not working, or the resulting 'play' event is not firing.
Top level widgets were recently removed see bug 130078 and http://tinikkel.wordpress.com/2010/09/01/bug-130078-landed

That may affect synthesizeMouse... I'm unsure what else could.
(In reply to comment #7)
> Top level widgets were recently removed see bug 130078 and
> http://tinikkel.wordpress.com/2010/09/01/bug-130078-landed
> 
> That may affect synthesizeMouse... I'm unsure what else could.

Adding Timothy Nickel to CC list, in case he's got any insights into this.
I wonder if the patch in bug 587960 would fix this. It is to properly fix the test right before this one instead of working around the problem in the test.
Looking at the test it could be starting before paint suppression ends. So I'll try landing this patch that starts the test off a setTimeout after the page's load event has fired and see if that fixes it.
Landed "start after paint suppression ends"
http://hg.mozilla.org/mozilla-central/rev/62d7a16bca1a
Comment on attachment 482172 [details] [diff] [review]
start after paint suppression ends

This seems to have worked, no failures on m-c since landing it. Better get review if I think this will stick.
Attachment #482172 - Flags: review?(chris)
Comment on attachment 482172 [details] [diff] [review]
start after paint suppression ends

This is dolske's domain, so passing review to him. Having said that, it looks like this patch has prevented the random failures.
Attachment #482172 - Flags: review?(chris) → review?(dolske)
That's a new failure mode. I guess we get a second canplaythrough event, does that make sense? If so it can be fixed by not re-adding the canplaythrough listener, and then not needing to remove it in runTest.
(In reply to comment #144)
> That's a new failure mode. I guess we get a second canplaythrough event, does
> that make sense?

Yes, you can get multiple canplaythrough events dispatched to an individual element, depending on the network download speed etc.
Assignee: nobody → tnikkel
Attachment #484198 - Flags: review?(dolske)
Attachment #482172 - Flags: review?(dolske) → review+
Comment on attachment 484198 [details] [diff] [review]
don't re-add the listener

Looks like this test is still failing randomly? :( These patches seem fine, though.
Attachment #484198 - Flags: review?(dolske) → review+
(In reply to comment #155)
> Comment on attachment 484198 [details] [diff] [review]
> Looks like this test is still failing randomly?

It seems to be mostly failing on TraceMonkey, which hasn't merged to pick up Tim's fix yet.

There's still the failure reported in comment 143 on m-c, but it's only been reported once so far.
The second of my two patches should fix the comment 143 failure.
And all the other failures are on TraceMonkey.
Landed the followup
http://hg.mozilla.org/mozilla-central/rev/2acfa1d1b45c

This should be fixed, we should only get some tracemonkey failures until it merges from m-c.
The easy way to get rid of my confusing noise from TM is just to resolve it, so I'll remember it's part of the huge list of things I star "needs an m-c merge" there.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.