1301476 - EventListener for CTRL-N doesn't work Firefox 48 as in Firefox 47

Status: RESOLVED INVALID

(Firefox :: Keyboard Navigation, defect)

Description

[Jan Fader]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.92 Safari/537.36

Steps to reproduce:

Open https://jsfiddle.net/wphdcg5f/4/ focus input field and press CTRL-N


Actual results:

New browser window gets opened


Expected results:

As in Firefox 47.0.1 no new browser window should open. Instead the alert-box should be shown.

Comment 1

[Jan Fader]

After the latest upgrade from Firefox 47 to 48 some keyboard shortcuts in our web-based erp-application beeline doesn't work any longer. These shortcuts (for example: CTRL-N to create a new object) are essentiell to our customers.

We don't want to force all of our customers and their users to learn new shortcuts after changing it. Other webapplications (like f.e. zarafa/kopano or online-office-suites) are suffering from the same problem too. Our team is already discussing about dropping firefox as our development and recommended browser for all our web-based applications.

Comment 2

[Alice0775 White]

[Tracking Requested - why for this release]: Web page event handling is broken with/without e10s


I got different regression window with e10s and without e10s.

Regression window(with e10s):
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=c154c877d4e4&tochange=a5c70a2fab90

Regressed by: Bug 1074971

Regression window(without e10s):
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5dafc240fe5dce667799a3ca0e7925d421abe399&tochange=b226ad5571c4ee17b25c60e9c037b9dc25b7b683

Regressed by: Bug 1203059

Comment 3

[Mike Taylor [:miketaylr]]

Per Bug 1203059, this is intended behavior. See https://bugzilla.mozilla.org/show_bug.cgi?id=1203059#c17 (and other comments).

> Our team is already discussing about dropping firefox as our development and recommended browser for all our web-based applications.

Chrome and Safari also disallow Ctrl/Cmd + N, so it seems like an alternate shortcut scheme would be more user friendly in the long run (even if they have to re-learn them).

Comment 4

[Jan Fader]

Thanks for looking at this.

As you mentioned Chrome disallow CTRL+N too but provides an application mode where all shortcuts from the webapplication works and that also provides additional value to our users (separated window and icon based on favicon). This is already requested in https://bugzilla.mozilla.org/show_bug.cgi?id=1283670

Comment 5

[Mike Taylor [:miketaylr]]

Hi Jan,

I'm not aware of the application mode of Chrome, can you link to some docs? 
(Or is that another term for Chrome apps? http://blog.chromium.org/2016/08/from-chrome-apps-to-web.html)

Comment 6

[Jan Fader]

Hi Mike

It's mentioned on a lot of blogs like http://www.jhh.me/blog/2013/11/11/running-web-apps-in-google-chrome-app-mode/ and documented in "Add a website as an app" on https://support.google.com/chrome/answer/3060053 

It's also documented in the man page of chrome:

       --app=URL
              Runs URL in "app mode": with no browser toolbars.

Comment 7

[:Felipe Gomes (needinfo for replies!)]

This was an intentional change, as you can tell. We're generally against adding more prefs to control behavior like this, but in this case I don't see much harm and I think there's some value in having a pref to disable this. Masayuki, what do you think?

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't think that it's worthwhile to change our behavior. When the other browsers provide alternative ways web applications to handle such key combinations, we'd follow them, though. We should mark this as INVA or WONTFIX.

Comment 9

[Marcia Knous [:marcia]]

Per Comment 8, adjusting the tracking flags.