Open Bug 1475681 Opened 2 years ago Updated 3 months ago
Page CSP can break seeking to unbuffered position (in mp3 playback)
STR: 1) Visit the URL at  2) Seek to an unbuffered position. The playback stops and cannot be resumed. Bug 1190558 looks similar, but that seemed to be about Android.  https://trowbotham.com/bug_tests/4159_1332269164.mp3
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
Has Regression Range: --- → yes
I can also reproduce this bug in a current nightly, Jean-Yves is that something that falls into your bucket?
:janh is this something you could look into? thank you
Flags: needinfo?(jyavenard) → needinfo?(jh+bugzilla)
I can take an initial look.
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.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
Yes, I was going to write that this was presumably caused by your CSP , 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 : > Content Security Policy: The page’s settings blocked the loading of a resource at https://trowbotham.com/bug_tests/4159_1332269164.mp3 (“default-src”).
Assignee: jh+bugzilla → nobody
Status: RESOLVED → REOPENED
Priority: P2 → --
Resolution: WORKSFORME → ---
Summary: Seeking to unbuffered position breaks playback on mp3 → Page CSP can break seeking to unbuffered position breaks playback on mp3
Summary: Page CSP can break seeking to unbuffered position breaks playback on mp3 → Page CSP can break seeking to unbuffered position (in mp3 playback)
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  are the file extensions for which the CSP header is not sent , 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.  https://github.com/h5bp/server-configs-apache/blob/master/src/files_match_pattern  https://github.com/h5bp/server-configs-apache/blob/master/src/security/content-security-policy.conf
Oops, didn't mean to remove the dependency.
If this is similar to bug 1190558, this is still on our regression radar. Nils, is this actively being looked at?
(In reply to Jan Henning [:JanH] from comment #6) > Yes, I was going to write that this was presumably caused by your CSP , > 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.
Webcompat Priority: --- → ?
Priority: P2 → P3
Whiteboard: [webcompat] → [webcompat] [media-playback]
You need to log in before you can comment on or make changes to this bug.