Consider adding an "ignore document.open/write" flag on document

Consider this testcase:

<script>
  location = something;
  document.write("hello");
</script>

Per spec as currently written, the location set will stop the pageload and start a new navigation, then the write() call will stop that navigation and blow away the document, replacing it with the string "hello".

None of the shipping browsers follow the spec here:

Chrome (release; dev builds match the spec) and Safari start the navigation async from the location set, so the write() happens before the parser is terminated and just inserts into the existing input stream, and then the navigation happens.
Firefox sets a flag to ignore document.open and document.write on a document if https://html.spec.whatwg.org/multipage/browsing-the-web.html#abort-a-document step 3 is reached and there is an active parser at that point. So in Firefox in this case the navigation starts sync and then the write() call is just ignored.

It turns out that if the testcase is modified slightly to:

<form action="something"></form>
<script>
  document.forms[0].submit()
  document.write("hello");
</script>

there are web compat requirements that either the navigation be async or there be a flag like the Firefox one, because otherwise the form submit will not complete. See https://crbug.com/955556 for details. Right now the spec has an async navigation for form submission, but we've been considering changing that to simplify the model, in which case we'd need to add a flag like the one Firefox has.

@annevk

@annevk

Add a flag to prevent document.open()/document.write() after document…

I went ahead and added this flag to Chrome based on https://bugs.chromium.org/p/chromium/issues/detail?id=973657, so I'd support adding this to the spec. I tested a bunch of ways of fixing this case, and the flag approach seemed to be least invasive.

It seems like we've got some convergence here, so this is probably what we should spec.

Add a flag to prevent document.open()/document.write() after document…

@natechapin

@natechapin are the tests you added in https://chromium-review.googlesource.com/c/chromium/src/+/1667743 ones that could be moved to web-platform-tests, so we can see how other browsers behave?

@natechapin

@natechapin are the tests you added in https://chromium-review.googlesource.com/c/chromium/src/+/1667743 ones that could be moved to web-platform-tests, so we can see how other browsers behave?
Yes, I think they should be convertible to web-platform-tests.

Though note, I have gotten one bug report about this behavior (https://bugs.chromium.org/p/chromium/issues/detail?id=980562), where a site is doing:

window.stop();
document.write('foo');

They expect this to abort the parser and replace the existing content with write(), where we seem to be converging on ignoring the write().

Hmm. What does that site end up doing in Firefox? Is it just broken there right now? Or is it UA-sniffing?

They're at least doing mobile vs desktop sniffing, based on the fact that the bug reproduces in mobile Chrome but not desktop Chrome. I definitely can't repro the bug in desktop Firefox, and it doesn't appear to reproduce in Firefox with Responsive Design Mode, though I'm not familiar enough with Firefox's developer tools to know whether that's a suitable substitute for testing on mobile Firefox.

Somewhat relatedly, https://github.com/web-platform-tests/wpt/blob/aef14686d9c71e64782cb0a102dc7cdf7e0a2cfa/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/aborted-parser.window.js tests for the current spec behavior. It would need to be adjusted after this change is done.

They're at least doing mobile vs desktop sniffing, based on the fact that the bug reproduces in mobile Chrome but not desktop Chrome. I definitely can't repro the bug in desktop Firefox, and it doesn't appear to reproduce in Firefox with Responsive Design Mode, though I'm not familiar enough with Firefox's developer tools to know whether that's a suitable substitute for testing on mobile Firefox.

I just tested this on Firefox on Android, and it looks like the website in question served the desktop version rather than attempting the redirect to mobile.

So the proposed spec change would be broken for this case, but UA-sniffing means that particular website is only showing it on mobile Chrome.

I suppose we could consider only setting the "ignore document.open/write" flag for abort-during-navigation-start, but that feels a little too subtle to me.

@natechapin

@natechapin do you have a preference on what the spec should end up saying here? At this point, do Chrome and Firefox effectively agree, or is there still a delta?

Fix document.open tests to align with HTML spec changes.

Bug 1580381. Fix document.open tests to align with HTML spec changes.…

Ignore document.open/write after the active parser has been aborted

Bug 1580381. Fix document.open tests to align with HTML spec changes.…

Navigation Menu

Repository navigation

Consider adding an "ignore document.open/write" flag on document #4723

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Consider adding an "ignore document.open/write" flag on document #4723

Description

Activity

bzbarsky commented on Jun 20, 2019

natechapin commented on Jun 20, 2019

TimothyGu commented on Jun 30, 2019

foolip commented on Jul 19, 2019

natechapin commented on Jul 25, 2019

bzbarsky commented on Jul 25, 2019

natechapin commented on Jul 25, 2019

TimothyGu commented on Jul 29, 2019

natechapin commented on Jul 29, 2019

foolip commented on Sep 10, 2019

10 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions