1475681 - Page CSP can break seeking to unbuffered position (in mp3 playback)

Status: REOPENED

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

Description

[Trevor Rowbotham [:rowbot]]

STR:
1) Visit the URL at [1]
2) Seek to an unbuffered position.

The playback stops and cannot be resumed. Bug 1190558 looks similar, but that seemed to be about Android.

[1] https://trowbotham.com/bug_tests/4159_1332269164.mp3

Comment 1

[Trevor Rowbotham [:rowbot]]

Looks like this regressed 2015-10-27, unfortunately mozregression wasn't able to narrow it down any further:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e8c7dfe727cd970e2c3294934e2927b14143c205&tochange=9a8f2342fb3116d23989087e026448d38a3768c5

Comment 2

[Pascal Chevrel:pascalc]

I can also reproduce this bug in a current nightly, Jean-Yves is that something that falls into your bucket?

Comment 3

[Jean-Yves Avenard [:jya]]

:janh is this something you could look into?

thank you

Comment 4

[Jan Henning [:JanH]]

I can take an initial look.

Comment 5

[Trevor Rowbotham [:rowbot]]

Hi Jan,

Thanks investigating this and for filing bug 1479516. I quickly tested a change in my .htaccess file to unset the Content-Security-Policy header when loading a file with a .mp3 extension and that resolved the issue I reported in this bug, I'll go ahead and close this bug. I reverted the change, however, so that it may be of use in resolving bug 1479516.

Comment 6

[Jan Henning [:JanH]]

Yes, I was going to write that this was presumably caused by your CSP [1], however our behaviour here might still be worth investigating, as it's a bit strange that the initial load (or any loads from the disk cache, provided we manage to download the whole file and store it there) succeeds, but additional requests caused by seeking to outside of the currently buffered range are then blocked by the CSP.

Someone other than me needs to decide what our behaviour here should be and then take this further, though, so unassigning myself again.

For completeness, these are the CSP headers sent by your server:
> block-all-mixed-content; connect-src 'self'; default-src 'none'; font-src 'self' https://cdnjs.cloudflare.com; img-src 'self'; script-src 'self' 'unsafe-inline' https://ajax.googleapis.com https://www.google-analytics.com; style-src 'self' https://ajax.googleapis.com https://cdnjs.cloudflare.com; report-uri https://trowbotham.report-uri.io/r/default/csp/enforce

[1]:
> Content Security Policy: The page’s settings blocked the loading of a resource at https://trowbotham.com/bug_tests/4159_1332269164.mp3 (“default-src”).

Comment 7

[Trevor Rowbotham [:rowbot]]

The media type here is likely irrelevant. I was using a snippet of code from the HTML5 Boilerplate Project (H5BP) to handle when not to send the CSP header. The list at [1] are the file extensions for which the CSP header is not sent [2], on my server at any rate, and likely any other server that uses the H5BP.

I would have to agree that this requires some more investigation. Having the browser's built-in pages affected by a site's CSP seems wrong to me.

[1] https://github.com/h5bp/server-configs-apache/blob/master/src/files_match_pattern
[2] https://github.com/h5bp/server-configs-apache/blob/master/src/security/content-security-policy.conf

Comment 8

[Trevor Rowbotham [:rowbot]]

Oops, didn't mean to remove the dependency.

Comment 9

[Trevor Rowbotham [:rowbot]]

Sigh... sorry for the bug spam. Meant to be depends on.

Comment 10

[David Durst [:ddurst]]

If this is similar to bug 1190558, this is still on our regression radar. Nils, is this actively being looked at?

Comment 11

[Jean-Yves Avenard [:jya]]

(In reply to Jan Henning [:JanH] from comment #6)
> Yes, I was going to write that this was presumably caused by your CSP [1],
> however our behaviour here might still be worth investigating, as it's a bit
> strange that the initial load (or any loads from the disk cache, provided we
> manage to download the whole file and store it there) succeeds, but
> additional requests caused by seeking to outside of the currently buffered
> range are then blocked by the CSP.
> 
this is due to the media cache layer between the demuxer and the HTTP resource.

the media cache download continuously by block of 32kB regardless of how much the demuxer is requesting.
Even when you seek in the resource, the Media Cache may decide to continue the current download and provide that range. Downloading continuously to get to where we wanted is often less expensive than opening a new http request.

Comment 12

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 13

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 14

[Nils Ohlmeier [:drno]]

Declaring NI bankruptcy.