arni2033 Reporter
	Description • 9 years ago

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

	arni2033 Reporter
	Comment 1 • 9 years ago

I changed my mind:   the additional case may be a part of bug 1225000, not this one

	Andrea Marchesini [:baku] Assignee
	Comment 2 • 9 years ago

If we have an error, we are not playing. Is this assumption correct?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 3 • 9 years ago

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.

	Andrea Marchesini [:baku] 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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 5 • 9 years ago

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!

	Pulsebot
	Comment 6 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/a9ca2bcc8633

	Phil Ringnalda (:philor)
	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.

	Jean-Yves Avenard [:jya]
	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.

	arni2033 Reporter
	Comment 9 • 9 years ago

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?

	Andrea Marchesini [:baku] Assignee
	Comment 10 • 9 years ago

What about if I disable the test(s) for Mulet for now?

	Phil Ringnalda (:philor)
	Comment 11 • 9 years ago

Bug 1223394 is fixed, I wouldn't expect that you would need to now.

	Pulsebot
	Comment 12 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/24c0074052e6

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 13 • 9 years ago

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/eaa63e3f2707 at Baku's request for mulet bustage.

	Andrea Marchesini [:baku] 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.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 15 • 9 years ago

I'm confused. If audio output fails, why would that trigger a media element error? AFAIK it shouldn't.

	Pulsebot
	Comment 16 • 8 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/d4b6ebed9c48

	Carsten Book [:Tomcat]
	Comment 17 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/d4b6ebed9c48

	Khalid Syfullah Zaman [:khalid32]
	Comment 18 • 8 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

	Saheda Reza [:Antora]
	Comment 19 • 8 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]

	Edgar
	Comment 20 • 8 years ago

I also reproduce this bug. Bug's fixed.
QA Whiteboard:[bugday-20160309][good first verify][testday-20160325]→[testday-20160401]

	Andrea Marchesini [:baku] Assignee
	Comment 21 • 8 years ago

I'm lost. Is this bug fixed or not?

	Mayur Patil
	Comment 22 • 8 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.

	Mohammad Maruf Islam
	Comment 23 • 8 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!