iframe.contentDocument on same domain returns null after form is submitted
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
People
(Reporter: joubran.jad, Unassigned)
Details
Attachments
(1 file)
781 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36
Steps to reproduce:
Create an iframe on the same origin (iframe with no src)
access the iframe's contentDocument and set the contentDocument.body.innerHTML to:
<form>
<input type="text" />
<input type="submit" />
</form>
Then submit the form (without having an event.preventDefault()
on submit).
After the form is submitted, the iframe becomes in an unusable state as iframe.contentDocument
starts to return null
. (even if you try to re-assign it's innerHTML)
I'm not getting that issue on Chrome & Safari.
Actual results:
iframe.contentDocument returns null
Expected results:
It could be that the same-origin is failing for the iframe after the form is submitted, but I'm not sure.
I'd expect it to be usable even after submit (if that makes sense according to the spec)
I can definitely put a reproduction case, but first wanted to make sure this is not a duplicate or a wont fix.
Thanks!
Comment 1•5 years ago
|
||
Hi Jad,
Thanks for submitting this bug to us.
I need a favour from you: would you be so kind to create an environment for us to test this? This will be very helpful.
Thanks!
Sebastian
Reporter | ||
Comment 2•5 years ago
|
||
To reproduce the issue:
Open dev tools console
Click on log iframe contentDocument
and see it work
Then using your mouse, click on the Submit button (which is inside the iframe)
then click on log iframe contentDocument
again and it will be null
Reporter | ||
Comment 3•5 years ago
|
||
Sure thing!
I was able to make reproduce the issue! I've attached a minimum reproduction case here, not that with this case the behaviour of Safari & Firefox is aligned while chrome is not.
But I'm not sure which browser is following the spec and which one is not
let me know if I should open this issue against another browser
Thanks!
Comment 4•5 years ago
|
||
Hello Jad,
Thanks for your help! With this I was able to reproduce it using 72.0a1 (2019-10-23) (64-bit) and Firefox 70.0 (64-bit) on macOS Mojave 10.14.4
I'm going to add a Product and a Component for this.
Thanks!
Sebastian
Comment 5•5 years ago
|
||
Yeah, we agree with Safari, might be a bug in Chrome, not sure...
Definitely not a layout bug though, so moving to a hopefully more appropriate component :)
Comment 6•5 years ago
|
||
So for about:srcdoc the document's URL is about:srcdoc (user agents agree on this). A form without action uses that URL as navigation destination. Navigating to that URL results in a network error. Network errors ought to be cross-origin, which would mean contentDocument returns null.
I'd say this is a bug in Chrome.
Comment 7•5 years ago
|
||
A form without action uses that URL as navigation destination
Not quite, in Chrome (and for that matter not in Safari). They both try to load "about:scrdoc?"
, not "about:srcdoc"
, when submitting such a form. In Firefox, the URL that gets navigated to is "about:srcdoc"
. I think the Firefox behavior here is technically wrong. In particular, we are landing at https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#submit-mutate-action with an empty entry list, so query ends up as the empty string. Then we are supposed to set the query component to empty string, which is not the same as setting it to null, so I think per spec this should end up as "about:srcdoc?"
, right?
I filed bug 1591100 on the missing ?
here.
Navigating to that URL results in a network error.
Yeah, this is the part that's nroken in Chrome. Here's a simple testcase:
<iframe src="about:srcdoc"></iframe>
<iframe src="about:srcdoc?"></iframe>
Both of those load in Chrome and claim to have documents with "about:srcdoc"
and "about:scrdoc?"
respectively as URLs.
In spec terms, those cases should land in https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-fetch and then https://fetch.spec.whatwg.org/#concept-fetch and then https://fetch.spec.whatwg.org/#concept-main-fetch. From there we end up in https://fetch.spec.whatwg.org/#concept-scheme-fetch which should return a network error for anything with the "about"
scheme except "about:blank"
. So this part is definitely wrong in Chrome. They even have an existing issue tracking this: https://bugs.chromium.org/p/chromium/issues/detail?id=974300.
Comment 8•5 years ago
|
||
Anne, do you mind double-checking my reasoning about the missing ?
?
Comment 9•5 years ago
|
||
Yes, that's correct, a non-null query is significant, see https://url.spec.whatwg.org/#url-serializing step 6 in particular.
Description
•