1873330 - Open a new window if shift key is held on window.open call

Status: RESOLVED FIXED

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

Description

[phpcoder2022]

Attachment: window.open bug.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

1. Open attached page
2. Press Ctrl and click on chart histogram
3. See that new tab was opened
4. Press Shift and click on chart histogram

Actual results:

New tab was opened

Expected results:

New window was opened

Chromium has so behavior and MDN reference says:

Note: Specifying any features in the windowFeatures parameter, other than noopener or noreferrer, also has the effect of requesting a popup.

Note

I need card with link, but user must can copy y-labels and view histogram title attribute in this chart. Than I putted link before elements, for that behavior. But script should have identical behavior as native link.

Comment 1

[phpcoder2022]

Attachment: window.open bug.html

Sorry, I forgot wrote else in first file. Need use this file

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Tooru Fujisawa [:arai]]

In short:

• the testcase does not request a popup
• chromium opens a new window if shift key is held. it's unrelated to your code
  • Safari matches to chromium on this behavior, and Firefox should follow it
• webpage doesn't have an ability to request a new window

The testcase does not request a popup, because of the following section in the spec:
https://html.spec.whatwg.org/multipage/nav-history-apis.html#popup-window-is-requested

The section's behavior is only for backward compatibility. It's not documented on MDN simply because the condition is too complicated and people aren't supposed to use the features like toolbar or rely on the condition (Safari doesn't follow it).

Webpage does not have an ability to control visibility of UI parts, and features like toolbar etc are used only as a condition for requesting popup or not.
Also, it's just a request for the user agent, and the user agent is allowed to do whatever the user want (whether to use tab or not, what UI to show), regardless of the request.
And also, there's no spec-ed way to request a new regular window. It's just "popup or not".
On usual desktop browsers, if popup is requested, they open a popup window with minimal UI (no toolbar, no menu, etc), and if popup is not requested, a new tab is opened. but again, this is not spec-ed and people shouldn't rely on it. for example, it's completely different on mobile browsers.

Then, the behavior difference is unrelated to features parameter.
The difference can be reproduced with the following testcase:

data:text/html,<div onclick="window.open('about:blank', '_blank')">click me</div>

Chromium opens a new window for window.open call if shift key is held.
This is not a spec-ed behavior, and it's totally up to user agent what UI to use.

Then, Safari also opens a new window if I shift-click on the above minimal testcase,
so I think Firefox should follow the behavior.

Comment 4

[Tooru Fujisawa [:arai]]

here's the result with window.open + modifiers:

	Chromium	Safari	Firefox
no feature + click	foreground tab	foreground tab	foreground tab
no feature + shift-click	window	window	foreground tab
no feature + meta-click	background tab	background tab	foreground tab
no feature + shift-meta-click	foreground tab	foreground tab	foreground tab
features="foo" + click	popup	window	popup
features="foo" + shift-click	popup	window	popup
features="foo" + meta-click	background tab	background tab	popup
features="foo" + shift-meta-click	foreground tab	foreground tab	popup

and the result with HTML anchor + modifiers:

	Chromium	Safari	Firefox
no target + click	current tab	current tab	current tab
no target + shift-click	window	(save to reading list)	window
no target + meta-click	background tab	background tab	background tab
no target + shift-meta-click	foreground tab	foreground tab	foreground tab
target="_blank" + click	foreground tab	foreground tab	foreground tab
target="_blank" + shift-click	window	(save to reading list)	window
target="_blank" + meta-click	background tab	background tab	background tab
target="_blank" + shift-meta-click	foreground tab	foreground tab	foreground tab

For HTML anchor, it's controlled by BrowserUtils.whereToOpenLink on Firefox.
we can appy the same for window.open.

Comment 5

[phpcoder2022]

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

Thanks. You understandly explained all info. Ok, I will wait Firefox enhancement with hope.

Comment 6

[Tooru Fujisawa [:arai]]

This could be an alternative to bug 1714939, given users can now control where the popup being opened by modifier keys.

Comment 7

[Tooru Fujisawa [:arai]]

Attachment: Bug 1873330 - Part 1: Add nsIBrowserDOMWindow.OPEN_NEWTAB_BACKGROUND. r?smaug!

In order to achieve "load in a new background tab" operation in window.open,
add OPEN_NEWTAB_BACKGROUND which is equivalent to OPEN_NEWTAB except for
flipping "load in background" flag.

Comment 8

[Tooru Fujisawa [:arai]]

Attachment: Bug 1873330 - Part 2: Add UserActivation::Modifiers and UserActivation::StateAndModifiers. r?smaug!

Associate modifier keys to user activation, in order to use the modifiers
in window.open initiated by the user activation.

Depends on D197859

Comment 9

[Tooru Fujisawa [:arai]]

Attachment: Bug 1873330 - Part 3: Store modifiers for user activation with input event. r?smaug!

Depends on D197860

Comment 10

[Tooru Fujisawa [:arai]]

Attachment: Bug 1873330 - Part 4: Add UserActivation::Modifiers getters. r?smaug!

Depends on D197861

Comment 11

[Tooru Fujisawa [:arai]]

Attachment: Bug 1873330 - Part 5: Add UserActivation::Modifiers parameters for window.open-related functions. r?smaug!

Pass UserActivation::Modifiers from nsGlobalWindowOuter::OpenInternal
to nsPIWindowWatcher.openWindowWithRemoteTab, through the following interfaces
and protocol:

• nsPIWindowWatcher.openWindow2
• nsIWindowProvider.provideWindow
• PContent.CreateWindow or PContent.CreateWindowInDifferentProcess
• nsPIWindowWatcher.openWindowWithRemoteTab

Depends on D197862

Comment 12

[Tooru Fujisawa [:arai]]

Attachment: Bug 1873330 - Part 6: Reflect UserActivation::Modifiers to window.open location. r?smaug!

Reflect modifiers to chromeFlags and nsIBrowserDOMWindow::OPEN_* location,
to perform the equivalent of BrowserUtils.whereToOpenLink in window.open with
modifier keys.

Depends on D197863

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/52ea5f001411
Part 1: Add nsIBrowserDOMWindow.OPEN_NEWTAB_BACKGROUND. r=smaug,geckoview-reviewers,amejiamarmol
https://hg.mozilla.org/integration/autoland/rev/9fca9bd73923
Part 2: Add UserActivation::Modifiers and UserActivation::StateAndModifiers. r=smaug
https://hg.mozilla.org/integration/autoland/rev/cd1f6085cd88
Part 3: Store modifiers for user activation with input event. r=smaug
https://hg.mozilla.org/integration/autoland/rev/66b12e633c3e
Part 4: Add UserActivation::Modifiers getters. r=smaug
https://hg.mozilla.org/integration/autoland/rev/2a11630b1ba7
Part 5: Add UserActivation::Modifiers parameters for window.open-related functions. r=smaug
https://hg.mozilla.org/integration/autoland/rev/c968fa42e944
Part 6: Reflect UserActivation::Modifiers to window.open location. r=smaug

Comment 14

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/52ea5f001411
https://hg.mozilla.org/mozilla-central/rev/9fca9bd73923
https://hg.mozilla.org/mozilla-central/rev/cd1f6085cd88
https://hg.mozilla.org/mozilla-central/rev/66b12e633c3e
https://hg.mozilla.org/mozilla-central/rev/2a11630b1ba7
https://hg.mozilla.org/mozilla-central/rev/c968fa42e944

Comment 15

[:Gijs (he/him)]

I would like to understand how this intersects with bug 1081542 and bug 935191 and the prefs mentioned there. Could you elaborate? It doesn't look like comment 4 considered this.

Comment 16

[Tooru Fujisawa [:arai]]

Good point.

The newly added code doesn't take any pref (browser.tabs.loadDivertedInBackground nor browser.tabs.loadInBackground) into account and let shift key control whether to activate the tab or not.
This doesn't match existing behavior for links.

here's Firefox behavior for (browser.tabs.loadInBackground, browser.tabs.loadDivertedInBackground) pref combinations:

	(false,false)	(false,true)	(true,false)	(true,true)
no target + click	current tab	current tab	current tab	current tab
no target + shift-click	window	window	window	window
no target + meta-click	foreground tab	foreground tab	background tab	background tab
no target + shift-meta-click	background tab	background tab	foreground tab	foreground tab
no target + middle-click	foreground tab	foreground tab	background tab	background tab
no target + shift-middle-click	background tab	background tab	foreground tab	foreground tab
target="_blank" + click	foreground tab	background tab	foreground tab	background tab
target="_blank" + shift-click	window	window	window	window
target="_blank" + meta-click	foreground tab	foreground tab	background tab	background tab
target="_blank" + shift-meta-click	background tab	background tab	foreground tab	foreground tab
target="_blank" + middle-click	foreground tab	foreground tab	background tab	background tab
target="_blank" + shift-middle-click	background tab	background tab	foreground tab	foreground tab

so, browser.tabs.loadInBackground controls the behavior for meta-click and middle-click,
and window.open should also reflect it.

then, about bug 935191, it would depend on the definition of "diverted" in term of window.open,
but it needs to be defined for regular links first in the bug.