1299609 - Network stalls on media asset request, channel canceled with NS_ERROR_PARSED_DATA_CACHED

Status: RESOLVED INVALID

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

Description

[Martin Best (:mbest)]

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.

Comment 1

[Michal Novotny [:michal]]

I cannot reproduce it on Linux. Honza, could you give it a try on Windows?

Comment 2

[Honza Bambas (:mayhemer)]

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?

Comment 3

[Honza Bambas (:mayhemer)]

OK, an optimized build is stuck on "assets loading..." with a fresh profile.  Going to study the log.

Comment 4

[Honza Bambas (:mayhemer)]

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.

Comment 5

[Andrew Overholt [:overholt]]

baku, looks like maybe some XHR-related stall?

Comment 6

[Andrea Marchesini [:baku]]

It seems a MediaResource bug.

Comment 7

[Paul Adenot (:padenot)]

This is HTMLMediaElement, not Web Audio.

Comment 8

[Honza Bambas (:mayhemer)]

Note that I was not able to reproduce in a debug build.  Maybe hunt for a code inside MOZ_ASSERT or #if DEBUG?

Comment 9

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

JW - can you take a look at this one?

Comment 10

[JW Wang [:jwwang] [:jw_wang]]

Can't repro it on my Windows VM.

Can you run with `MOZ_LOG=MediaDecoder:4,nsMediaElement:4` and upload the logs? Thanks!

Comment 11

[Honza Bambas (:mayhemer)]

Attachment: MediaDecoder:4,nsMediaElement:4,sync logs #1

(both child and parent for completeness, but I assume you are only interested in the child log)

Comment 12

[JW Wang [:jwwang] [:jw_wang]]

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.

Comment 13

[JW Wang [:jwwang] [:jw_wang]]

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

Comment 14

[Honza Bambas (:mayhemer)]

Then why FIXED and not INVALID?

Comment 15

[JW Wang [:jwwang] [:jw_wang]]

I don't know why comment 13 changed INVALID to FIXED. might be an accident...