Standardize a popup's condition and UI opened by window.open #5872

arai-a · 2020-08-28T12:49:48Z

derived from arai-a/window-open-features#2 and https://bugzilla.mozilla.org/show_bug.cgi?id=1657738

The behavior of window.open differs between browsers, for:

the condition to choose the target based on features parameter, from
- new popup window
- new normal window
- new tab
a popup window's UI (especially, whether to show location bar)

current situation is summarized in https://arai-a.github.io/window-open-features/ (let me know if you find something wrong there)

it would be nice to standardize the condition for popup etc, that will help web developers to figure out what to write in features parameter of window.open,
Also, I would be nice if we can standardize popup window's look-and-feel.

First, I'd like to gather opinion from browser developers about:

the reasoning behind the current condition for popup/window/tab
concern for changing/standardizing the condition
the reasoning behind the popup window's UI (why location bar is read-only or hidden, why toolbar etc are hidden)
concern for changing popup window's UI

related discussion:

https://bugzilla.mozilla.org/show_bug.cgi?id=1657738 : making popup window's location bar writable, and also provide tab/toolbar etc
https://bugzilla.mozilla.org/show_bug.cgi?id=1658775 : toolbar in popup (especially WebExtensions' browser action)
Add additional feature names to window.open() #2464 : previous discussion about features

The text was updated successfully, but these errors were encountered:

annevk · 2020-08-31T08:17:39Z

@rniwa can you help with this or point to someone else from WebKit who can? @natechapin can you for Chromium perhaps?

michaelwasserman · 2020-09-02T19:14:51Z

Thanks for investigating these topics and promoting cross-browser consistency! Here are some initial thoughts as a Chromium developer proposing semi-related Screen/Window changes/APIs (but limited web-platform experience):

the reasoning behind the current condition for popup/window/tab
Others might have historical perspective on conditions, but I suspect Chromium inherited Webkit behavior and made incremental changes over time to address specific cases; it may be difficult to capture that history, I hope other folks will chime in.
concern for changing/standardizing the condition
Standardizing popup/window/tab conditions seems desirable. Introducing a new explicit feature string parameter e.g. 'type=tab' could clarify intent of the request (for this poorly-shaped API). Considering the space of web application manifest display modes in tandem would be very nice. The opener's window type (tab/popup/web-application/etc.) may also influence the resulting window type or UI details (e.g. web-app popup in Chromium).
the reasoning behind the popup window's UI (why location bar is read-only or hidden, why toolbar etc are hidden)
I don't have historical perspective here, but each implementer would probably cite some overlapping set of reasons (e.g. they weren't primarily meant to be user-navigable surfaces; they're designed to minimize frame UI/dimensions and accompany a 'main' browser window; etc.). Chromium even has slightly different styling for popups from web application windows, which use the web application out-of-scope navigation info-bar in lieu of a read-only location bar :-/
concern for changing popup window's UI
It may be detrimental to rigorously specify UI elements, dimensions, or characteristics. While some window.open features were designed for ui specification (thank you for iterating on that documentation!), they've obviously fallen out of favor. On the other hand, I'd personally like to see some advances and consistency in popup window design.

current situation is summarized in https://arai-a.github.io/window-open-features/ (let me know if you find something wrong there)

I may be misreading this, but I think Chromium's IsPopup(windowFeature) should have a step after 5 like

  6. If windowFeature["width"] is true or windowFeature["height"] is true, then:
    1. Return true.

arai-a · 2020-09-03T08:10:15Z

Thank you.

Introducing a new explicit feature string parameter e.g. 'type=tab' could clarify intent of the request (for this poorly-shaped API).

Yeah, adding explicit feature string sounds better.

Considering the space of web application manifest display modes in tandem would be very nice.

This looks nice, that it also defines fallback for each option,
It would work across different environment (desktop/mobile/other) that some option might be unavailable,
and also browsers can provide choice to users.

The opener's window type (tab/popup/web-application/etc.) may also influence the resulting window type or UI details (e.g. web-app popup in Chromium).

Yes, we should define a matrix for opener's window type and requested window type.

It may be detrimental to rigorously specify UI elements, dimensions, or characteristics.

Thank you for the resource, it looks great.

While some window.open features were designed for ui specification (thank you for iterating on that documentation!), they've obviously fallen out of favor.

Yes, IIUC, Firefox was the last modern browser that supported those UI-specific features separately, and the behavior was removed.

On the other hand, I'd personally like to see some advances and consistency in popup window design.

Thanks :)
Also, the consistent popup design will also benefit the WebExtension UI design,
about what tool (browser action, page action) to provide for popup.

I may be misreading this, but I think Chromium's IsPopup(windowFeature) should have a step after 5 like
  6. If windowFeature["width"] is true or windowFeature["height"] is true, then:
    1. Return true.

I don't see difference in the following 2 cases, that passes steps 1-5, and both don't result in popup:

"location=yes,menubar=yes,resizable=yes,scrollbars=yes,status=yes,toolbar=yes"
"location=yes,menubar=yes,resizable=yes,scrollbars=yes,status=yes,toolbar=yes,width=500,height=500"

arai-a · 2020-09-03T12:03:32Z

I forgot to describe Firefox's case and my opinion:

the reasoning behind the current condition for popup/window/tab

Firefox has been allowing website to specify each UI parts' visibility separately until Firefox 76.
And we've changed the behavior to follow other browsers, website no more can specify each UI parts visibility.

The condition for popup/window/tab is based on:

the mix of other browsers' behavior about when to use popup
existing configuration about window vs tab

concern for changing/standardizing the condition

Given above, changing the condition for popup should be fine.
Changing condition for window/tab may affect users, but if we can provide fallback or some customizability, that should be fine.

As pointed out by @michaelwasserman, adding explicit feature would be nice,
instead of specifying combination of existing features (that's already confusing)

the reasoning behind the popup window's UI (why location bar is read-only or hidden, why toolbar etc are hidden)

About UI visibility, we chose minimal UI for popup, that is, only location bar is shown,
because that was the default behavior when any UI-visibility features aren't specified,
and that seems to be common usecase.

The other usecase was to specify all UI parts' features and open normal browser window, but that behavior was changed to open a new tab, to follow chromium's behavior, and also to honor user's configuration about where to open new window (tab vs window).

Location bar has made readonly in bug 22183 (commit) at the same time showing a minimal-location bar for the case standard location bar is hidden, in order to prevent spoofing.
At that point, IIUC, the minimal-location bar was only for informative purpose and not for navigation, to avoid breaking web, that's the reason why it's made readonly.

Apparently the minimal-location bar is made hide-able again for web-compat issue, and then it's made always visible in bug 337344 (commit), in order to make spoofing harder.
At this point, still it's considered to be informative, and that seems to be the reason why it's kept readonly.

concern for changing popup window's UI

Given that the current style is decided based on old behavior around UI (allows contolling each UI parts' visibility, and status bar had many items), we could revisit the UI.
Personally, location bar still feels necessary for anti-spoofing, so, I'd like to hear the reasoning behind Safari's behavior that hides location bar.

Adding more items (toolbar, tabs, etc) may benefit users, but adding them unconditionally may break the web content display on small screen.
There was some comments about making full toolbar switchable in above bugs, we could revisit it also.

annevk · 2020-09-09T13:20:58Z

@arai-a I don't think Safari's UI allows for spoofing as the domain is clearly visible in the chrome of the popup. If we are to keep (readonly) popups that actually seems like the most appropriate UI to me.

arai-a · 2020-09-09T13:30:08Z

@arai-a I don't think Safari's UI allows for spoofing as the domain is clearly visible in the chrome of the popup.

Thank you for pointing that out :)

victornpb · 2020-09-09T13:59:00Z

As said before, location should not be able to be hidden, as it would be easily abused for phishing, specially for creating fake oauth popups.

arai-a · 2020-09-24T11:29:18Z

@rniwa can you take a look?

rniwa · 2021-03-14T03:55:34Z

Here are some thoughts / commentary I've gathered from Safari/WebKit side so far:

Safari has a preference to "open pages in tabs instead of windows". This preference needs preside over whatever references website may give to window.open.
Safari's condition for when to use a popup changed over time. Notably, we've removed all but most ways for websites to signal to use a popup (it used to be same as what Chrome does today).

arai-a · 2021-03-17T04:25:00Z

Thank you!

Safari's condition for when to use a popup changed over time. Notably, we've removed all but most ways for websites to signal to use a popup (it used to be same as what Chrome does today).

That's great news.
If there weren't much breakage with the change, it means that we can use Safari's condition, that's "open popup only when width is specified", as minimum condition, regardless of whether to add yet another explicit feature (e.g. type=popup) for where to open the page.

Then, #4431 also suggests that it's better just dropping all features that are directly/indirectly connected with BarProps.

Safari has a preference to "open pages in tabs instead of windows". This preference needs preside over whatever references website may give to window.open.

This sounds like good solution for people who wants toolbars always available.
"Never using popup" works around the issue that "toolbars aren't available in popup".
Maybe browser can provide "open new normal window instead" option as well, if necessary.

For WebExtensions' toolbar situation, I'll track it in separate issue, given that popup condition can be solved before that.

I'll write a draft spec change.

arai-a · 2021-03-23T09:19:29Z

Here's draft proposal, https://arai-a.github.io/window-open-features/proposal.html , that covers this issue and #4431 ,
based on Safari's behavior for window.open features parameter, and chrome's behavior for BarProps, and some extra steps for user-agent-dependent behavior for user-preference etc.

Currently it doesn't cover the detailed UI parts visibility for the popup (just requires location bar or equivalent for showing URL or domain),
and also the explicit features (type=popup) isn't yet integrated.

I choose "popup" vs "tab" (instead of "window"), because many modern desktop browsers provides tab features, and also looks like mobile browsers also calls each page "tab".

Suggestions welcome :)

rniwa · 2021-03-23T10:07:28Z

I choose "popup" vs "tab" (instead of "window"), because many modern desktop browsers provides tab features, and also looks like mobile browsers also calls each page "tab".

I don't think the distinction between "tab" and "window" makes much sense. That is squarely the concern of each web browser & underlying operating system. Some operating systems such as iOS doesn't even provide a concept of window.

Also, I'm not really sure that defining what kind of UI popup will have or will not have is something HTML spec should even mention. That is at best a non-normative note.

annevk · 2021-03-23T10:44:00Z

@arai-a thank you for writing that up! It's really great to see us make some progress in this area.

I agree with @rniwa that we probably want to abstract this a little bit. How about we give "top-level browsing context" a boolean "is popup" field and based on that we define the BarProp properties to return false. And then in notes we describe some of the possible UI choices.

arai-a · 2021-03-23T10:44:42Z

Thank you :)

I don't think the distinction between "tab" and "window" makes much sense. That is squarely the concern of each web browser & underlying operating system. Some operating systems such as iOS doesn't even provide a concept of window.

I agree that the normative steps in the proposal shouldn't mention implementation dependent thing like "browser window".
Also, if we don't mention "browser window", it doesn't make much sense to introduce "tab". we can keep "window" name.
I'll fix that part.

Also, I'm not really sure that defining what kind of UI popup will have or will not have is something HTML spec should even mention. That is at best a non-normative note.

Okay, I'll fix that part as well.

arai-a · 2021-03-23T10:46:20Z

I agree with @rniwa that we probably want to abstract this a little bit. How about we give "top-level browsing context" a boolean "is popup" field and based on that we define the BarProp properties to return false. And then in notes we describe some of the possible UI choices.

That sounds good!

arai-a · 2021-03-25T10:56:25Z

Updated the proposal not to mention browser window or tab.
now it only calculate "whether it's popup or not" from tokenizedFeatures, and stores into [[IsPopup]] internal slot,
and added notes about the possible usage of [[IsPopup]] slot.

annevk · 2021-03-25T13:47:51Z

Thanks @arai-a! I think this is ready for a pull request. Are you willing to create one? I'll be out for two weeks, but hopefully @domenic can help move it along, but if not I'll be happy to help once back.

Quick comment on "Modify create a new browsing context", I think instead of this we can give is popup a default value of false.

And in "IsPopupRequested" I don't think we need step 1 at which point we might as well inline this into the caller.

arai-a · 2021-03-25T14:12:37Z

Thank you!

Quick comment on "Modify create a new browsing context", I think instead of this we can give is popup a default value of false.

Does it mean that we check the existence of [[IsPopup]] internal slot before getting the value, and default to false when the slot doesn't exist?

And in "IsPopupRequested" I don't think we need step 1 at which point we might as well inline this into the caller.

Indeed, the existence of the step doesn't change the condition, now that other features are removed.
I'll remove it.

arai-a · 2021-03-25T14:13:14Z

Are you willing to create one?

Sure, I'll open PR.

annevk · 2021-03-25T14:52:17Z

Abstractly, it means that top-level browsing context has an is popup member that's false unless otherwise stated (the choosing a browsing context steps will set it to true sometimes).

arai-a · 2021-03-25T14:58:23Z

Abstractly, it means that top-level browsing context has an is popup member that's false unless otherwise stated (the choosing a browsing context steps will set it to true sometimes).

Thanks. I didn't know that "member" is different thing than internal slot.
will update the proposal.

…g#5872)

Fixes whatwg#5872 Define an "is popup" member in top-level browsing context, and set it to true only when the browsing context is created by calling `window.open` with `width` features provided. Also add non-normative notes/example for using popup UI depending on "is popup" member.

…alues for each case For whatwg/html#5872 and whatwg/html#4431

Fixes whatwg#5872 Define an "is popup" member in top-level browsing context, and set it to true only when the browsing context is created by calling `window.open` with `width` features provided. Also add non-normative notes/example for using popup UI depending on "is popup" member.

Fixes whatwg#5872 Define an "is popup" member in top-level browsing context, and set it to true only when the browsing context is created by calling `window.open` with specific combination of `features` parameter. Also add non-normative notes/example for using popup UI depending on "is popup" member.

…alues for each case For whatwg/html#5872 and whatwg/html#4431

Fixes whatwg#5872 Define an "is popup" member in top-level browsing context, and set it to true only when the browsing context is created by calling `window.open` with specific combination of `features` parameter. Also add non-normative notes/example for using popup UI depending on "is popup" member.

For whatwg/html#5872, whatwg/html#4431, and whatwg/html#6530.

…by window.open, and BarProp values for each case, a=testonly Automatic update from web-platform-tests HTML: test BarProp and window.open() feature interactions For whatwg/html#5872, whatwg/html#4431, and whatwg/html#6530. -- wpt-commits: 29faceaa68f5cb31798cc17fe6868eaf5fa5fb7f wpt-pr: 28243

See [1] and [2] for more context, but this CL implements new behavior for how window.open() interprets the windowPreferences argument when deciding whether to open the window as a new tab or as a "popup", which is a separate window with minimal UI (toolbars, onmibox, etc.), and also what to return from the BarProp visible properties, e.g. window.toolbar.visible. The existing "trigger" behavior for popups will be retained by this CL, namely that a popup will be opened instead of a tab if: 1. the windowFeatures parameter is *not* empty, and 2. one of the following conditions is true: * both `location` and `toolbar` are false or missing * `menubar` is false or missing * `resizable is false or missing * `scrollbar` is false or missing * `status` is false or missing With this CL, an additional windowFeature called 'popup' is added, so that if 'popup' is present and truthy. Additionally, all BarProp properties (locationbar,menubar, personalbar,scrollbars,statusbar, and toolbar) will always return the same values, either false if a popup was opened, or true if a tab/window was opened. The spec for this behavior is part of the HTML spec: https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested The intent to ship is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ybnmxxvpE [1] whatwg/html#5872 [2] whatwg/html#6530 Fixed: 1192701 Change-Id: I50e745b1000d460c49085edd57d13f420b875ff3

For whatwg/html#5872, whatwg/html#4431, and whatwg/html#6530.

See [1] and [2] for more context, but this CL implements new behavior for how window.open() interprets the windowPreferences argument when deciding whether to open the window as a new tab or as a "popup", which is a separate window with minimal UI (toolbars, onmibox, etc.), and also what to return from the BarProp visible properties, e.g. window.toolbar.visible. The existing "trigger" behavior for popups will be retained by this CL, namely that a popup will be opened instead of a tab if: 1. the windowFeatures parameter is *not* empty, and 2. one of the following conditions is true: * both `location` and `toolbar` are false or missing * `menubar` is false or missing * `resizable is false or missing * `scrollbar` is false or missing * `status` is false or missing With this CL, an additional windowFeature called 'popup' is added, so that if 'popup' is present and truthy. Additionally, all BarProp properties (locationbar,menubar, personalbar,scrollbars,statusbar, and toolbar) will always return the same values, either false if a popup was opened, or true if a tab/window was opened. The spec for this behavior is part of the HTML spec: https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested The intent to ship is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ybnmxxvpE [1] whatwg/html#5872 [2] whatwg/html#6530 Fixed: 1192701 Change-Id: I50e745b1000d460c49085edd57d13f420b875ff3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2950386 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#943716}

See [1] and [2] for more context, but this CL implements new behavior for how window.open() interprets the windowPreferences argument when deciding whether to open the window as a new tab or as a "popup", which is a separate window with minimal UI (toolbars, onmibox, etc.), and also what to return from the BarProp visible properties, e.g. window.toolbar.visible. The existing "trigger" behavior for popups will be retained by this CL, namely that a popup will be opened instead of a tab if: 1. the windowFeatures parameter is *not* empty, and 2. one of the following conditions is true: * both `location` and `toolbar` are false or missing * `menubar` is false or missing * `resizable is false or missing * `scrollbar` is false or missing * `status` is false or missing With this CL, an additional windowFeature called 'popup' is added, so that if 'popup' is present and truthy. Additionally, all BarProp properties (locationbar,menubar, personalbar,scrollbars,statusbar, and toolbar) will always return the same values, either false if a popup was opened, or true if a tab/window was opened. The spec for this behavior is part of the HTML spec: https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested The intent to ship is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ybnmxxvpE [1] whatwg/html#5872 [2] whatwg/html#6530 Fixed: 1192701 Change-Id: I50e745b1000d460c49085edd57d13f420b875ff3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2950386 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#943716}

See [1] and [2] for more context, but this CL implements new behavior for how window.open() interprets the windowPreferences argument when deciding whether to open the window as a new tab or as a "popup", which is a separate window with minimal UI (toolbars, onmibox, etc.), and also what to return from the BarProp visible properties, e.g. window.toolbar.visible. The existing "trigger" behavior for popups will be retained by this CL, namely that a popup will be opened instead of a tab if: 1. the windowFeatures parameter is *not* empty, and 2. one of the following conditions is true: * both `location` and `toolbar` are false or missing * `menubar` is false or missing * `resizable is false or missing * `scrollbar` is false or missing * `status` is false or missing With this CL, an additional windowFeature called 'popup' is added, so that if 'popup' is present and truthy. Additionally, all BarProp properties (locationbar,menubar, personalbar,scrollbars,statusbar, and toolbar) will always return the same values, either false if a popup was opened, or true if a tab/window was opened. The spec for this behavior is part of the HTML spec: https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested The intent to ship is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ybnmxxvpE [1] whatwg/html#5872 [2] whatwg/html#6530 Fixed: 1192701 Change-Id: I50e745b1000d460c49085edd57d13f420b875ff3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2950386 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#943716}

…ndowPreferences and popups, a=testonly Automatic update from web-platform-tests Change behavior of window.open w.r.t. windowPreferences and popups See [1] and [2] for more context, but this CL implements new behavior for how window.open() interprets the windowPreferences argument when deciding whether to open the window as a new tab or as a "popup", which is a separate window with minimal UI (toolbars, onmibox, etc.), and also what to return from the BarProp visible properties, e.g. window.toolbar.visible. The existing "trigger" behavior for popups will be retained by this CL, namely that a popup will be opened instead of a tab if: 1. the windowFeatures parameter is *not* empty, and 2. one of the following conditions is true: * both `location` and `toolbar` are false or missing * `menubar` is false or missing * `resizable is false or missing * `scrollbar` is false or missing * `status` is false or missing With this CL, an additional windowFeature called 'popup' is added, so that if 'popup' is present and truthy. Additionally, all BarProp properties (locationbar,menubar, personalbar,scrollbars,statusbar, and toolbar) will always return the same values, either false if a popup was opened, or true if a tab/window was opened. The spec for this behavior is part of the HTML spec: https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested The intent to ship is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ybnmxxvpE [1] whatwg/html#5872 [2] whatwg/html#6530 Fixed: 1192701 Change-Id: I50e745b1000d460c49085edd57d13f420b875ff3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2950386 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#943716} -- wpt-commits: 3660b77d3cec8138401c12e055bee44d62e9b060 wpt-pr: 29334

Fixes whatwg#5872 by standardizing an internal "is popup" boolean, and how it is impacted by various window.open() features. Implementations can use this boolean (in addition to other signals) to determine whether an opened window is a popup or not. Fixes whatwg#4431 by changing the various BarProp visible properties to only reflect this "is popup" boolean, instead of reflecting the actual state of user interface elements, or the passed-in window features. Adds a "popup" window.open() feature to provide a simpler method of requesting a popup.

mfreed7 · 2021-12-14T03:52:49Z

Quick heads-up that the TAG reviewed this change, and was of the opinion that a type=popup type enum would have been more extensible than a boolean popup flag. I replied with some of the conversation that took place on the PR, but I thought I'd post a heads-up here, in case people think any action needs to be taken. This feature only shipped very recently, so there's likely still time to make changes if needed. But not for too long.

mfreed7 · 2021-12-14T04:54:08Z

Also one more point the TAG made: it would have been (or would still be) nice to allow windowFeatures to be specified as a dictionary, with the new popup parameter possibly only available there, to encourage its use.

annevk · 2021-12-14T08:14:43Z

That does seem like a reasonable idea. I think for click attribution APIs they also want to add new parameters to window.open(). It would be a bit of design and testing work though and we wouldn't want to support just popup there, noopener and noreferrer also need to be supported in some fashion.

domenic · 2021-12-14T14:58:25Z

Here was my proposal for redesigning window.open() to be a modern dictionary-accepting API: WICG/attribution-reporting-api#130 (comment) . Last time @annevk wasn't a fan, but maybe he's changed his mind?

annevk · 2021-12-14T16:03:41Z

I'm more open to it. Getting rid of popups isn't going to happen anytime soon and it's clear we might add more here over time.

Fixes whatwg#5872 by standardizing an internal "is popup" boolean, and how it is impacted by various window.open() features. Implementations can use this boolean (in addition to other signals) to determine whether an opened window is a popup or not. Fixes whatwg#4431 by changing the various BarProp visible properties to only reflect this "is popup" boolean, instead of reflecting the actual state of user interface elements, or the passed-in window features. Adds a "popup" window.open() feature to provide a simpler method of requesting a popup.

See [1] and [2] for more context, but this CL implements new behavior for how window.open() interprets the windowPreferences argument when deciding whether to open the window as a new tab or as a "popup", which is a separate window with minimal UI (toolbars, onmibox, etc.), and also what to return from the BarProp visible properties, e.g. window.toolbar.visible. The existing "trigger" behavior for popups will be retained by this CL, namely that a popup will be opened instead of a tab if: 1. the windowFeatures parameter is *not* empty, and 2. one of the following conditions is true: * both `location` and `toolbar` are false or missing * `menubar` is false or missing * `resizable is false or missing * `scrollbar` is false or missing * `status` is false or missing With this CL, an additional windowFeature called 'popup' is added, so that if 'popup' is present and truthy. Additionally, all BarProp properties (locationbar,menubar, personalbar,scrollbars,statusbar, and toolbar) will always return the same values, either false if a popup was opened, or true if a tab/window was opened. The spec for this behavior is part of the HTML spec: https://html.spec.whatwg.org/multipage/window-object.html#popup-window-is-requested The intent to ship is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ybnmxxvpE [1] whatwg/html#5872 [2] whatwg/html#6530 Fixed: 1192701 Change-Id: I50e745b1000d460c49085edd57d13f420b875ff3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2950386 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#943716} NOKEYCHECK=True GitOrigin-RevId: cdad240f282dca85fb85fa3ecc809d7f34862996

annevk added interop Implementations are not interoperable with each other topic: frames/navigables/browsing contexts labels Aug 31, 2020

annevk mentioned this issue Mar 12, 2021

Further BarProp cleanup #4431

Closed

arai-a added a commit to arai-a/html that referenced this issue Mar 25, 2021

Standardize the condition to open popup with window.open (fixes whatw…

d10252f

…g#5872)

arai-a added a commit to arai-a/wpt that referenced this issue Mar 25, 2021

HTML: the condition for opening a popup by window.open, and BarProp v…

2677196

…alues for each case For whatwg/html#5872 and whatwg/html#4431

This was referenced Mar 25, 2021

HTML: the condition for opening a popup by window.open, and BarProp values for each case web-platform-tests/wpt#28243

Merged

Standardize the condition for opening a popup by window.open, and BarProp values #6530

Merged

arai-a added a commit to arai-a/wpt that referenced this issue Oct 12, 2021

HTML: the condition for opening a popup by window.open, and BarProp v…

12ebca4

…alues for each case For whatwg/html#5872 and whatwg/html#4431

arai-a added a commit to arai-a/wpt that referenced this issue Oct 27, 2021

HTML: the condition for opening a popup by window.open, and BarProp v…

85ce509

…alues for each case For whatwg/html#5872 and whatwg/html#4431

domenic pushed a commit to web-platform-tests/wpt that referenced this issue Oct 29, 2021

HTML: test BarProp and window.open() feature interactions

29facea

For whatwg/html#5872, whatwg/html#4431, and whatwg/html#6530.

domenic closed this as completed in ab08b9b Oct 29, 2021

past mentioned this issue Nov 5, 2021

Upcoming HTML standard issue triage meeting on 11/4/2021 #7201

Closed

karlcow mentioned this issue Nov 10, 2021

kepco.jp - Warning message due to pop-up blocker behaviour is present webcompat/web-bugs#85017

Closed

Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this issue Nov 18, 2021

HTML: test BarProp and window.open() feature interactions

826490a

For whatwg/html#5872, whatwg/html#4431, and whatwg/html#6530.

mfreed7 mentioned this issue Nov 19, 2021

"FYI" Review of new window.open() behavior w3ctag/design-reviews#691

Closed

1 task

whimboo mentioned this issue Dec 2, 2021

Add a context parameter for browsingContext.create w3c/webdriver-bidi#153

Merged

mfreed7 mentioned this issue Dec 8, 2021

Should 'true' count as truthy in parsing windowFeatures booleans? #7399

Closed

arai-a mentioned this issue Nov 17, 2022

Standardize the relation between the popup condition, BarProp.visible, and noopener/noreferrer #8520

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Standardize a popup's condition and UI opened by window.open #5872

Standardize a popup's condition and UI opened by window.open #5872

arai-a commented Aug 28, 2020 •

edited

Loading

annevk commented Aug 31, 2020

michaelwasserman commented Sep 2, 2020

arai-a commented Sep 3, 2020

arai-a commented Sep 3, 2020

annevk commented Sep 9, 2020

arai-a commented Sep 9, 2020

victornpb commented Sep 9, 2020

arai-a commented Sep 24, 2020

rniwa commented Mar 14, 2021

arai-a commented Mar 17, 2021 •

edited

Loading

arai-a commented Mar 23, 2021

rniwa commented Mar 23, 2021

annevk commented Mar 23, 2021

arai-a commented Mar 23, 2021

arai-a commented Mar 23, 2021

arai-a commented Mar 25, 2021

annevk commented Mar 25, 2021

arai-a commented Mar 25, 2021

arai-a commented Mar 25, 2021

annevk commented Mar 25, 2021

arai-a commented Mar 25, 2021

mfreed7 commented Dec 14, 2021

mfreed7 commented Dec 14, 2021

annevk commented Dec 14, 2021

domenic commented Dec 14, 2021

annevk commented Dec 14, 2021

Standardize a popup's condition and UI opened by window.open #5872

Standardize a popup's condition and UI opened by window.open #5872

Comments

arai-a commented Aug 28, 2020 • edited Loading

annevk commented Aug 31, 2020

michaelwasserman commented Sep 2, 2020

arai-a commented Sep 3, 2020

arai-a commented Sep 3, 2020

annevk commented Sep 9, 2020

arai-a commented Sep 9, 2020

victornpb commented Sep 9, 2020

arai-a commented Sep 24, 2020

rniwa commented Mar 14, 2021

arai-a commented Mar 17, 2021 • edited Loading

arai-a commented Mar 23, 2021

rniwa commented Mar 23, 2021

annevk commented Mar 23, 2021

arai-a commented Mar 23, 2021

arai-a commented Mar 23, 2021

arai-a commented Mar 25, 2021

annevk commented Mar 25, 2021

arai-a commented Mar 25, 2021

arai-a commented Mar 25, 2021

annevk commented Mar 25, 2021

arai-a commented Mar 25, 2021

mfreed7 commented Dec 14, 2021

mfreed7 commented Dec 14, 2021

annevk commented Dec 14, 2021

domenic commented Dec 14, 2021

annevk commented Dec 14, 2021

arai-a commented Aug 28, 2020 •

edited

Loading

arai-a commented Mar 17, 2021 •

edited

Loading