Closed Bug 1224936 Opened 7 years ago Closed 6 years ago
Sound indicator is displayed after video stops because of network error
>>> My Info: Win7_64, Nightly 45, 32bit, ID 20151113030248, new profile <<< STR_1: 1. Open https://videos.cdn.mozilla.net/uploads/mozillaorg/ 2. Click "A different kind of browser.webm" link [sound indicator will appear] 3. Before the video is buffered, disable internet connection [you'll get an error "Video playback aborted due to a network error." ] Result: Sound indicator is still displayed Expectations: Sound indicator should disapper, because video is stopped Note: On some slow sites audio playback sometimes stops because it's not buffered (you know. Audio plays several seconds, then stops to load next portion of data) So, when audio playback stops, the sound indicator is still displayed. I think this additional case will be fixed at the same time as STR_1 will be fixed. If you disagree or if you think that it's separate bug, I can provide a site, STR_2 and a screencast.
I changed my mind: the additional case may be a part of bug 1225000, not this one
If we have an error, we are not playing. Is this assumption correct?
Comment on attachment 8687900 [details] [diff] [review] error.patch Review of attachment 8687900 [details] [diff] [review]: ----------------------------------------------------------------- Correct. However, this means you need to call HTMLMediaElement::UpdateAudioChannelPlayingState when mError changes. This also needs a test.
You are right but I didn't find any smart way to simulate a network failure or any kind of error that can reproduce this issue.
Attachment #8688184 - Flags: review?(roc) → review+
There should be a way to have a decode error occur after playback begins, by playing a media file that's partially corrupted. I don't have such a file on hand, but if we don't have one in the tree it should be possible to make one --- and we definitely should be testing that playing back such a file doesn't crash!
The bad news is, I backed you out in https://hg.mozilla.org/integration/mozilla-inbound/rev/e72f21cccc6b for Mulet Gij failures, https://treeherder.mozilla.org/logviewer.html#?job_id=17377141&repo=mozilla-inbound The good news is, that failure very probably means that your patch is working exactly like it should. It's hard to understand through all the noise, but bug 1223394 is an infra bug, taskcluster started running Mulet tests on instances that have no audio support. Since the fix for that hasn't landed yet, your patch had to run on Mulet which thought that it was playing audio just fine, despite the fact that nothing was playing because it had no audio support, and then you came along and told it about the error, and it stopped saying that it was playing when it wasn't, and so the test failed. Like it should, but you still don't get to land and make the test permaorange, even though it should be permaorange.
Depends on: 1223394
Using MSE would enable you to very easily simulate this. you can then issue the error you want to propagate to the media element (network error, decoding error etc) As far as the visual indicator is concerned, using MSE or a plain file should make no difference.
Um, sorry for interrupting, but there're actually many errors that stop the playback, e.g. bug 1225770 So maybe there's a general way to fix all of them together?
What about if I disable the test(s) for Mulet for now?
Bug 1223394 is fixed, I wouldn't expect that you would need to now.
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/eaa63e3f2707 at Baku's request for mulet bustage.
roc, it seems that on mulet machines we have some audio issue that triggers errors to any media element. I cannot disable partial gaia integration tests, so I would like to know your opinion about a #ifndef MOZ_MULET if(mError)... #endif. I filed a bug but I don't think it will be fixed soon.
Flags: needinfo?(amarchesini) → needinfo?(roc)
I'm confused. If audio output fails, why would that trigger a media element error? AFAIK it shouldn't.
I've reproduced this bug on Nightly 45.0a1 (2015-11-15) on Ubuntu 14.04 LTS, 32-bit! This bug's fix is verified on Latest Nightly 48.0a1! Build ID: 20160309030419 User Agent: Mozilla/5.0 (X11; Linux i686; rv:48.0) Gecko/20100101 Firefox/48.0
QA Whiteboard: [bugday-20160309] → [bugday-20160309] [good first verify]
I also reproduced this bud on nightly according to [2015-11-15] It's fixed on Latest Developer Edition Build Id (20160326004034), User Agent-(Mozilla/5.0 (Windows NT 6.3; rv:47.0) Gecko/20100101 Firefox/47.0) Tested OS-- Windows8.1 32bit [testday-20150325]
QA Whiteboard: [bugday-20160309] [good first verify] → [bugday-20160309] [good first verify][testday-20160325]
I also reproduce this bug. Bug's fixed. QA Whiteboard:[bugday-20160309][good first verify][testday-20160325]→[testday-20160401]
I'm lost. Is this bug fixed or not?
[bugday-20160323] Status: FIXED -> NOT FIXED Comments: STR is clear. Component: Name Firefox Version 46.0b9 Build ID 20160322075646 Update Channel beta User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 OS Windows 7 SP1 x86_64 Expected Results: No sound indicator should be there after Actual Results: The sound indicator is still after the network conn. loss. I don't think this seems to be treated as bug, we will see the same behavior on Youtube. My personal opinion.
I have reproduced this bug with Firefox Nightly 45.0a1 (Build ID: 20151115030440) on Windows 8.1, 64-bit with the instructions from comment 0. Verified as fixed with Firefox Developer edition 47.0a2 (Build ID: 20160415004038) Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Verified as fixed with Firefox Nightly 48.0a1 (Build ID: 20160415030231) Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 As this bug is also verified on Ubuntu(Comment 18), I am marking this as verified!
You need to log in before you can comment on or make changes to this bug.