Closed
Bug 1224936
Opened 9 years ago
Closed 9 years ago
Sound indicator is displayed after video stops because of network error
Categories
(Firefox :: Tabbed Browser, defect)
Firefox
Tabbed Browser
Tracking
()
VERIFIED
FIXED
Firefox 46
People
(Reporter: arni2033, Assigned: baku)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
361.33 KB,
image/png
|
Details | |
2.14 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
>>> 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.
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → amarchesini
I changed my mind: the additional case may be a part of bug 1225000, not this one
Assignee | ||
Comment 2•9 years ago
|
||
If we have an error, we are not playing. Is this assumption correct?
Attachment #8687900 -
Flags: review?(roc)
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.
Attachment #8687900 -
Flags: review?(roc)
Assignee | ||
Comment 4•9 years ago
|
||
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 #8687900 -
Attachment is obsolete: true
Attachment #8688184 -
Flags: review?(roc)
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!
Flags: needinfo?(jyavenard)
Comment 7•9 years ago
|
||
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
Comment 8•9 years ago
|
||
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.
Flags: needinfo?(jyavenard)
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?
Assignee | ||
Comment 10•9 years ago
|
||
What about if I disable the test(s) for Mulet for now?
Flags: needinfo?(philringnalda)
Comment 11•9 years ago
|
||
Bug 1223394 is fixed, I wouldn't expect that you would need to now.
Flags: needinfo?(philringnalda)
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/eaa63e3f2707 at Baku's request for mulet bustage.
Flags: needinfo?(amarchesini)
Assignee | ||
Comment 14•9 years ago
|
||
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.
Flags: needinfo?(roc)
Comment 17•9 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d4b6ebed9c48
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox47:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 46
Comment 18•9 years ago
|
||
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]
status-firefox48:
--- → verified
Updated•9 years ago
|
QA Whiteboard: [bugday-20160309] → [bugday-20160309] [good first verify]
Comment 19•9 years ago
|
||
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]
Updated•9 years ago
|
QA Whiteboard: [bugday-20160309] [good first verify] → [bugday-20160309] [good first verify][testday-20160325]
Comment 20•9 years ago
|
||
I also reproduce this bug. Bug's fixed. QA Whiteboard:[bugday-20160309][good first verify][testday-20160325]→[testday-20160401]
Flags: needinfo?(amarchesini)
Comment 22•9 years ago
|
||
[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.
Comment 23•9 years ago
|
||
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!
Status: RESOLVED → VERIFIED
QA Whiteboard: [bugday-20160309] [good first verify][testday-20160325] → [bugday-20160309] [good first verify][testday-20160325][testday-20160415]
You need to log in
before you can comment on or make changes to this bug.
Description
•