Closed
Bug 869632
Opened 12 years ago
Closed 12 years ago
crash loading shoutcast stream
Categories
(Core :: Audio/Video, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 824877
People
(Reporter: rillian, Unassigned)
References
()
Details
(Keywords: crash, stackwanted)
User reports loading shoutcast mp3 streams in the <audio> element on up-to-date Windows Server 2012 crashes the browser. It is important to add a semicolon to the end of the url so the server reports Content-Type: text/plain instead of audio/mpeg.
Forked from https://bugzilla.mozilla.org/show_bug.cgi?id=862088#c18
Reporter | ||
Comment 1•12 years ago
|
||
Spender, can you confirm you see the crash on http://people.mozilla.org/~rgiles/2013/shoutcast.html ? This is a rough copy of your example.
I just get '"Content-Type" of "text/plain" is not supported. Load of media resource failed.' on Windows 7 with Firefox 20.0.1.
Comment 2•12 years ago
|
||
Please provide the crash ID from the about:crashes page.
Comment 3•12 years ago
|
||
Giles, there's been a little bit of confusion about what set of circumstances causes which problem.
With Shoutcast (as per the demo you posted above), I get "load failed" because of (I believe) a sniffing failure. Hopefully this has been noted for https://bugzilla.mozilla.org/show_bug.cgi?id=862088 . To be clear, in this case, no crash occurs.
If I modify your test case to look at an IceCast stream instead, I reliably crash the browser. By changing the 'src' attr of the audio tag from 'http://206.217.201.136:8016/;' to 'http://94.25.53.133:80/nashe-128-3.mp3', I can reliably crash my browser.
The crash report is here: https://crash-stats.mozilla.com/report/index/d8d9116d-c5b6-48fd-8f06-3dd932130507
As previously stated, I'm on the release channel ATM, so perhaps this is already fixed. I'll check later.
Flags: needinfo?(giles)
Comment 4•12 years ago
|
||
(In reply to spender from comment #3)
> https://crash-stats.mozilla.com/report/index/d8d9116d-c5b6-48fd-8f06-
> 3dd932130507
> As previously stated, I'm on the release channel ATM, so perhaps this is
> already fixed. I'll check later.
It's bug 824877 fixed in 21.0. Does it happen in Nightly?
Flags: needinfo?(giles)
Comment 5•12 years ago
|
||
(In reply to spender from comment #3)
> With Shoutcast (as per the demo you posted above), I get "load failed"
> because of (I believe) a sniffing failure. Hopefully this has been noted for
> https://bugzilla.mozilla.org/show_bug.cgi?id=862088 . To be clear, in this
> case, no crash occurs.
Comment 1 notes the mime type is sent as text/plain. Even if we sniffed the type of MP3 file correctly in bug 862088 we still wouldn't sniff this stream as we don't sniff text/plain.
Reporter | ||
Comment 6•12 years ago
|
||
I can't reproduce on Windows 7 with firefix 20.0.1 or Aurora. Spender?
Flags: needinfo?(giles)
Reporter | ||
Comment 7•12 years ago
|
||
(In reply to spender from comment #3)
> With Shoutcast (as per the demo you posted above), I get "load failed"
> because of (I believe) a sniffing failure. Hopefully this has been noted for
> https://bugzilla.mozilla.org/show_bug.cgi?id=862088 . To be clear, in this
> case, no crash occurs.
Aha, sorry for the confusion. Yes, that's more releated to bug 862088. Sounds like that's working as intended.
> If I modify your test case to look at an IceCast stream instead, I reliably
> crash the browser. By changing the 'src' attr of the audio tag from
> 'http://206.217.201.136:8016/;' to 'http://94.25.53.133:80/nashe-128-3.mp3',
> I can reliably crash my browser.
Ok, I made a new test case at http://people.mozilla.org/~rgiles/2013/icecast-crash.html Please verify this crashes for you with the release, but if fixed with Nightly or Aurora.
Comment 8•12 years ago
|
||
Verfied fixed in current nightly.
Reporter | ||
Comment 9•12 years ago
|
||
Excellent, thanks!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•