Design Review #691

#691: "FYI" Review of new window.open() behavior

Opened Nov 19, 2021

Braw mornin' TAG!

I'm requesting a TAG review of the newly-specified window.open() behavior.

Per my Chromium Intent to Ship, it was requested that I file an FYI TAG review - hence this request.

Here is a summary of the changes, copied from the chromestatus entry for this change:

The window.open() API is currently confusing to use, in terms of trying to get it to open a popup vs. a tab/window. This change simplifies the usage by adding a single boolean argument called 'popup' that works as you'd expect: popup=1 gets you a popup, and popup=0 gets a tab/window:

const popup = window.open('_blank','','popup=1'); const tab = window.open('_blank','','popup=0');

Also there were previously confusingly-behaved getters for the BarProp visible properties (e.g. window.statusbar.visible) which didn't correctly represent what was actually visible. Now, those all return true if you got a new window/tab, and false if you got a popup.

This is an interop-driven change, to align Chromium with the newly-landed spec for window.open. It does not change existing behavior around whether a popup or tab/window is opened, to avoid compat issues.

Explainer¹: https://chromestatus.com/feature/5663031909416960
Specification URL: https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested
Tests: https://wpt.fyi/results/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name?label=master&label=experimental&aligned&q=open-features-is-popup-condition.html
Primary contacts (and their relationship to the specification):
- Mason Freed (@mfreed7), Google
Organization(s)/project(s) driving the specification: Mozilla
Key pieces of existing multi-stakeholder review or discussion of this specification: https://github.com/whatwg/html/issues/5872
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5663031909416960

Further details:

I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: none
The group where the work on this specification is currently being done: WHATWG
The group where standardization of this work is intended to be done: WHATWG
Major unresolved issues with or opposition to this specification: None
This work is being funded by: Google/Mozilla

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @mfreed7

Discussions

2021-12-Madripoor

Minutes

Draft comment

@plinss and I took a look at this during our virtual f2f today.

We think that a boolean argument (popup=0 or popup=1) is not extensible, if in the future authors want to select between more than these two kinds of window UI, whereas a keyword-based argument (e.g. type=popup) would not have this problem.

As a side point, this sentence in the explainer was unclear:

The window.open() API is currently confusing to use, in terms of trying to get it to open a popup vs. a tab/window.

until I read this section on MDN:

Most modern browsers (listed below) don't allow web content to control the visibility of UI parts separately. [snip] UI-related items of windowFeatures are used as a condition to whether opening a popup or a new tab, or a new window, and UI parts visibility of each of them is fixed.

Furthermore, we understand that this method has a long history, but if it were designed today we would strongly recommend using a dictionary instead of a serialized string that has to be parsed and re-serialized, see: https://github.com/w3ctag/design-principles/issues/213. It may be worth considering allowing users to pass a dictionary in place of this string for future enchancements, similarly to what was done for addEventListener().

We generally encourage people to seek feedback before features have already shipped in browsers. Given that this has already shipped in both Blink and Gecko, it seems too late to have any of our feedback taken on board. Therefore we're closing this issue, feel free to ping us if there's anything further to discuss.