Issue metadata
Sign in to add a comment
|
issues with the protocol behavior of about:blank iframes
Reported by
lahat....@gmail.com,
Mar 20 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36 Steps to reproduce the problem: There are two issues with how the protocol of empty iframes works which I think require improvement. Relative protocol in nested empty iframes: --------------------------- 1. Create an iframe with about:blank src. 2. Create an iframe with about:blank src inside the above mentioned empty iframe. 3. Add a resource to the nested empty iframe with a relative path, for example: <script src="//resource.com/script.js"></script> The script will not load because it will inherit the protocol from the parent empty iframe resulting in about://resource.com/script.js history.pushState stopped working in empty iframe (I think since chrome 45): --------------------------- Empty iframes are used in many cases to isolate the load of external resource from the page while allowing them some access and visibility, for example adverts, videos, etc. Many of those third parties use the following check to decide the type of protocol they should use: var domain = window.location.protocol == "https:" ? "secure.domain.com" : "non-secure.domain.com". In empty iframes running in SSL pages the above will result in the non secure domain. In the past the solution for this problem was: history.replaceState({}, null, window.parent.location.href); I understand the reasoning behind why this was disabled, but is there a way to solve this? I don't believe this is a rare situation and when using third parties there's no way to fix this without them fixing their implementation. What is the expected behavior? What went wrong? Wrong protocol Did this work before? Yes Chrome 44 and below Chrome version: 49.0.2623.75 Channel: stable OS Version: OS X 10.11.0 Flash Version: Shockwave Flash 21.0 r0
,
Mar 21 2016
Attached is a test page that demonstrates the two issues.
Re:second issue, a suggestion could be an iframe attribute or a sandbox option that tells the iframe to have the same location as it's parent, something that will have the same effect as:
history.replaceState({}, null, window.parent.location.href);
,
Mar 22 2016
Thank you for providing more feedback. Assigning to requester "tkonchada@chromium.org" for another review. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 26 2016
Tested the same on mac 10.11 chrome version 50.0.2661.87 - observed the output as shown in the screenshot Could you please let us know what should be the expected output.
,
Apr 26 2016
Thank you for following up on the issue. For the first scenario I would expect that in nested empty iframes relative protocols would continue to inherit the topmost relevant protocol. Example: I'm on https://website.com, an about:blank iframe and another about:blank iframe in it and then a script tag pointing to "//domain.com/script.js". Current: Chrome will attempt to load about://domain.com/script.js Expected: Chrome will attempt to load https://domain.com/script.js what about history.replaceState which stopped working on empty iframes?
,
Apr 26 2016
Thank you for providing more feedback. Adding requester "tkonchada@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 26 2016
,
Apr 28 2016
,
Jul 29 2016
Firefox and Edge uses the top-level document URL as the base of relative URLs in the nested IFRAME. Safari has the same behaivor as Chrome. https://html.spec.whatwg.org/multipage/infrastructure.html#fallback-base-url > 2. If document's URL is about:blank, and document's browsing context has a creator browsing context, then return the creator base URL. https://html.spec.whatwg.org/multipage/embedded-content.html#the-iframe-element:the-iframe-element-6 > When an iframe element is inserted into a document that has a browsing context, the user agent must create a new browsing context, set the element's nested browsing context to the newly-created browsing context, and then process the iframe attributes for the "first time". It's unclear if we should make the former browsing context a creator browsing context of the new one. Maybe we should file a spec bug to clarify it.
,
Jul 29 2016
As for history.replaceState(), would you file a new issue please?
,
Jul 27 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tkonch...@chromium.org
, Mar 21 2016Labels: Needs-Feedback