From: Jeff Gilbert Debugging showed this is a problem with loading music.mp3, perhaps due to a difference in the default for <audio>'s preload attribute. (Specifically, this is not a WebGL issue, though WebGL changes may have altered timing?) While debugging it, I reloaded the mp3 request, and now it's working even when shift-reloading the page. I suspect this bug may be interplay between our defaults and our resource cache. Load up the following demo: http://leon196.github.io/NaturallyUndead/ It's very reproducible on nightly on windows.
I cannot reproduce it on Linux. Honza, could you give it a try on Windows?
Assignee: nobody → honzab.moz
Martin, I'm sorry, but the description of the problem is a bit vague. I'm checking with an m-c debug build on Win10. First visit to the page worked well. Reload (F5) during the same session worked well. Load in a new session worked well. Can you please provide more detailed STR?
OK, an optimized build is stuck on "assets loading..." with a fresh profile. Going to study the log.
I can see load for http://leon196.github.io/NaturallyUndead/assets/music.mp3 being done twice, shortly in a row. Both channels are canceled after receiving some 5k of data with NS_ERROR_PARSED_DATA_CACHED. This is definitely something in the DOM media loading code. Network parts behave as expected/instructed. Also, this isn't an HTTP cache bug. STR in detail: - Win (I have tested on 10), faster machine - optimized build or a nightly official installation - fresh profile - go to http://leon196.github.io/NaturallyUndead/ Reproduced: stuck on "assets loading..." forever. Expected: the page shows an animation, music plays.
Component: Networking → DOM
Summary: Network stalls on media asset request → Network stalls on media asset request, channel canceled with NS_ERROR_PARSED_DATA_CACHED
baku, looks like maybe some XHR-related stall?
It seems a MediaResource bug.
Flags: needinfo?(amarchesini) → needinfo?(padenot)
This is HTMLMediaElement, not Web Audio.
Flags: needinfo?(padenot) → needinfo?(ajones)
Note that I was not able to reproduce in a debug build. Maybe hunt for a code inside MOZ_ASSERT or #if DEBUG?
JW - can you take a look at this one?
Component: DOM → Audio/Video: Playback
Flags: needinfo?(ajones) → needinfo?(jwwang)
Can't repro it on my Windows VM. Can you run with `MOZ_LOG=MediaDecoder:4,nsMediaElement:4` and upload the logs? Thanks!
Flags: needinfo?(jwwang) → needinfo?(honzab.moz)
Created attachment 8796606 [details] MediaDecoder:4,nsMediaElement:4,sync logs #1 (both child and parent for completeness, but I assume you are only interested in the child log)
This is a bug of the site script which waits for the 'canplay' event to finish loading assets. It should set preload=auto to ensure 'canplay' will be fired. Otherwise, the default value for preload is 'metadata' on firefox (note the default value could be different on different user agents) which will just load enough data to decode metadata and doesn't guarantee 'canplay' will be fired.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
(In reply to Honza Bambas (:mayhemer) from comment #11) > Created attachment 8796606 [details] > MediaDecoder:4,nsMediaElement:4,sync logs #1 > > (both child and parent for completeness, but I assume you are only > interested in the child log) Thanks for the logs. Per comment 12, this is a bug of the site script.
Resolution: INVALID → FIXED
Then why FIXED and not INVALID?
I don't know why comment 13 changed INVALID to FIXED. might be an accident...
Resolution: FIXED → INVALID
You need to log in before you can comment on or make changes to this bug.