777526 - History API throws nasty exception when used within an iframe (with no src)

Status: RESOLVED DUPLICATE of bug 957479

(Core :: DOM: Navigation, defect)

Description

[Remy Sharp]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11

Steps to reproduce:

I have a live example of this failing, but wanted to also explain the type of iframe:

var f = document.createElement('iframe');
document.body.appendChild(f);
var doc = f.contentDocument;
doc.open();
doc.write(SOME_HTML_AND_JS);
doc.close();

If the contents of that iframe tries to use the history API to pustState or replaceState it throws an exception.

Here's the live example: http://jsbin.com/okocap/5/edit?javascript,live


Actual results:

Exception


Expected results:

No exception.

Not sure how it should affect the iframe to be completely honest, but I tested this in other browsers and there's no error.

However, I can't say that the documentation for the history api inside of anonymous iframes explains what the right behaviour is or not...

Comment 1

[Remy Sharp]

Sorry - by "Actual results: exception" - I meant to include this screenshot: http://i.imgur.com/MaVk3.png (message can be seen there properly).

Comment 2

[Paul Rouget [:paul]]

Attachment: test case

I can reproduce in JSBin, but not in a this test case.

Rem, can you take a look at this attachment?

Comment 3

[Paul Rouget [:paul]]

Well, now it fails as described in comment 0. (I have, at first, tested with a file:// URL).

Comment 4

[Remy Sharp]

Paul - your attachment fails for me - but also, oddly, the throbber continues and never stops: http://i.imgur.com/vuiRT.png

Comment 5

[Boris Zbarsky [:bzbarsky]]

The throbber never stops because the testcase calls document.open() without calling document.close.

The pushState fails presumably because it's trying to operate on about:blank, but someone should look into that part.

Comment 6

[Steven Downum]

If you still need help, I will take this one.

Comment 7

[Justin Lebar (not reading bugmail)]

I'd start by reproducing the error in a debug build of Firefox and seeing what's causing the error.  The suspicion is that nsDocShell::AddState (which implements history.pushState and replaceState) is doing something wrong.

I'd also compare our behavior to other browsers', because throwing an exception is not necessarily wrong.

Comment 8

[Steven Downum]

Sounds good - I started digging into nsDocShell earlier. I ran the test case on Chromium, Safari and IE 10 after I read the bug report. These browsers do not throw an exception on the code, but the Nightly build and FF 15 always do. I'm making a fresh debug build and will look at it some more in the morning.

Comment 9

[Steven Downum]

When the iframe invokes nsDocShell::AddState in this case, there is a security check where the current URI and the new URI being pushed have the same origin. In this case the userpass data for each URL is being tested, however the userpass data for the iframe URI (mCurrentURI) is empty and the following call fails:

NS_ENSURE_SUCCESS(mCurrentURI->GetUserPass(currentUserPass),
                              NS_ERROR_FAILURE)

Removing this check results in a successful history.pushState call from the iframe. The failure is bubbling up from the nsStandardURL::GetUserPass call.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yes, GetUserPass is expected t fail on about:blank (and in particular, that is NOT an nsStandardURL).

We should check the spec to make sure what should happen here in the about:blank case... and maybe get it changed if needed.

Comment 11

[Justin Lebar (not reading bugmail)]

As far as I can tell, the spec [1] says we should let pushState run, unless you pass a URL to pushState, in which case it should fail because about:blank is not a hierarchical URL (see note at the very bottom of step 2).

That matches our behavior when I play with the testcase in comment 0.  It also seems relatively sane to me.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-pushstate

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, yes.  The original testcase does pass a URL.  There's just no way to make that work...  Throwing an exception seems perfectly reasonable in this case.

Comment 13

[christoph.burgmer]

Attachment: Variation of the initial test case that simply changes the hash part and outputs the resulting location.href

Documents embedded through the new `srcdoc` attribute suffer the same limitations.


I am trying to understand the specs here. When I look at http://www.w3.org/TR/2010/WD-html5-20101019/the-iframe-element.html#attr-iframe-srcdoc I read "Any navigation required of the user agent in the 'process the iframe attributes' algorithm must be completed with the iframe element's document's browsing context as the source browsing context."

With my limited understanding of the spec, I interpret this loosely as "use the parent's URL". This is what Chrome seems to be doing. In the attached testcase Chrome will output the parent's URL with the added hash part, and so does Firefox if opening through file://

From the user's perspective this bug keeps you from opening any serious single page app depending on hash change for internal state.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Olli, do you have time to sort through the spec here?

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

(In reply to christoph.burgmer from comment #13)
>  I read "Any navigation required of the user agent in the
> 'process the iframe attributes' algorithm must be completed with the iframe
> element's document's browsing context as the source browsing context."

I don't see how that is relevant there. We aren't in 'process the iframe attributes'.

But reading the spec some more...

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

Hmm, I can't get any exception in the testcases.

And if I read the spec correctly, pushState should work.
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-pushstate

Comment 17

[Boris Zbarsky [:bzbarsky]]

Looks like the behavior on the minimal testcase changed in this range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=12d3ba62a599&tochange=34dddf6f7ec1

And in particular looks like we fixed this for the testcases reported (but NOT per the summary, afaict) in bug 957479.