1287580 - Firefox will not load iframe content if iframe URL is the same as parent frame even when the URL fragments differ

Status: RESOLVED DUPLICATE of bug 1279728

(Core :: DOM: Core & HTML, defect)

Description

[torin.n.francis]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36

Steps to reproduce:

1) Create a trivial single-page app that uses hash based routing
2) Create a target page with a path similar to http://localhost:8080/#/iframe-target
3) Create a parent page containing a single iframe whose src=http://localhost:8080/#/iframe-target (or similar) and give it a path similar to http://localhost:8080/#/parent
4) Navigate to http://localhost:8080/#/parent (or similar)


Actual results:

The iframe was blocked and no indication was given in console as to why it may have been blocked.


Expected results:

The iframe should have been loaded. I understand the attempt to prevent infinite recursion, but URL fragments should be considered when evaluating whether two URLs are equal.

It would also be extremely nice to have some sort of error logged in the console when an iframe is blocked and why it was blocked (like what is done with mixed content iframes). It is quite difficult to determine what exactly is happening in situations like these when they occur in complex environments.

Comment 1

[Andrew Overholt [:overholt]]

Does this work differently in other browsers?

Anne, are we not following the spec?

Comment 2

[torin.n.francis]

Despite the spec https://html.spec.whatwg.org/multipage/embedded-content.html#process-the-iframe-attributes (which seems to have been written at a time when URL fragments were only used for anchors), the above steps produce the expected result in all other browsers.

Comment 3

[torin.n.francis]

(In reply to Andrew Overholt [:overholt] from comment #1)
> Does this work differently in other browsers?
> 
> Anne, are we not following the spec?

And by all other browsers I mean Safari 9, Chrome 51, IE 11, and Edge... 25?

Comment 4

[torin.n.francis]

Sorry to spam, but I would also note that providing some nonsense query string to the iframe src (e.g. http://localhost:8080/?foo=bar#/iframe-target) allows the example to work in firefox. As a query string is certainly provides no more guarantee of a unique page than a URL fragment in practice, it seems rather arbitrary to single out the latter. Perhaps if we assume that only a unique server request can generate a unique page, then it might make sense. Though, of course, that hasn't been the case for at least a decade.