1955773 - holding shift makes even window.open() open url in new window

Status: RESOLVED INVALID

(Core :: DOM: Navigation, defect)

Description

[[:jaborandi]]

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

Steps to reproduce:

1. go to https://ewnjtgouierg.github.io/ffbugs/IncorrectNewWindowLink.html
2. hold shift and click the button

Actual results:

about:blank is opened in a new window

Expected results:

it should open in a new tab

holding Shift to make link open in new window is a nice convenient feature

and i understand the intention and natural desire to control all kinds of links, including those that use javascript, but this is kind of all or nothing solution - it monopolizes Shift key and makes it impossible for rich web applications to utilize it for its own purposes in click scenarios

Comment 1

[Tooru Fujisawa [:arai]]

Can you please provide the actual use case where the web application really need to utilize the shift key on click for website-specific behavior in that situation?
Why does it need to call window.open in the same event handler? What is the shift key used for?

Basically, window.open doesn't guarantee what kind of UI is used for the newly-opened browsing context.
(See https://html.spec.whatwg.org/#window-open-steps for the details. The only things defined in the spec is "is popup" flag, which is controllable with features parameter, but it also doesn't directly control the UI. It's just an request, and user agents are allowed to override, and nothing guarantees the resulting UI)

Also, all modern browsers mostly agree with controlling the target (window, tab, etc) with modifier keys,
except for some edge cases.
(see bug 1081542 comment #31 for the combination of the modifiers, elements, events, features, and browsers)

With the testcase, Firefox and Safari agree with opening a new window when clicking with shift key.
Chrome opens a tab, but this is an edge case (not sure if it's intentional or not), where the modifier keys are ignored inside the "mousedown" event handler.
If you use "click" event instead, Chrome also agrees with opening a new window when clicking with shift key.

Comment 2

[[:jaborandi]]

i'm not sure why you always insist on specific examples?

applications do utilize meta-keys, including Shift, to define various key combinations for actions
some actions open pages with window.open() - the possible use cases are unlimited
the current behavior limits browser based applications - disallowing the use of Shift key completely for actions that open new pages
this is kind of a costly sideeffect

your point about the known convention and support by all major browser is 100% valid though

window.open() does not specify / warranty any exact method of opening the page? okay

but, as i understand, you want to make it most flexible by allowing user to control and enforce the exact method

so I guess it boils down to allowing user to customize the modifiers functions...

perhaps it should be resolved by bug 57805 then... one day)

Comment 3

[[:jaborandi]]

thinking about it again, i guess there's no way to satisfy both goals

from your explanation, I understand that you need the default behavior of Shift as now
and the possibility of customization is not a solution for apps used by many users - we cannot tell users to disable an option (what if they like the default behavior)

so probably this can be closed

Comment 4

[Tooru Fujisawa [:arai]]

(In reply to [:jaborandi] from comment #2)

i'm not sure why you always insist on specific examples?

Because, without those details provided, it's difficult to define the exact requirements (what specific combination of details explained below, and to what extent), and unfortunately this is not actionable.

If this is happening in wild and this is causing compatibility issues, or if this is happening as a part of ongoing development on certain website or framework and this is blocking it, we can look into the details how exactly the website works, what it expects, and what other browsers do.
Such as, why or whether it needs to be "mousedown" event, why and whether window.open is synchronously called or asynchronously called inside the event handler, what parameters are passed to the call, which modifier combinations are actually used, when the modifier keys are supposed to be pressed and released in the specific scenario the website's use case, how the browser behavior breaks the specific workflow, etc.

If the testcase you've attached is created as a reduced testcase from an actual website, then those information are unfortunately lost. And providing the original website and the actual use case is more helpful for further discussion.

Then, as you've seen in the linked comment above, there are some differences in how the modifiers affect (or not affect) the behavior. If certain website relies on the behavior on certain browser, we (possibly including other browsers) could look into tweaking the behavior details, to improve the interoperability and possibly make the website and its users happy. or maybe we can contact the website or framework owner to look into the interoperability.

Or, if the website doesn't work nicely on all major browsers, then the option would be to contact the website owner.