Closed Bug 1586740 Opened 5 years ago Closed 5 years ago

iframe.contentDocument on same domain returns null after form is submitted

Categories

(Core :: DOM: Navigation, defect)

69 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox70 --- affected
firefox71 --- affected
firefox72 --- affected

People

(Reporter: joubran.jad, Unassigned)

Details

Attachments

(1 file)

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!

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

Flags: needinfo?(joubran.jad)
Attached file index.html

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

Flags: needinfo?(joubran.jad)

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!

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

Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Images, Video, and HTML Frames
Ever confirmed: true
Product: Firefox → Core

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 :)

Component: Layout: Images, Video, and HTML Frames → Document Navigation

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.

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.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

Anne, do you mind double-checking my reasoning about the missing ??

Flags: needinfo?(annevk)

Yes, that's correct, a non-null query is significant, see https://url.spec.whatwg.org/#url-serializing step 6 in particular.

Flags: needinfo?(annevk)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: