Closed Bug 973235 Opened 11 years ago Closed 11 years ago

Intermittent test_mediarecorder_getencodeddata.html | should get onError first

Categories

(Core :: Audio/Video: Recording, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30
Tracking Status
firefox28 --- unaffected
firefox29 --- fixed
firefox30 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: RyanVM, Assigned: rlin)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=34734731&tree=Mozilla-Aurora Windows XP 32-bit mozilla-aurora pgo test mochitest-1 on 2014-02-15 04:39:24 PST for push 8b17003640d4 slave: t-xp32-ix-018 04:52:06 INFO - 124263 INFO TEST-START | /tests/content/media/test/test_mediarecorder_getencodeddata.html 04:52:06 INFO - 124264 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Media recorder should be recording 04:52:06 INFO - 124265 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Media recorder stream = element stream at the start of recording 04:52:06 INFO - 124266 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_mediarecorder_getencodeddata.html | should get onError first 04:52:06 INFO - 124267 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Events fired from onerror should be RecordErrorEvent 04:52:06 INFO - 124268 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Event type should onerror 04:52:06 INFO - 124269 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Event name is GenericError 04:52:06 INFO - 124270 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Events fired from ondataavailable should be BlobEvent 04:52:06 INFO - 124271 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Event type should dataavailable 04:52:06 INFO - 124272 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Blob data size received is equal to zero 04:52:06 INFO - 124273 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Blob data received should have type = 04:52:06 INFO - 124274 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Mime type in ondataavailable = 04:52:06 INFO - 124275 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | Media recorder is inactive after being stopped 04:52:06 INFO - 124276 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | onStop after onError 04:52:06 INFO - 124277 INFO TEST-PASS | /tests/content/media/test/test_mediarecorder_getencodeddata.html | ondataavailableFired 04:52:06 INFO - 124278 INFO TEST-INFO | MEMORY STAT vsize after test: 432947200 04:52:06 INFO - 124279 INFO TEST-INFO | MEMORY STAT vsizeMaxContiguous after test: 766246912 04:52:06 INFO - 124280 INFO TEST-INFO | MEMORY STAT residentFast after test: 200347648 04:52:06 INFO - 124281 INFO TEST-INFO | MEMORY STAT heapAllocated after test: 55879142 04:52:06 INFO - 124282 INFO TEST-END | /tests/content/media/test/test_mediarecorder_getencodeddata.html | finished in 143ms
Component: Video/Audio → Video/Audio: Recording
No longer blocks: MediaRecording
Assignee: nobody → rlin
The problem looks like mr.start() ->starting creating encoder. async method. mr.reqeustdata() ->invoked successful , return blob with zero length. NotifyTracksAvailable received form MSG. and fail to create encoder, and return onerror notify. ==>The NotifyTracksAvailable received slower than before so cause this test failed.
Hi roc, This issue hit the timing of start and requestdata method. Could I delay the execute the requestdata (using dispatch to mainthread again) And let it can execute until start or create encoder error? Or ask w3c to change the spec and let this function get exception? (the state would be set recording because of this statement:Start() : Set state to 'recording' and wait until media becomes available from stream.
Flags: needinfo?(roc)
(In reply to Randy Lin [:rlin] from comment #2) > The problem looks like > mr.start() ->starting creating encoder. async method. > mr.reqeustdata() ->invoked successful , return blob with zero length. > > NotifyTracksAvailable received form MSG. and fail to create encoder, and > return onerror notify. > ==>The NotifyTracksAvailable received slower than before so cause this test > failed. I don't understand why this test is supposed to fire an error event. Can you explain why? We should put it in a comment in the test somewhere.
Flags: needinfo?(roc)
The test case want to capture the encoder creation problem, We try to disable ogg support start recorder, except we should get onerror event.
Attached patch patch v1 (obsolete) (deleted) — Splinter Review
From the spec, it's possible to call the requestdata while recorder is under initialization. So it's possible to have a zero blob first, then get onerror, ondataavailable, onstop event.
Attachment #8384480 - Flags: review?(jsmith)
Attachment #8384480 - Flags: review?(jsmith) → review+
Attached patch check-in patch (deleted) — Splinter Review
carry r+, check-in needed, try result https://tbpl.mozilla.org/?tree=Try&rev=5a6c91f37592
Attachment #8384480 - Attachment is obsolete: true
https://hg.mozilla.org/integration/b2g-inbound/rev/350d43769841 Please remember for the future that your commit message should be saying what your patch is doing, not re-stating the problem :)
Flags: in-testsuite+
Keywords: checkin-needed
The test passes for me with that patch applied and its timeout set to 0. I could only reproduce the test locally with its timeout set to 0. Can the timeout in the test be changed from 100ms to 0ms? Having magical timeouts in mochitests is a bad thing, and will likely cause other failures: https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges#Using_magical_timeouts_to_cause_delays
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
ni? Randy for comment 9
(In reply to Chris Pearce (:cpearce) from comment #9) > The test passes for me with that patch applied and its timeout set to 0. I > could only reproduce the test locally with its timeout set to 0. Can the > timeout in the test be changed from 100ms to 0ms? Having magical timeouts in > mochitests is a bad thing, and will likely cause other failures: > > https://developer.mozilla.org/en-US/docs/Mozilla/QA/ > Avoiding_intermittent_oranges#Using_magical_timeouts_to_cause_delays This test need to use timeout to capture the use after release problem. If we set timeout == 0, we don't need this one. BTW, I change the check flow to avoid the possible receive ondataavailable on js side before receive onerror event. It should solve cpearce's problem.
Flags: needinfo?(rlin)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: