Closed Bug 1224936 Opened 7 years ago Closed 6 years ago

Sound indicator is displayed after video stops because of network error


(Firefox :: Tabbed Browser, defect)

Not set



Firefox 46
Tracking Status
firefox42 --- affected
firefox43 --- affected
firefox44 --- affected
firefox45 --- affected
firefox47 --- verified
firefox48 --- verified


(Reporter: arni2033, Assigned: baku)


(Blocks 1 open bug)



(2 files, 1 obsolete file)

>>> My Info:   Win7_64, Nightly 45, 32bit, ID 20151113030248, new profile <<<
1. Open
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

 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: nobody → amarchesini
I changed my mind:   the additional case may be a part of bug 1225000, not this one
Attached patch error.patch (obsolete) — Splinter Review
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]

Review of attachment 8687900 [details] [diff] [review]:


However, this means you need to call HTMLMediaElement::UpdateAudioChannelPlayingState when mError changes.

This also needs a test.
Attachment #8687900 - Flags: review?(roc)
Attached patch error.patchSplinter Review
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)
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)
Blocks: 1225342
The bad news is, I backed you out in for Mulet Gij failures,

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.
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?
What about if I disable the test(s) for Mulet for now?
Flags: needinfo?(philringnalda)
Bug 1223394 is fixed, I wouldn't expect that you would need to now.
Flags: needinfo?(philringnalda)
Backed out in at Baku's request for mulet bustage.
Flags: needinfo?(amarchesini)
Depends on: 1226815
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)
Has STR: --- → yes
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 46
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]
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
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]
Flags: needinfo?(amarchesini)
I'm lost. Is this bug fixed or not?
Flags: needinfo?(amarchesini)


STR is clear.

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!
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.