Intent to Ship: New window.open() popup vs. window behavior

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

https://arai-a.github.io/window-open-features/proposal.html

Specification

https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested

Summary

This change aligns Chromium with the spec for window.open(), by 1) adding a "popup" windowFeature to control popup vs. tab/window, and 2) ensuring all BarProp properties return !is_popup.

Blink component

Blink

Search tags

window.open, popup

TAG review

Very small change, landed as part of the HTML spec, so no TAG review should be needed.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This is an interop-driven change, and should result in better interop around popups. There is a small compat risk, from the changes to the BarProp properties. They previously always returned true, whereas with this change they now return !is_popup. The consensus is that the risk should be fairly low, given low usage and bad interop previously.

Gecko: Positive This was a Firefox-driven change to the spec.

WebKit: No signal Safari has been very lightly involved in the spec discussion, but hasn't expressed support or opposition: https://github.com/whatwg/html/issues/5872#issuecomment-798828427

Web developers: No signals

Other signals:

Debuggability

All fields are debuggable via existing JS apis.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

WindowOpenNewPopupBehavior

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1192701

Estimated milestones

M98

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5663031909416960

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Wednesday, November 10, 2021 at 2:29:17 AM UTC+1 Mason Freed wrote:

Contact emails

mas...@chromium.org

Explainer

https://arai-a.github.io/window-open-features/proposal.html

That not really an explainer, in the sense that it outlines the algorithmic changes to HTML, but not the developer impact.

Could you maybe write a few lines that explain what this does and how developers are expected to use it?

 

Specification

https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested

Summary

This change aligns Chromium with the spec for window.open(), by 1) adding a "popup" windowFeature to control popup vs. tab/window, and 2) ensuring all BarProp properties return !is_popup.

Blink component

Blink

Search tags

window.open, popup

TAG review

Very small change, landed as part of the HTML spec, so no TAG review should be needed.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This is an interop-driven change, and should result in better interop around popups. There is a small compat risk, from the changes to the BarProp properties. They previously always returned true, whereas with this change they now return !is_popup. The consensus is that the risk should be fairly low, given low usage and bad interop previously.

Gecko: Positive This was a Firefox-driven change to the spec.

Have they implemented? Have they shipped?

[Tooru Fujisawa]

Hello :)

> Could you maybe write a few lines that explain what this does and how developers are expected to use it?

The change standardize the following 2 things:

• the condition to open minimal popup
  
  • whether to open popup or not isn't normative. browsers can:
    • provide options to override the behavior
    • simply ignore, for example, in case it lacks the concept of window, like mobile browsers
• BarProp.visible value
  • this is normative change, for improving privacy
    
  • It stops reflecting actual UI visibility or features parameter of window.open
  • if the window/tab is opened by requesting a popup by window.open, all BarProp.visible returns false. otherwise true

the developer impact would be:

• popup condition
  • in general
    • the old UI-related features (locationbar, toolbar, menubar, resizable, scrollbars, status) are now mildly deprecated
      
    • if they want positioned/sized a popup, just specifying left/top and/or width/height works
    • if they don't want a popup, they shouldn't specify any features except noopener or noreferer
  • on Chromium
    • the basic condition isn't changed. no impact
  • on Firefox
    • width feature is removed from the condition for opening popup window, but having non-empty feature requests popup, so not much impact unless the feature has location,menubar,scrollbars,status that requests non-popup
  • on Safari
    • Safari uses different behavior, it uses minimal popup, normal window, and normal tab, and the condition is different, so there can be some impact that different thing (window/popup/tab) is opened
• new "popup" feature
  • in general
    • if website hits a compatibility issue about whether to open popup or not, they can use the newly added "popup" feature for the quick fix
      • popup=1 if they want a popup
      • popup=0 if they don't want a popup
    • for basic usage, this feature isn't much necessary, given:
      • to request popup, having non-empty features (except noopener or noreferer) works, and in most case the popup will have width (if the website wants to request popup without specifying position/size, they can use "popup" feature)
      • to request non-popup, just having empty features (except noopener or noreferer) works
• BarProp.visible:
  • in general
    • there was already inconsistency between browsers, so I'd expect not much meaningful usage for it, except for finger printing
    • there's no alternative for getting actual UI visibility
  • on Chromium
    • this was returning each features in window.open call
  • on Firefox and Safari
    • this is/was mostly returning the actual visibility

> Have they implemented? Have they shipped?

Firefox implemented and shipped the change in version 96, that will be released on 2022-01-11:
https://bugzilla.mozilla.org/show_bug.cgi?id=1701001

The option to override the behavior is in WIP:
https://bugzilla.mozilla.org/show_bug.cgi?id=1714939

[Mason Freed]

Thanks Tooru for the explanation. (Tooru made/landed the spec changes for this feature.)

I've also updated the chromestatus entry with a bit more detail, and I copied the new text below. Hopefully between the two of these, your questions have been answered. But let me know if not!

Motivation

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.

[Rick Byers]

I'm thrilled to see window.open behavior getting more predictable and understandable. Thank you Tooru and Mason! The precise details of window.open behavior has long been an ugly wart on the web platform IMHO.

I agree that the risk seems likely to be small, LGTM1. 

But as always, please keep an eye out for feedback during canary/dev/beta and be prepared to pause the roll-out of this feature if we see non-trivial evidence of compat impact. window.open seems like exactly the sort of feature that sites have taken hard dependencies on the precise behavior of in different browsers for many years. These are the sort of features which often surprise us with compat impact due to very subtle changes, but we can't let that stop us from trying to improve them.

Thanks,

   Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDh8Oi%2Bi37s0WVUFzYPMxGTx-TOwBaETdk6WgT5P_8FPuw%40mail.gmail.com.

[Yoav Weiss]

Thanks Mason and Tooru!

This does indeed sound like an improvement towards interop on the popup front.

Does this change the current Chromium behavior by default? (i.e. when a "popup" argument is not passed) 

[Mason Freed]

Thanks for the comments!

On Mon, Nov 15, 2021 at 1:17 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks Mason and Tooru!

This does indeed sound like an improvement towards interop on the popup front.

Does this change the current Chromium behavior by default? (i.e. when a "popup" argument is not passed) 

No, this should not change the "opening" behavior of Chromium. We originally planned to slightly change the "triggers" for a popup, but a use counter study (results discussed around here) showed too high a percentage of potentially changed behavior. So we fell back to the current proposal which does not change behavior (assuming "popup" isn't passed). This proposal will change the return values from the BarProp properties, but these should have lower compat risk, we think.

 

On Fri, Nov 12, 2021 at 5:22 PM Rick Byers <rby...@chromium.org> wrote:

I'm thrilled to see window.open behavior getting more predictable and understandable. Thank you Tooru and Mason! The precise details of window.open behavior has long been an ugly wart on the web platform IMHO.

I agree that the risk seems likely to be small, LGTM1. 

But as always, please keep an eye out for feedback during canary/dev/beta and be prepared to pause the roll-out of this feature if we see non-trivial evidence of compat impact. window.open seems like exactly the sort of feature that sites have taken hard dependencies on the precise behavior of in different browsers for many years. These are the sort of features which often surprise us with compat impact due to very subtle changes, but we can't let that stop us from trying to improve them.

Thanks! I definitely agree that this is an area that can cause compat trouble. We'll definitely monitor for feedback, and there is a blink::Feature (kWindowOpenNewPopupBehavior) that can be used as a killswitch if necessary.

Thanks,

Mason

[Yoav Weiss]

LGTM2

On Mon, Nov 15, 2021 at 8:18 PM Mason Freed <mas...@chromium.org> wrote:

Thanks for the comments!

On Mon, Nov 15, 2021 at 1:17 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks Mason and Tooru!

This does indeed sound like an improvement towards interop on the popup front.

Does this change the current Chromium behavior by default? (i.e. when a "popup" argument is not passed) 

No, this should not change the "opening" behavior of Chromium. We originally planned to slightly change the "triggers" for a popup, but a use counter study (results discussed around here) showed too high a percentage of potentially changed behavior. So we fell back to the current proposal which does not change behavior (assuming "popup" isn't passed). This proposal will change the return values from the BarProp properties, but these should have lower compat risk, we think.

Yeah, that makes sense!

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUJ%2Bpc3iM7N-f_v6HkGaFRFQbWnbhp_2jTEEH%3DJ91WqOQ%40mail.gmail.com.

[Chris Harrelson]

Could you also file a webkit-dev signals request, and a "FYI" TAG issue?

[Mason Freed]

Thanks for the LGTMs!

On Thu, Nov 18, 2021 at 12:18 PM Chris Harrelson <chri...@chromium.org> wrote:

Could you also file a webkit-dev signals request, and a "FYI" TAG issue?

Yes, definitely. The webkit-dev request will show up here soon, and here is the TAG Review.