1714939 - Provide an option to open new normal window when popup is requested by window.open

Status: ASSIGNED

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[Tooru Fujisawa [:arai]]

Related to bug 1507375, bug 1701001, and https://github.com/whatwg/html/issues/5872 .

in window.open API, currently all desktop browsers opens whether a new tab, a new popup, or a new window, depending on features parameter.

Currently Firefox opens whether "a new tab or a new window, depending on configuration", or "a new popup".

The current popup window has some issues around UI, like:

• extensions' browser actions aren't available (they're in toolbar)
• menubar isn't available (on windows and maybe some linux)
• location bar is read-only

One solution there is to add an option for "open a new window when a website requests opening a popup",
so that, when user needs full-featured normal window, they can configure the browser to open a new normal window.

Comment 1

[Tooru Fujisawa [:arai]]

Attachment: Safari's preferences

Safari already has similar option

Comment 2

[Tooru Fujisawa [:arai]]

I'd like to get feedback from UX team before going forward.

my questions are following:

1. is adding an option to always open a new tab instead of popup window okay?
2. should the option be exposed to about:preferences, like Safari above?
3. is there better way to solve UI/UX problems in comment #0 ?
   • other options I can think of are:
     • add a button to popup window that dynamically turn the popup window into normal window
     • somehow make toolbars or toolbar items available in current minimal popup window

Comment 3

[Tooru Fujisawa [:arai]]

:victoria, can you take a look into the above questions?

Comment 4

[Victoria Wang [:victoria]]

Hello Arai! Happy to look at this.

Just to make sure I understand the UX issue before I bring it up with others — is it correct to say that:

• Needing to have full browser controls in a popup window isn't a common user problem - it's mainly a question of correctness — it is correct to standardize all browser behavior to allow this ability.
• Popups are not a very common pattern in websites these days - partly because by default, browsers block pop-ups.
• However, for users, allowing user-permitted popup windows to open as regular tabs may be helpful in some edge cases. Or it may be desirable to be able to reuse a window by editing the location bar.

If this is true, we could add a setting that isn't too prominent, so Preferences rather than something that is shown for each popup window makes sense. Safari's "Always" vs "Automatically" design is a bit confusing - I think we would want to mention popups. It might even make sense to have our setting located under the Privacy > Pop-ups settings instead of in General, although it will be a bit harder to find. I'm imaging a checkbox that says "Show allowed popup windows as new tabs." Maybe a way to show popups as regular new windows would also be needed?

Comment 5

[Tooru Fujisawa [:arai]]

Thank you!

Sorry that the question lacks context.
I'll describe each in the answers below.

(In reply to Victoria Wang [:victoria] from comment #4)

Just to make sure I understand the UX issue before I bring it up with others — is it correct to say that:

• Needing to have full browser controls in a popup window isn't a common user problem - it's mainly a question of correctness — it is correct to standardize all browser behavior to allow this ability.

the target of standardization is a bit different than this bug.
the standardization is about the condition for opening tabs vs popups, in window.open's features parameter.

The background is that, originally, window.open's features parameter had been allowing websites to control each UI parts (toolbar, location bar, menu bar) visibility separately, on Internet Explorer, and until Firefox 75 (bug 1507375).
And Safari, Chromium, and old Edge are using features parameter only as condition to open minimal popup (no toolbar etc) or regular tab/window, instead of allowing controling each UI parts visibility.
Firefox 76 changed the behavior to follow other browsers (again, bug 1507375), but still there were differences between browsers about the condition.

Currently Firefox and Chromium uses several features (locationbar, toolbar, menubar, etc) to decide whether to open a popup, and Safari uses only width feature,
and the proposal is based on Safari's behavior.

The status of current behavior is summarized in https://arai-a.github.io/window-open-features/
and the proposal is https://github.com/whatwg/html/pull/6530 (https://arai-a.github.io/window-open-features/proposal.html for simplified change)

And the spec proposal mentions that browser can provide an option for users to override the behavior,
https://whatpr.org/html/6530/window-object.html#apis-for-creating-and-navigating-browsing-contexts-by-name step 12.4
that is, even if a website requests a popup window, user can override the browser to use non-popup.

Also, in the spec, "tab vs window" is just an implementation dependent details, and not something specified.
Given some desktop browser doesn't have "tab" concept, and some (e.g. mobile) browser doesn't have "window" concept.

Then, until Firefox 75, there were options to disallow each features parameters,
so that website cannot hide specific UI parts, and some users had been using them to get "always shown toolbar" or "always writable locationbar",
but given those options are for previous behavior, I removed those options,
and those issues come up (bug 1657738, bug 1658775, and bug 1712017)

Then, this bug is about using the proposal's "option to override the behavior" to solve the UX problem about toolbar items and location bar.

• Popups are not a very common pattern in websites these days - partly because by default, browsers block pop-ups.

Yes, the popup opened by window.open is target of popup-blocker, but to my understanding, popup is still used in many places.

according to telemetry, on beta channel, there are 2.5M calls for window.open in 4 days.

• However, for users, allowing user-permitted popup windows to open as regular tabs may be helpful in some edge cases. Or it may be desirable to be able to reuse a window by editing the location bar.

for the issue that toolbar items aren't available on popup, allowing using regular window/tab instead of popup should help, as toolbar items are available there. (to be clear, this is workaround, and this still doesn't solve the issue that popup doesn't have toolbar items)
then, for location bar, I think it's very edge case that user needs to modify location bar of popup, but anyway opening a new window/tab instead of popup will also help here as well.

Then, in the context of window.open, there's difference between opening a new regular window vs opening a new regular tab,
that is, window.open can specify the position and size of the opened popup, by left, top, width, and height features.
that would be the reason why width feature is chosen as a condition for opening popup on Safari,
and the same is the reason why I chose the Safari's behavior as standard in the proposal.

So, using a regular new window instead of a new popup still allows the website to specify the position and the size,
but using a regular new tab in the current window doesn't allow it.

For the issues in this bug, both using regular tab or using regular window solves,
but we'd need to keep the behavior difference introduced by this bug's option small I think.

If this is true, we could add a setting that isn't too prominent, so Preferences rather than something that is shown for each popup window makes sense. Safari's "Always" vs "Automatically" design is a bit confusing - I think we would want to mention popups. It might even make sense to have our setting located under the Privacy > Pop-ups settings instead of in General, although it will be a bit harder to find. I'm imaging a checkbox that says "Show allowed popup windows as new tabs." Maybe a way to show popups as regular new windows would also be needed?

Adding option under "Privacy > Pop-ups" sounds reasonable for this specific case.

But, I just realized that we may need to think a bit more about "tab vs window vs popup" handling in preferences.

About regular tab vs regular window, we already have an option for general case, that's not specific to window.open, but including regular link with target=_blank.
in about:preferences, "General" pane, "Tabs" section, "Open links in tabs instead of new windows" checkbox, that's checked by default.
If the checkbox is unchecked, Firefox opens a new window instead of a new tab, when window.open requests non-popup,
so the behavior of window.open is changed from "tab vs popup" to "window vs popup".

If we add a new option to use regular tab instead of popup, combination would become the following:

A: existing "Open links in tabs instead of new windows" option
B: new "Show allowed popup windows as new tabs" option

A	B	if popup is requested	otherwise	note
unchecked	unchecked	open popup	open new window
checked	unchecked	open popup	open new tab	default behavior
unchecked	checked	open new tab	open new window
checked	checked	open new tab	open new tab

or, if the new option is to use new window.

A: existing "Open links in tabs instead of new windows" option
B: new "Show allowed popup windows as new regular windows" option

A	B	if popup is requested	otherwise	note
unchecked	unchecked	open popup	open new window
checked	unchecked	open popup	open new tab	default behavior
unchecked	checked	open new window	open new window
checked	checked	open new window	open new tab

either way, those behavior sound a bit confusing.
maybe those 2 options needs to be integrated in some way.
(in the way similar to Safari maybe?)

Can I have your opinion?

also, I got responses in slack ux channel that this is security UX issue.
Can you bring this up with security UX team?

Comment 6

[Victoria Wang [:victoria]]

Thanks for all the background!

Yes, the popup opened by window.open is target of popup-blocker, but to my understanding, popup is still used in many places.

according to telemetry, on beta channel, there are 2.5M calls for window.open in 4 days.

Wow, good to know. Also, I learned from slack that there are allowed events (dom.popup_allowed_events) for popups which bypass popup blocking, because "user generated" popups have long been considered to be okay. That makes popups much more relevant to the modern web than I had thought!

My initial thought is we can add a checkbox with dropdown menu preference like this: [ ] Open pop-ups as [windows/tabs ▾]

The security issue mentioned in slack sounds like a question for an engineer actually. I will start a thread in #security on slack.

Also, it does sound good to find out which PM owns this so I can help in a more official way :)

Comment 7

[Tooru Fujisawa [:arai]]

Discussed in slack, and this change seems to be fine from the security POV and user-agent POV.

Now we need to decide the details about the preference, and implementation:

so far the question comes up in the discussion is:

• whether to add a hint about possible breakage, next to the checkbox/dropdown
  • if the website expects the popup be visible next to main page, using a window still works, but using a tab breaks
  • some options in preferences pane have description above the option itself
  • some options in preferences pane have "Learn more" link

About read-only location bar, we could look into it in bug 1657738, to solve the situation in minimal-popup,
given the read-only-ness might be unnecessary anyway.

Note for implementation:

• verify that content size doesn't change with regular window (width/height are used as innerWidth/innerHeight)
• verify that popup blocker works in the exactly same way, even with window/tab
• verify that using tab follows focus (foreground/background) behavior

Comment 8

[Tooru Fujisawa [:arai]]

it turns out that choosing where to open window.open target is somewhat configurable with current prefs, but it's very complicated.

• popup requested
  • No: popup is not requested (empty feature)
  • Yes: popup is requested (non empty, popup feature)
• browser.link.open_newwindow
  • 1: Open the link in the current tab.
  • 2: Open the link in a new tab in a new window.
  • 3: (default) Open the link in a new tab in the current window.
• browser.link.open_newwindow.restriction
  • 0: Always use browser.link.open_newwindow value.
  • 1: Always open the link in a new window.
  • 2: (default) If some feature is specified, open the link in a new window.
    Otherwise use browser.link.open_newwindow value.

popup requested	open_newwindow	restriction	result
No	1	0	current tab
No	1	1	new window
No	1	2	current tab
No	2	0	new window
No	2	1	new window
No	2	2	new window
No	3	0	current tab
No	3	1	new window
No	3	2	new tab
Yes	1	0	current tab
Yes	1	1	popup
Yes	1	2	popup
Yes	2	0	new window
Yes	2	1	popup
Yes	2	2	popup
Yes	3	0	new tab
Yes	3	1	popup
Yes	3	2	popup

I wonder if we should drop browser.link.open_newwindow.restriction as well, and replace it with the new pref that controls what to do when popup is requested.
so that, we can control the each case (popup is requested, popup is not requested) separately

Comment 9

[Tooru Fujisawa [:arai]]

If we're to replace browser.link.open_newwindow.restriction with the new pref,
one thing that's not covered is "when a popup is requested, open it in the current tab".
I'm not sure if that actually makes sense tho, still possible with the current prefs.

Comment 10

[Tooru Fujisawa [:arai]]

I got 2 questions:

(1) If we're going to expose the preference to about:preferences, will it be synced between desktop and mobile?

the default behavior for pop-ups is different between desktop and mobile, that

• on desktop, if a website requests a pop-up, it opens a new minimal-pop-up window
• on mobile, if a website requests a pop-up, it opens a new tab

and previously it was defined by the default value of browser.link.open_newwindow.restriction, that

• on desktop, if a website requests a pop-up, it opens makes the target a new window (and given the minimal style, it becomes minimal pop-up)
• on mobile, if a website requests a pop-up, it's handled in the same way as opening a link that opens new tab

So, the default value for the new pref should also be different between desktop and mobile,
and I'm wondering sync can break the value between them.
I'll investigate it next week.

(2) whether to provide the preference UI as "checkbox + dropdown" or "dropdown with default option"

the possible options for the pref is:

• open pop-up
• open new window
• open new tab

the simple implementation is: Open allowed pop-ups as [pop-ups/windows/tabs ▾]
where "pop-ups" is selected by default on desktop.
this can be single preference value with 1/2/3.

the another implementation (as suggested above) is: [ ] Open allowed pop-ups as [windows/tabs ▾]
where it's unchecked by default on desktop.
this can be either 2 preference values with true/false for checkbox, and 1/2 for dropdown,
or custom code that maps checkbox+dropdown and single preference value with 1/2/3.

anyway, the option UI doesn't make sense on mobile, given there's no pop-ups/windows, so we shouldn't worry about the UI on mobile.
(still need to make sure the pref value doesn't get synced between desktop/mobile)

Comment 11

[Tooru Fujisawa [:arai]]

(In reply to Tooru Fujisawa [:arai] from comment #10)

the simple implementation is: Open allowed pop-ups as [pop-ups/windows/tabs ▾]
where "pop-ups" is selected by default on desktop.
this can be single preference value with 1/2/3.

UI mock: https://www.figma.com/file/8ugVSvcSgqLvPldsiWAo1X/Pop-up-windows-preferences-pane?node-id=0%3A1
for patch stack https://treeherder.mozilla.org/jobs?repo=try&revision=80b9700489f197a577ee0bea92ba104ce82cc940

Comment 12

[Tooru Fujisawa [:arai]]

having checkbox with 2 prefs might be simpler, so that the default behavior can be hidden inside the code, instead of prefs,
and mobile code can ignore the checkbox pref and always use tab.

Comment 13

[Tooru Fujisawa [:arai]]

(In reply to Tooru Fujisawa [:arai] from comment #10)

the another implementation (as suggested above) is: [ ] Open allowed pop-ups as [windows/tabs ▾]
where it's unchecked by default on desktop.
this can be either 2 preference values with true/false for checkbox, and 1/2 for dropdown,
or custom code that maps checkbox+dropdown and single preference value with 1/2/3.

UI mock: https://www.figma.com/file/CXg7suMaKsFdJbC6wImGY7/Pop-up-windows-preferences-pane-(separate)?node-id=0%3A1
for patch stack https://treeherder.mozilla.org/jobs?repo=try&revision=b11cf038eeae5347c5594883ef75658e4e81cecf

Comment 14

[Tooru Fujisawa [:arai]]

Attachment: Bug 1714939 - Part 1: Add underlying option for selecting where to open a popup requested by window.open. r?smaug!

Depends on D129412

Comment 15

[Tooru Fujisawa [:arai]]

Attachment: Bug 1714939 - Part 2: Remove browser.link.open_newwindow.restriction pref. r?smaug!

Depends on D129984

Comment 16

[Tooru Fujisawa [:arai]]

Attachment: Bug 1714939 - Part 3: Add UI for dom.window.open.popup. r?smaug!,victoria!

Depends on D129985

Comment 17

[Tooru Fujisawa [:arai]]

Attachment: Bug 1714939 - Part 4: Add test for BarProp with overridden behavior. r?smaug!

Depends on D129986

Comment 18

[Tooru Fujisawa [:arai]]

new UI mock for radio button: https://www.figma.com/file/jAa9h8mMXccI2hrftNZ437/Pop-up-windows-preferences-pane-(radio)?node-id=0%3A1

Comment 19

[Tooru Fujisawa [:arai]]

Attachment: popup options in permission dialog

Comment 20

[Tooru Fujisawa [:arai]]

Attachment: popup options in permission dialog with window height = 719

This is the case if the content doesn't fit.

currently, the "Remove Website" and "Remove All Website" buttons are outside of scrollable area,
and the new radio buttons shouldn't be placed between the list and those buttons, it's placed under the buttons, and it's also outside of scrollable area

Comment 21

[08xjcec48]

Please make sure that the new "Open allowed pop-ups as tabs" option also works with pop-ups opened by extensions, such as the uBlock Origin logger.

Comment 22

[Tooru Fujisawa [:arai]]

(In reply to André from comment #21)

Please make sure that the new "Open allowed pop-ups as tabs" option also works with pop-ups opened by extensions, such as the uBlock Origin logger.

This option is for window.open API, and as long as the WebExtension uses the API from content script, it follows the option.

The uBlock Origin's Logger window uses completely different API browser.windows.create, and it's out of scope for this option, nor the popup blocker.
Also, for that specific use case, you can hold Shift key while clicking the button, to switch between a detached window and a tab.

Comment 23

[Simon Mainey]

https://phabricator.services.mozilla.com/D129985#4245531

I am still worried about removing browser.link.open_newwindow.restriction

It is used by Tor Browser to mitigate malicious new window sizes that aim to leak/indicate screen resolution - pinging sysrqb

Comment 24

[Tooru Fujisawa [:arai]]

(In reply to Simon Mainey from comment #23)

https://phabricator.services.mozilla.com/D129985#4245531

I am still worried about removing browser.link.open_newwindow.restriction

It is used by Tor Browser to mitigate malicious new window sizes that aim to leak/indicate screen resolution - pinging sysrqb

if the intent there is to always use tab (browser.link.open_newwindow.restriction==0 with browser.link.open_newwindow==3),
the behavior can also be achieved by the new pref in the patch as well,
by choosing "Open allowed pop-ups as tabs" (the wording will be changed), with browser.link.open_newwindow==3.
but I'd like to see the details before deciding which way to go.

Comment 25

[Simon Mainey]

(In reply to Tooru Fujisawa [:arai] from comment #24)

if the intent there is to always use tab [ snip ] the behavior can also be achieved by the new pref in the patch as well

Thanks :) I was concerned about the open window methods not covered by browser.link.open_newwindow, but if they're all "popups" (covered under the new pref) then that's all good

Comment 26

[Tooru Fujisawa [:arai]]

If the configuration is widely used also outside of Tor (so, with non-default configuration), we could have a pref value migration code to cover common cases.

Comment 27

[Tooru Fujisawa [:arai]]

According to telemetry early result:

• ~0.5% of nightly users are using browser.link.open_newwindow.restriction==0
• less than 0.01% of nightly users are using browser.link.open_newwindow.restriction==1
• ~0.05% to 0.1% of beta users are using browser.link.open_newwindow.restriction==0
• less than 0.002% of beta users are using browser.link.open_newwindow.restriction==1

will monitor the result for some more time.

Then, at least browser.link.open_newwindow.restriction==0 case should be covered by profile migration,
to reflect the browser.link.open_newwindow.restriction+browser.link.open_newwindow combination to the new pref

Comment 29

[Tooru Fujisawa [:arai]]

result for browser.link.open_newwindow.restriction pref

channel	0	1	2
Nightly	~0.5%	~0.01%	~99.5%
Beta	~0.05%	~0.001%	~99.95%
Release	~0.05%	~0.001%	~99.95%

(where 2 includes other values that fallbacks to 2)

I think the patch Part 1 is fine, as it covers browser.link.open_newwindow.restriction==0 case well.
the remaining concern is other browsers using the same code, such as Tor, that needs to be updated to use the new prefs.
(patch Part 1 has pref migration, but it works only for user pref)

Comment 30

[Meridel [:meridel]]

Hi Romain, there's a request for UX support on this. I checked in with you last month and this work wasn't a priority. Is the status still the same? Please let me know when/if we should staff this, thanks.

Comment 31

[Romain Testard [:RT]]

FYI this is still not a priority and was added to the product backlog for consideration VS competing priorities.

Comment 32

[Jackie Aguirre]

Attachment: same problem

Thanks from irbiemoxi1986.