See the bug report for the same issue in Chrome, presumably in shared WebKit code: https://code.google.com/p/chromium/issues/detail?id=496814 Example URL: http://viajon.net/test/protocol_relative_test.html Steps to reproduce the problem: 1. Click "Load Protocol-Relative Script" button to see the issue. 2. You can click the http or https (need to accept self-signed cert first) versions of the button to see the script loading working. What is the expected behavior? The script should load and run properly. What went wrong? When a script tag is loaded with a protocol-relative URL inside of two friendly iframes, the load fails. Specifying an explicit scheme causes the load to succeed. For example: <iframe id="outer"> <iframe id="inner"> <script src="//domain.com/script-to-load.js"></script> </iframe> </iframe> The script-to-load.js file is never downloaded and run.
What happens here is that the frame you add the <script> element to is about:blank, and about://domain.com/script-to-load.js obviously isn't going to load. I'm surprised that this works in Firefox somehow.
My understanding is that about:blank is not a valid "fallback base URL", and the behavior described by the HTML spec involves tracing back through parent browsing contexts until a non-about base URL is found. https://html.spec.whatwg.org/multipage/infrastructure.html#fallback-base-url Since the address of the inner iframe is "about:blank", to find the fallback base URL, we take the document base URL of its creator browsing context (the outer iframe). The document base URL of the outer iframe is just its fallback base URL, which likewise, is the document base URL of the top browsing context. So when parsing the protocol-relative URL of the script tag inside the inner iframe, we should be using the base URL of the top window in this case (and therefore deriving the proper scheme from there).
Interesting. That's quite strange, as this is a pretty unique place in the spec, I don't know if anything else behaves this way. Perhaps we should try to get the spec simplified.
I think the spec as written describes generally helpful behavior. The "promise" of a protocol-relative URL is that you can address content which can be served via either http or https and have things "just work". Which to my mind, ideally means using the protocol of the closest containing browsing context which actually addresses remote (or local in the case of file:) content. Specifically, you'd get a mixed content warning if you loaded an http resource inside an https iframe, even if there are several friendly iframes contexts in the middle. The implicit assumption is that the friendly iframes have "inherited" the https context in some sense. Either way though, the current behavior is at least inconsistent. A script with a protocol-relative URL loaded in a single friendly iframe doesn't pick up the about: protocol. So there is some idea in that case that about:blank is not a useful base URL. It's only if the next containing browsing context happens to also be about: that we end up hitting this issue.