toolkit/content/tests/widgets/test_videocontrols_audio_direction.html fails on Windows debug builds

RESOLVED FIXED in mozilla1.9.3a1

Status

()

defect
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: dbaron, Assigned: Ehsan)

Tracking

({intermittent-failure})

unspecified
mozilla1.9.3a1
x86
Windows Server 2003
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 beta3-fixed)

Details

Attachments

(3 attachments)

If you look at the Windows debug unittest 5/5 on http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox-Unittest&noignore=1 it appears that this failure:

14549 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_videocontrols_audio_direction.html | Rendering of reftest videocontrols_direction-2a.html should not be different to the reference

happens every time.  It seems ok on other platforms, and on non-debug.

In particular, look for the box "WINNT 5.2 mozilla-central test debug mochitests-5/5".
Summary: content/tests/widgets/test_videocontrols_audio_direction.html fails on Windows debug builds → toolkit/content/tests/widgets/test_videocontrols_audio_direction.html fails on Windows debug builds
I can't reproduce this failure locally (running just toolkit/content/tests/widgets/).
The difference in the snapshots (from the logs) looks like the part of the UI that shows how much of the audio has loaded.  (At least I think that's what that UI is showing.)
So, looking at the test, it's snapshotting when it gets a load event for an iframe.  Video elements don't hold up load any more, so this looks entirely random based on how much of the video has been buffered by the time the load event fires.  It looks to me like toolkit/content/tests/widgets/videocontrols_direction_test.js needs some rejiggering to cooperatively delay for embedded video element buffering.
They do hold up the document load until we reach the first decoded frame, but they no longer fire the load event on the media element.  I don't think the test relies on that, so that's not the problem.

None of the media elements used in the test are autobuffer, so the load is going to be suspended by the media cache sometime after the first frame is decoded.  Because the test files are so small, we'll usually have loaded the entire file before this happens, but it's not guaranteed.
You're right that it needs to wait for more than the document load event, though, because even with autobuffer the file might not finish loading until after we've unblocked the document load event.
Ah, indeed, that would cause the problem.

Since this is effectively a reftest, it needs to wait until the load actually finishes so that the progress bars look the same. I think that will now require listening to progress events, and waiting until .loaded == .total (it's a small clip, so that should be fine w.r.t. the media cache). And they'd also need the autobuffer attribute set.

Comment 8

10 years ago
I believe the progress events are no longer actual progress events in the spec, so .loaded and .total will not exist. 

We haven't made this change yet but it would pay not to have tests rely on something that is going away.
When they go away, controls will have to be modified to use 'buffered' instead, so I think it's reasonable to expect to modify these tests then too, and use .loaded and .total for now.
AIUI, this is one of the tests that's holding up switching over to the split mochitests, so we should fix this ASAP. Ehsan, can you pick this up?
Assignee

Updated

10 years ago
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
It's just holding up unhiding that part of the Windows debug Mochitests.
(In reply to comment #11)
> It's just holding up unhiding that part of the Windows debug Mochitests.

Any ETA on this?

We're having to run unittests both ways until this is fixed, and the extra load is hurting wait times.
Seems to have gone away on its own, at least for now, but it would still be really good to make this test wait for what it ought to be waiting for.
Assignee

Comment 14

10 years ago
This should take care of the failure.

I've also submitted a try server build...
Attachment #411298 - Flags: review?(mconnor)
Attachment #411298 - Flags: review?(dolske)
Comment on attachment 411298 [details] [diff] [review]
Patch (v1)
[Checkin: Comment 16 & 17]

r=me, land away assuming it doesn't explode on try (doesn't need further review).
Attachment #411298 - Flags: review?(mconnor)
Attachment #411298 - Flags: review?(dolske)
Attachment #411298 - Flags: review+
Assignee

Comment 16

10 years ago
http://hg.mozilla.org/mozilla-central/rev/25138a08de15

I'll land it on branch after a green cycle on trunk.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Assignee

Updated

10 years ago
Blocks: 501754
Assignee

Updated

10 years ago
No longer blocks: 501754
(In reply to comment #18)
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/645622c570fb


Firefox3.5-Unittest went orange once this landed -

85931 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_videocontrols_audio_direction.html | Test timed out.
85934 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_videocontrols_video_direction.html | Test timed out.
(In reply to comment #18)
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/645622c570fb

Broke SeaMonkey too:
{
28659 ERROR TEST-UNEXPECTED-FAIL | /tests/content/xml/document/test/test_bug293347.html | doc still intact - got 0, expected 2
28660 ERROR TEST-UNEXPECTED-FAIL | /tests/content/xml/document/test/test_bug293347.html | doc body still intact - got null, expected "http://www.w3.org/1999/xhtml"
buildbot.slave.commands.TimeoutError: command timed out: 300 seconds without output, killing pid 17359
}

Please, back out.!.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258020412.1258021384.16867.gz
WINNT 5.2 mozilla-central debug test mochitests-5/5 on 2009/11/12 02:06:52  
"s: moz2-win32-slave22"
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee

Comment 23

10 years ago
Hmm, I'm really out of ideas here.  The buffer bar value is set by the progress handler, and after the final progress event, a suspend event is fired <http://mxr.mozilla.org/mozilla-central/source/content/media/ogg/nsOggDecoder.cpp#2225>.  The only other case in which a suspend event is fired is when nsHTMLMediaElement::SuspendDownload is called.  So, this check should handle that case as well.  I've ran this test quite a few times locally and it passes every time.  I think this patch is also worth a shot.
Attachment #411978 - Flags: review?(dolske)
Assignee

Updated

10 years ago
Status: REOPENED → ASSIGNED
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258097623.1258098384.17798.gz#err0
WINNT 5.2 mozilla-central debug test mochitests-5/5 on 2009/11/12 23:33:43
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258127273.1258128330.10805.gz
WINNT 5.2 mozilla-central debug test mochitests-5/5 on 2009/11/13 07:47:53  
"s: moz2-win32-slave14"
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258130599.1258131421.13534.gz
WINNT 5.2 mozilla-central debug test mochitests-5/5 on 2009/11/13 08:43:19  
"s: moz2-win32-slave27"
Assignee

Updated

10 years ago
Attachment #411978 - Flags: review?(dolske)
Assignee

Updated

10 years ago
Blocks: 438871
Whiteboard: [orange]
Attachment #411978 - Attachment description: Patch (v2) → Patch (v2) [Checkin: Comment 27 & 28]
Attachment #411298 - Attachment description: Patch (v1) → Patch (v1) [Checkin: Comment 16 & 17]
Assignee

Comment 29

10 years ago
I think this can be marked as FIXED now.  The only remaining known issue with this test is bug 528001.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
Target Milestone: mozilla1.9.3a1 → ---
Version: Trunk → unspecified
Target Milestone: --- → mozilla1.9.3a1
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.