Tracking issue for document.open() overhaul

[TimothyGu]

This is a list of issues that currently surround document.open() interoperability. The list is tentative, and will most probably be extended in the future. For items in the list without dedicated issues or pull requests, I will be filing them individually in the future if need be.

The goal is for each listed issue to have extensive WPT coverage, as well as a confirmed resolution, either as a spec change or "known browser bug; will fix", or both. For now, the "resolution" present is what I believe to be the right path forward, and does not represent the final verdict.

The first checkbox represents if the resolution and tests have been completed. The second represents if the spec change has been submitted (or if it's not necessary).

• ☑️ Order of bail-outs (https://crbug.com/875735, HTML: Add bailout order checks for document.open() web-platform-tests/wpt#12240, Align Document::open() and close() further with the spec web-platform-tests/wpt#12627, HTML: more tests for document.open bailout order web-platform-tests/wpt#12645)
  Resolution: No change to spec required. There seems to be internal bugs in Chrome, Firefox, and Safari.
• ☑️ Return value should be document (HTML: Add checks for the return value of document.open() web-platform-tests/wpt#12359)
  Resolution: No change to spec required. Edge returns null instead currently, but making Edge return document has minimal compatibility risk. Tests needed though.
• ☑️ Calling document.open() from custom elements constructor (Add test for document.open() in custom element constructor web-platform-tests/wpt#12037)
  Resolution: Keep existing spec in alignment with Chrome and Firefox and also Safari. There is an existing issue with Safari.
• ☑️ Calling document.open() when the Document is being unloaded (https://crbug.com/583586, HTML: Add bailout order checks for document.open() web-platform-tests/wpt#12240, Implement ignore-opens-during-unload counter in Document web-platform-tests/wpt#12413)
  Resolution: Keep existing spec in alignment with Firefox and Safari. File bugs with (and fix!) Chrome and (later) Edge.
• ☑️ Non-active documents (Extend document.open/write to non-active documents #2827, https://crbug.com/741071, HTML: document.open() and document's URL web-platform-tests/wpt#12636, HTML: review followup web-platform-tests/wpt#12662, document.open(): Test non-fully active documents web-platform-tests/wpt#12770, Allow document.open() to be called on non-active documents #3977)
  Resolution: Aim to support non-active documents, but defer until other clean-ups are done.
• ☑️ Bail with active parser (https://bugzilla.mozilla.org/show_bug.cgi?id=1475000, [html] Add tests for document.open() after window.stop() web-platform-tests/wpt#11929)
  Resolution: No change to spec required. There seems to be a bug in Firefox and Edge.
• ☑️ Stripping out fragments in document URL (Unclear what to do with fragments on document.open #2555, HTML: document.open() and document's URL (with fragments) web-platform-tests/wpt#10817, document.open(): remove fragment before propagating entry document's URL #3970)
  Resolution: Strip out fragments in document URL in document.open() if the entry settings object's document is not the same as the document on which open() is called. Align with Chrome (and Edge to a lesser extent, as it strips document URL's fragment in all cases), and provide a simpler but reasonable fix to the scrolling bug.
• ☑️ Aborting document and fetches (Investigate a new document.open() #3651, Unclear what exactly should be aborted in document.open() #3975, HTML: document.open() and aborting documents web-platform-tests/wpt#10789, document.open(): only abort when there is a navigation #3999)
  Resolution: Only abort when there is an ongoing attempt to navigate. Use the "ideal 2" plan in Unclear what exactly should be aborted in document.open() #3975.
• ☑️ "Prompt to unload" and "unload" (document.open URL handling is fishy #3286, How should document.open handle the beforeunload handler tearing down the world? #3306, HTML: document.open() and the unload event web-platform-tests/wpt#10773, HTML: document.open() and the beforeunload event web-platform-tests/wpt#10778, document.open() simplifications: realm creation, unloading, tasks removal #3918)
  Resolution: Remove "prompt to unload" and "unload" and align with Chrome and Safari. Firefox only fires beforeunload but not pagehide or unload events. Edge doesn't fire any events but still seems to run these steps – which for our purposes is identical to not running them.
• ☑️ Removal of event listeners (HTML: document.open() and event listener removal web-platform-tests/wpt#12122, document.open(): Test non-fully active documents web-platform-tests/wpt#12770, Revise event listener removal in document.open() #3893, Allow document.open() to be called on non-active documents #3977)
  Resolution: Keep existing spec and remove event listeners on document's nodes. Additionally, align with Chrome and Safari in removing event listeners from Window, which has minimal compatibility risk due to current Edge and Firefox behaviors of removing tasks (since most events fired on Window are fired from tasks).
• ☑️ Removal of event handlers (Event handlers-created event listener need to be removed sometimes #3836, HTML: document.open() and event listener removal web-platform-tests/wpt#12122, Revise event listener removal in document.open() #3893)
  Resolution: Set event handlers' values to null (deactivate all event handlers), but do not explicitly remove event handler content attributes. There's no reason to keep handlers there when the underlying event listener has been removed.
• ☑️ Removal of tasks (No longer remove tasks for document.open() #3665, https://crbug.com/592867, HTML: document.open() and tasks web-platform-tests/wpt#10818, document.open() simplifications: realm creation, unloading, tasks removal #3918)
  Resolution: Do not remove any tasks and align with Chrome, Safari, and partially Firefox.
• ☑️ MutationObserver (HTML: Add test for document.open() and MutationObserver web-platform-tests/wpt#12879)
  Resolution: No changes to spec required. Continue to make MutationObserver work with document.open()'s changes to the DOM tree. The provided test passes in Chrome, Firefox, and Safari, but fails in Edge currently.
• ☑️ Creating a new JavaScript realm (Calling InitializeHostDefinedRealm in document.open is probably unnecessary #1698, https://crbug.com/149785, HTML: document.open() and global variables web-platform-tests/wpt#10815, HTML: Change document.open() test expectation web-platform-tests/wpt#12882, document.open() simplifications: realm creation, unloading, tasks removal #3918)
  Resolution: Remove the abstract operation call as well as related steps; dramatically simplify algorithm and align with Chrome and Safari.
• ☑️ Quirks mode (Document open steps and quirks mode #3831, HTML: document.open() and quirks mode web-platform-tests/wpt#10679, Make document.open() set the document to no-quirks #3966)
  Resolution: Align with Chrome, Edge, and Safari and set the document's mode to no-quirks mode in document open steps.
• ☑️ Reload override buffer (document.open() can make a document's URL go out of sync with its history entry #3885, https://bugzilla.mozilla.org/show_bug.cgi?id=556002, HTML: document.open() and reload web-platform-tests/wpt#12555, HTML: Fix test when run through ./wpt run web-platform-tests/wpt#12885, document.open() simplifications, part 2 #3946)
  Resolution: Align with Chrome and Safari, and remove the reload override buffer concept. Align with Safari in following the Document's URL when reloading. Also change the session history entry's URL to be the new Document's URL by using history.replaceState() model.
• ☑️ load event in conjunction with document.close() (document.open() and the load event web-platform-tests/wpt#10239)
  Resolution: This seems to be a bit out of scope for an investigation focused on document.open(), as it touches navigation as well as iframe loading behavior. Keep existing spec for now, and revisit in the future in the context of a comprehensive iframe investigation.
• ☑️ Readiness (HTML: document.open()'s readiness step web-platform-tests/wpt#10844, HTML: document.open()'s readiness step (lite) web-platform-tests/wpt#12727)
  Resolution: Browsers all seem fairly aligned (on document.open()'s behavior at least). No need to change spec.
• ☑️ History and replacement (At least Blink does not support document.open()'s replace parameter #3564, Investigate a new document.open() #3651, document.open() can make a document's URL go out of sync with its history entry #3885, https://crbug.com/68833, HTML: document.open() and history entry creation web-platform-tests/wpt#12634, HTML: add test for history.state after document.open() web-platform-tests/wpt#12650, document.open() simplifications, part 2 #3946)
  Resolution: Align with Chrome, Safari, and Edge in not adding a history entry when document.open() is called – i.e., always use the replace semantics. Simplifies implementation and align with Chrome, Safari, and Edge. Also remove replace parameter in the process as it's always enabled.

[annevk]

@bzbarsky you probably want to review the above. With Ben leaving I suspect there's nobody else at the moment with a somewhat active interest in this?

[bzbarsky]

Well, @hsivonen might have thoughts. And maybe @mystor, maybe. Are you sure @wanderview is not still interested? ;)

I'm not quite clear on the event listeners thing. Firefox doesn't remove them from the old Window but does create a new Window, right? So the only way to trigger the listeners on the old Window is ... I'm not even quite sure what, actually.

[TimothyGu]

So the only way to trigger the listeners on the old Window is ... I'm not even quite sure what, actually.

Yeah. That is precisely my point: if we can't trigger listeners on the old Window with Firefox right now, it is pretty much equivalent to if the event listeners were removed in the first place. (Well one can of course always fire synthetic events but that's different.)

[bzbarsky]

Even with synthetic events... what would you fire them at, exactly?

[TimothyGu]

@bzbarsky The window as visible to the script that ran document.open()? Something like

<script>
window.addEventListener("myEvent", () => { parent.fired = true; });
document.open();
window.dispatchEvent(new Event("myEvent"));
</script>

in an iframe.

But the bigger issue here seems to be that Firefox doesn't remove event listeners – on anything, not just the window object. See https://wpt.fyi/results/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/event-listeners.window.html, step 13 in the current spec, and web-platform-tests/wpt#12122.

[bzbarsky]

window.dispatchEvent(new Event("myEvent"));

Here "window" is the windowproxy, so would dispatch to the new window.

Though it's possible that bareword dispatchEvent() might work, actually...

But the bigger issue here seems to be that Firefox doesn't remove event listeners – on anything, not just the window object

Yeah. We should probably change that...

[wanderview]

Are you sure @wanderview is not still interested? ;)

FWIW, I'm interested but probably unable to help much in the near future. Ramping up on other tasks, etc.

[TimothyGu]

With all the checkboxes checked and relevant PRs merged, and bugs filed:

• Chrome: https://crbug.com/866274
• Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/18917746/
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1489308
• WebKit: https://bugs.webkit.org/show_bug.cgi?id=189371, https://bugs.webkit.org/show_bug.cgi?id=189373, https://bugs.webkit.org/show_bug.cgi?id=189374, https://bugs.webkit.org/show_bug.cgi?id=189375, https://bugs.webkit.org/show_bug.cgi?id=189376

… it's time for me to close this out :)