620224 - mixed content warning when loading OGG over HTTPS

Status: REOPENED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Stefan]

User-Agent:       
Build Identifier: 

FF 3.5.16 and 3.6.13 issue a mixed content warning when OGG file is loaded via HTTPS. 

Current MF issues warning when OGG over HTTPS is loaded for the second time.

Reproducible: Always

Steps to Reproduce:
1. click on testcase
2. click on testcase again

Actual Results:  
1. mixed content warning shown in FF 3.5/3.6
2. mixec content warning shown in FF 3.5/3.6/current MF.

Expected Results:  
Do not show mixed content warnings.

Comment 1

[Stefan]

Attachment: OGG testcase

Comment 2

[Stefan]

The issue only shows up when the http repsonse header

Accept-Ranges: bytes

is set. bugzilla does not send this header.

Comment 3

[Stefan]

Attachment: longer testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is the media code putting its byte-range requests into the right loadgroup and such?

Comment 5

[Ed Morley [:emorley]]

Do you have a link to an ogg on a server that does send the response in comment 1, so I can test and confirm?

Comment 6

[Stefan]

https://www.vogtner.de/content-disposition

Comment 7

[Ed Morley [:emorley]]

Thanks for the link.

Other than the initial invalid security cert message when viewing the .htm (which I presume is due to you having just set up a quick ssl cert that isn't marked as trusted by a CA), WFM using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110102 Firefox/4.0b9pre ID:20110102030355 in that no mixed content warnings appear at all.

Comment 8

[Stefan]

Detailed STR (needs fresh (!) profile):

1. open URL of Comment 6
2. confirm security exeception (temporarily)
3. click at link to white.ogg
4. wait 3 seconds
5. click reload

Comment 9

[Ed Morley [:emorley]]

Ah new profile due to pressing the "don't show me again" to mixed content warning. Of course, my bad.

Performed the STR in comment 8 with clean profile using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110102 Firefox/4.0b9pre ID:20110102030355 and it shows me the mixed content warning the 1st time, but not subsequent times, which differs from your behaviour on Linux...strange.

Either way, marking as confirmed, since ogg files over https shouldn't be causing mixed content messages surely?

Comment 10

[Matthew Gregan [:kinetik]]

(In reply to comment #4)
> Is the media code putting its byte-range requests into the right loadgroup and
> such?

As far as I can tell, it is.  New channels are created in nsHTMLMediaElement::LoadResource, nsMediaChannelStream::RecreateChannel, and nsMediaChannelStream::CloneData.  All three pass the document's load group to NS_NewChannel.  I verified in GDB that any time these are called they're using the same load group passed in to nsVideoDocument::StartDocumentLoad.

Comment 12

[jeremyjtan]

FYI: 

http://developers.facebook.com/blog/post/497/ (all apps be https on Oct 1)  

This bug will start to affect a lot of users that plays ogg over https.

Comment 13

[Matthew Gregan [:kinetik]]

So, the  bit I missed last time I looked at this is that nsMediaStream::MoveLoadsToBackground removes and readds the stream from the load group when the LOAD_BACKGROUND flag is added, and the mixed content warning happens during the remove:

#2  0x00007ffff5604c40 in nsSecureBrowserUIImpl::OnStateChange (this=0xfe9bf0, aWebProgress=<value optimized out>, 
    aRequest=0x181e880, aProgressStateFlags=65552, aStatus=<value optimized out>)
    at /home/kinetik/mozilla-valgrind/security/manager/boot/src/nsSecureBrowserUIImpl.cpp:1252
#3  0x00007ffff558822b in nsDocLoader::FireOnStateChange (this=0x127ad80, aProgress=0x127ada8, aRequest=0x181e880, 
    aStateFlags=65552, aStatus=0) at /home/kinetik/mozilla-valgrind/uriloader/base/nsDocLoader.cpp:1339
#4  0x00007ffff55886d4 in nsDocLoader::doStopURLLoad (this=0x127ad80, request=<value optimized out>, 
    aStatus=<value optimized out>) at /home/kinetik/mozilla-valgrind/uriloader/base/nsDocLoader.cpp:912
#5  0x00007ffff5589743 in nsDocLoader::OnStopRequest (this=0x127ad80, aRequest=0x181e880, aCtxt=<value optimized out>, 
    aStatus=0) at /home/kinetik/mozilla-valgrind/uriloader/base/nsDocLoader.cpp:696
#6  0x00007ffff4c6f9f8 in nsLoadGroup::RemoveRequest (this=0x127b510, request=0x181e880, ctxt=0x0, aStatus=0)
    at /home/kinetik/mozilla-valgrind/netwerk/base/src/nsLoadGroup.cpp:734
#7  0x00007ffff5333eaf in nsMediaStream::ModifyLoadFlags (this=<value optimized out>, aFlags=536870913)
    at /home/kinetik/mozilla-valgrind/content/media/nsMediaStream.cpp:1236
#8  0x00007ffff5333f65 in nsMediaStream::MoveLoadsToBackground (this=<value optimized out>)
    at /home/kinetik/mozilla-valgrind/content/media/nsMediaStream.cpp:1220

Comment 14

[Stefan]

(In reply to Stefan from comment #6)
> https://www.vogtner.de/content-disposition
moved to
https://www.vogtner.de/mozilla/620224

Comment 15

[Patrick Dark]

I can confirm this issue for Firefox 25 Beta (10?). See https://patrick.dark.name/web.dev/demos/audio.playback.1/ (which doesn't give an untrusted warning like https://www.vogtner.de/mozilla/620224).

The Ogg Vorbis file causes the page to improperly indicate that it's partially encrypted. Playing back the Ogg Vorbis file directly confirms that this is the source of the problem. On the other hand, the MP3 file appears encrypted in Firefox, and the XHTML page appears encrypted without issue in Chrome 30, Internet Explorer 11, and Opera 17. (Of course, Internet Explorer plays the MP3 file instead of the Ogg Vorbis file.)

Comment 16

[Tanvi Vyas[:tanvi]]

This is fixed in bug 947079, but like bug https://bugzilla.mozilla.org/show_bug.cgi?id=1072421, I think bug 947079 is just a bandaid to some other underlying problem.  Since there is never any attempt to make an http request on the previous page or the white.ogg page, there should be nothing to confuse nsSecureBrowserUIImpl into thinking that an insecure load took place.

Comment 17

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.