1427984 - Firefox seems to leak keypress to current tab when switching tab with Alt+N

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Gaute Hope]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171114144214

Steps to reproduce:

Open Google Calendar in Tab 1 in e.g. Monthly view
Open some other Tabs
Swap between tabs using Alt+2 Alt+3 Alt+1 etc.

This is on Linux.


Actual results:

1.) The view is changed in Google Calendar (Google Calendar has keyboard shortcuts bounds to 1,2,3,4,... for changing views).
2.) The Tab is changed (as it should)


Expected results:

1.) Nothing - no key should be sent to this page
2.) Tab should be changed

Comment 2

[Dão Gottwald [:dao]]

Did this work as expected in older Firefox versions?

Comment 3

[musicant]

Yes, it did work as expected in older Firefox versions.

I'll also post here the info I had in the duplicate bug that has another mechanism to reproduce:

Open up multiple tabs. Make sure the first one of the tabs is this page (http://unixpapa.com/js/testkey.html), so you can see what is getting passed through. Uncheck "keypress" so it doesn't suppress handling of that. Then hit alt-1, alt-2, whatever you like. Firefox will change tabs as it should, but if you switch back to this testkey page, you'll see that the shortcut was also passed through to the page itself.

Comment 4

[Gaute Hope]

Yes, it worked as expected in previous versions of Firefox (latest I tried was before the latest major UI change).

Comment 5

[Michael Cooper [:mythmon]]

I believe this is actually a regression in Google Calendar's new interface.

I tried using the test page from comment 3, and the output is the same whether I use Firefox 56 or Nightly 2018-01-10.

Google Calendar's new interface, which launched about the same time as 57, I see this content-switching behavior in both Firefox 56 and Nightly 2018-01-10. I don't see the problem using Google Calendar's old interface.

Comment 6

[Gaute Hope]

Either way, those keys should not be sent to the web page.

Comment 7

[musicant]

I just tested the old version of Google calendar -- you can still revert via calendar settings, at least until the end of the month or something when they'll force-upgrade everyone (so I read somewhere). Mike Cooper is right; only the brand new version of Google calendar that just rolled out is causing the issue to be seen. The bug was not visible on the old version. So mea cupla, it does not seem to be a specific change in Firefox 57, thanks to Mike for correcting that.

But as Gaute Hope points out, it merely means that a new version of Google Calendar is calling to attention a bug in Firefox that wasn't as obvious as it was before. Admittedly, it would be nice if Google Calendar didn't pick shortcuts that conflict with Firefox. That said, Firefox shouldn't be both passing keyboard shortcuts as content to web pages, and also acting on them, should it?

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to musicant from comment #7)
> I just tested the old version of Google calendar -- you can still revert via
> calendar settings, at least until the end of the month or something when
> they'll force-upgrade everyone (so I read somewhere). Mike Cooper is right;
> only the brand new version of Google calendar that just rolled out is
> causing the issue to be seen. The bug was not visible on the old version. So
> mea cupla, it does not seem to be a specific change in Firefox 57, thanks to
> Mike for correcting that.

I will clear "regression-" keywords based on the above investigation, thanks all.

> 
> But as Gaute Hope points out, it merely means that a new version of Google
> Calendar is calling to attention a bug in Firefox that wasn't as obvious as
> it was before. Admittedly, it would be nice if Google Calendar didn't pick
> shortcuts that conflict with Firefox. That said, Firefox shouldn't be both
> passing keyboard shortcuts as content to web pages, and also acting on them,
> should it?

Stone might be able to shed some light here.

Comment 9

[Ming-Chou Shih [:stone]]

Chrome fires keyup to the switched tab.
FF fires keypress to the original tab.
FF fires keyup to the switched tab. (same as Chrome)
Edge doesn't fire keyup to the switched tab nor the original tab.
Safari fires keyup to the switched tab. (same as Chrome)

Chrome doesn't fire keypress when pressing alt+N or ctrl+N.
FF fires keypress when pressing alt+N or ctrl+N.
Edge doesn't fire keypress when pressing alt+N or ctrl+N. (same as Chrome)
Safari doesn't fire keypress when pressing cmd+N.

It looks like the problem is about should we fire keypress event when some modifiers are held.

Comment 10

[Ming-Chou Shih [:stone]]

(In reply to Ming-Chou Shih [:stone] from comment #9)
> Chrome fires keyup to the switched tab.
> FF fires keypress to the original tab.
> FF fires keyup to the switched tab. (same as Chrome)
> Edge doesn't fire keyup to the switched tab nor the original tab.
> Safari fires keyup to the switched tab. (same as Chrome)
> 
> Chrome doesn't fire keypress when pressing alt+N or ctrl+N.
> FF fires keypress when pressing alt+N or ctrl+N.
> Edge doesn't fire keypress when pressing alt+N or ctrl+N. (same as Chrome)
> Safari doesn't fire keypress when pressing cmd+N.
> 
> It looks like the problem is about should we fire keypress event when some
> modifiers are held.

Edge fires keypress in some cases (e.g. CTRL+Z) but not in other cases (e.g. CTRL+A).

Comment 11

[Ming-Chou Shih [:stone]]

Any comments/suggestions if we stop firing keypress when the ALT is held?

Comment 12

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

We should stop dispatching keypress events when key operation doesn't cause printable character (declared by UI Evnets, see bug 968056). However, I haven't started to work on that because this causes not so serious problems (not dispatching something is more important).