Chrome prevents HTML import for local files (e.g. Polymer)
Reported by
xpb...@gmail.com,
Jun 21 2016
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36 Example URL: Only occurs with local files Steps to reproduce the problem: 1. Write an HTML page importing another using, as an example: <link rel="import" href="bower_components/polymer.html"> 2. Try to load the page locally in Chrome What is the expected behavior? The page would import the Polymer elements properly. What went wrong? "Imported resource from origin 'file://' has been blocked from loading by Cross-Origin Resource Sharing policy: Invalid response. Origin 'null' is therefore not allowed access." "file://" seems like it doesn't have a "known" origin so the security policy prevents it. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 51.0.2704.84 Channel: stable OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 22.0 r0 This works as expected in all other browsers. I don't see why a local set of HTML files cannot reference a single set of imports. The entire point of the import protocol is to reduce code redundancy. Yes, Vulcanization of the local pages would work... But then each page would be bloated by the imports. I'm possibly looking at a thousand different pages all referencing the same Polymer imports.
,
Jun 23 2016
I think this is working as intended, as it's a security issue to load things from file:// I work around this by running a local server: python -m SimpleHTTPServer Then open localhost:8000 and your imports should work. (For triaging purposes I'm closing this as WontFix to clear it out of the main bug queue, but I don't mean to shut down discussion on this bug. Feel free to comment.)
,
Jun 24 2016
I understand the security concerns with cross-site references. (A malicious site could easily try to reference and steal files on your local machine.) However, I don't understand when it's from file:// to file://. If someone has access to the local filesystem, I think you have bigger security worries than them utilizing Chrome. Yes, I understand there's a workaround in that you can run a lightweight server, but my entire goal is to eliminate the need for any user to have to install anything (because government IT tends to make things difficult). I've developed a site using GWT and Polymer (both Google products, which makes this especially ironic) for hosting over an RNDIS connection (which requires a driver) but I'd also like to deliver the same content available over mass storage (which doesn't require any drivers). I really don't want to re-design the entire site just to make it work with a single browser. I suppose I can simply note in the product manual that they need to use a browser other than Chrome.
,
Jun 24 2016
I hear your concerns but this ship sailed a long time ago ( crbug.com/4197 ). I believe most browsers block this to varying degrees. One thing you can try is using the "--allow-file-access-from-files" flag. This is just for testing (you'll get a warning, etc) but it might work for your development workflow. |
||
►
Sign in to add a comment |
||
Comment 1 by xpb...@gmail.com
, Jun 21 2016