Open Bug 1432022 Opened 7 years ago Updated 3 years ago

Add option for <embed> media in local html file to work

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Version:
52 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: luweitest, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20171226003912 Steps to reproduce: Open a local htm file with content: <html><head></head><body> <embed src=test.mp3 height="16" width="200" autoplay="true" PLUGINSPAGE="http://www.apple.com/quicktime/download/"></embed> </body></html> Actual results: Firefox shows a blank page and nothing is heard. Expected results: If the file is on a http server, Firefox can show a play control and test.mp3 is played. If local and remote file have different plugin activation settings (I feel it unlikely because local file should be considered safer), then there should be an alert like "blocked content" and let people choose to activate.
Component: Untriaged → Audio/Video
Product: Firefox → Core
Component: Audio/Video → Audio/Video: Playback
Thanks for your report. Playback often doesn't work properly for file:// urls because of cross-origin protections. This seems to be something of an edge case. It works for me if I use an <audio> tag instead of an <embed>. If you need a fallback, you can put the <embed> inside the <audio> and browsers which support the html5 element won't show it, while older clients will skip the html5 element instead.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Priority: -- → P3
Resolution: --- → INVALID
I think this has nothing to do with cross-origin protections. I removed PLUGINSPAGE tag like this: <html><head></head><body> <embed src="test.mp3" height="36" width="200"></embed> </body></html> And it still does not play. <audio> tag does work, but it's irrelevant to this bug. <embed> is in HTML5 standard, and should be supported, regardless local or remote. In fact the origin page I encountered is a remote one. I downloaded it for local access, but found it break -- hence this bug report. There's hundreds of pages and you can't request a normal user editing them one by one, right?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: embed media in local htm file not work → Add option for <embed> media in local html file to work
Cross-origins protections apply to file:// urls. That can be helpful, for example, to prevent a page you've loaded fetching and uploading sensitive files from your local machine. In general, I think we treat each file:// resource as a separate origin. Likely <embed> is blocked while <audio> is not because we have different default policies for 'object-src' vs 'media-src'. Anne, is there spec'd behaviour for this somewhere? I wasn't able to find anything.
Flags: needinfo?(annevk)
There are no definitive specifications for file: URLs as they're not really web observable (bits that are such as parsing are defined). It seems a little strange for file: URL <embed> to just be blocked for all resources. I can see blocking plugins, but everything else that works in <iframe>, <img>, et al could work there too. Having said that, <embed> is a bit of a mess (including in the standard), so I can someone opting for disabling it just in case.
Flags: needinfo?(annevk)
Ok, thanks, Anne.
As long as there's need for local stored html files, <embed> tag should work as an option; or else how do I deal with those hundred of files?
Usually people run a local http server to test against local files.
(In reply to Ralph Giles (:rillian) | needinfo me from comment #7) > Usually people run a local http server to test against local files. That's what I did to confirm the bug before reporting. But that's not an option for a normal user; he might just open IE and find IE works fine.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.