<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Scripts with protocol-relative URLs fail to load in about:blank"
href="https://bugs.webkit.org/show_bug.cgi?id=145692#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Scripts with protocol-relative URLs fail to load in about:blank"
href="https://bugs.webkit.org/show_bug.cgi?id=145692">bug 145692</a>
from <span class="vcard"><a class="email" href="mailto:x@jx0.co" title="Jon <x@jx0.co>"> <span class="fn">Jon</span></a>
</span></b>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>