1191862 - [GTK][Mac] Firefox does not respect native key bindings which are conflict with reserved shortcut keys

Status: RESOLVED FIXED

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

Description

[situmam]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150727205026

Steps to reproduce:

This is best done on Ubuntu Linux.

* Switch to Emacs keybindings in GTK (http://situmam.blogspot.ca/2012/05/emacs-keybidings-in-ubuntu-1204-precise.html)
* Open a web page that has text fields in it (single or multi line)
* Type some text then press CTRL-n


Actual results:

A new firefox window is created


Expected results:

cursor should move to the beginning of the line as a proper GTK application is suppose to behave when Emacs keybindings are suppose to. BTW, this happens in nightly too, which uses GTK 3.

Comment 1

[situmam]

This issue no longer happens in FireFox 4.1 Beta but continues to happen in FF 43 Alpha. I suspect it is something to do with GTK3 migration. If you want, I am happy to provide any debugging necessary provided you can point me at the steps required as I am new at this.

Comment 2

[Loic]

The best tool to do that is Mozregression: http://mozilla.github.io/mozregression/
You can search a regression range for Nighty (if you use 32-bit builds, don't forget to add --bits=32 to the command line).

Comment 3

[Karl Tomlinson (:karlt)]

Do the bindings behave as expected in other GTK3 apps or in the File -> OpenFile dialog?

Comment 4

[situmam]

(In reply to Karl Tomlinson (ni?:karlt) from comment #3)
> Do the bindings behave as expected in other GTK3 apps or in the File ->
> OpenFile dialog?

The behaviour works just fine in the OpenFile dialog, as an example.

Comment 5

[Karl Tomlinson (:karlt)]

I'm not able to reproduce with a mozilla-central build, GTK+ 3.16.6, and gtk-key-theme-name=Emacs in ~/.config/gtk-3.0/settings.ini (which I'd expect to have the same effect as gsettings with gnome-settings-daemon).

C-n only moves to the next line if there is a next line, but even when there is not, no new window is created (no new window is expected).

Comment 6

[situmam]

(In reply to Karl Tomlinson (ni?:karlt) from comment #5)
> I'm not able to reproduce with a mozilla-central build, GTK+ 3.16.6, and
> gtk-key-theme-name=Emacs in ~/.config/gtk-3.0/settings.ini (which I'd expect
> to have the same effect as gsettings with gnome-settings-daemon).

I am not sure if this is correct of not but on my gnome-shell setup, the dconf editor clearly shows the gtk-key-theme=Emacs. However, ~/.config/gtk-3.0/settings.ini file isn't there so it is stored in ~/.config/dconf/user database file. I don't think this matter much because the behaviour of your CTL-n is correct so the dcong is correct.

> C-n only moves to the next line if there is a next line, but even when there
> is not, no new window is created (no new window is expected).

Unfortunately, I am able to reproduce this on my GTK+ 3.10 (Ubuntu 14.04) and GTK+ 3.16 (Ubuntu 15.10) and the nightly build (44.0a1 (2015-10-19)). However, it doesn't happen on my FF 42-b7 on the same OS.

Comment 7

[situmam]

Ok. I have done more investigation and came to the following realization:

* Using a basic multiline text box PgUp + Shift or PgDown + Shift highlights the text as expected (you can try it in Bugzilla right here)

* Using gmail the same behaviour doesn't work. I have to use Up or Down coupled with shift to highlight text.

This is all using the Emacs or Default bindings. Seems something unique to Gmail. Should I file a new bug?

Comment 8

[situmam]

Ok. Pressed Save Changes too soon. Here is the bug (1232656) that captures what I described in my previous comment. I recommend we close this bug but not sure if I can do that or leave it up to you guys to do so.

Comment 9

[situmam]

(In reply to situmam from comment #7)
> Ok. I have done more investigation and came to the following realization:
> 
> * Using a basic multiline text box PgUp + Shift or PgDown + Shift highlights
> the text as expected (you can try it in Bugzilla right here)
> 
> * Using gmail the same behaviour doesn't work. I have to use Up or Down
> coupled with shift to highlight text.
> 
> This is all using the Emacs or Default bindings. Seems something unique to
> Gmail. Should I file a new bug?

Please discard. This is wrong.

Comment 10

[situmam]

(In reply to situmam from comment #8)
> Ok. Pressed Save Changes too soon. Here is the bug (1232656) that captures
> what I described in my previous comment. I recommend we close this bug but
> not sure if I can do that or leave it up to you guys to do so.

Please discard. This is wrong comment for the wrong bug. Apologies.

Comment 11

[situmam]

(In reply to situmam from comment #6)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #5)
> > I'm not able to reproduce with a mozilla-central build, GTK+ 3.16.6, and
> > gtk-key-theme-name=Emacs in ~/.config/gtk-3.0/settings.ini (which I'd expect
> > to have the same effect as gsettings with gnome-settings-daemon).
> 
> I am not sure if this is correct of not but on my gnome-shell setup, the
> dconf editor clearly shows the gtk-key-theme=Emacs. However,
> ~/.config/gtk-3.0/settings.ini file isn't there so it is stored in
> ~/.config/dconf/user database file. I don't think this matter much because
> the behaviour of your CTL-n is correct so the dcong is correct.
> 
> > C-n only moves to the next line if there is a next line, but even when there
> > is not, no new window is created (no new window is expected).
> 
> Unfortunately, I am able to reproduce this on my GTK+ 3.10 (Ubuntu 14.04)

I tried again today using the 47.0a1 (2016-02-05) build of firefox and CTRL-n opens a new window using the Emacs GTK keybindings. I will continue to investigate and ask for others to confirm.

Comment 12

[Akkana Peck]

Confirming. I just got upgraded today to 46.0.1 and now nearly every editing keystroke I type, in the URLbar or any text field -- e.g. ctrl-H, ctrl-B -- opens up a sidebar instead of editing as it always has in the past. Ctrl-N, as reported here, does indeed open a new window.

This is a very serious regression for anyone who depends on these bindings and needs to use the browser to type anything nontrivial (e.g. mail, bug reports).

Comment 13

[Karl Tomlinson (:karlt)]

Do the keybindings behave as expected in the single and multiline text entry/view in gtk3-widget-factory?  The Ubuntu package is gtk-3-examples.

Comment 14

[Akkana Peck]

Karl Tomlinson's comment 5 is the ticket (I'd missed it on the first read-through) -- once I realized GTK3 was the issue, I tried a bunch of different ways to switch themes (there are 4-5 different ways if you google for it) and the one that worked for me was the same one Karl mentions, adding to ~/.config/gtk-3.0/settings.ini
gtk-key-theme-name = Emacs

A more common suggestion,
gsettings set org.gnome.desktop.interface gtk-key-theme "Emacs"
didn't work. Can't test gnome-settings-daemon since I don't run gnome.

Comment 15

[Lars Viklund]

As a note to someone also trying to piece together a ~/.config/gtk-3.0/settings.ini from scratch, the key must be under a [Settings] section and the line seems to need a trailing newline.

[Settings]
gtk-key-theme-name = Emacs

Comment 16

[situmam]

(In reply to Karl Tomlinson (:karlt) from comment #13)
> Do the keybindings behave as expected in the single and multiline text
> entry/view in gtk3-widget-factory?  The Ubuntu package is gtk-3-examples.

I just tested it using the multiline view and the Entry section and all behaved properly. However, it is still not behaving as expected in FF 54.0b10 (Using Ubuntu PPA)

Comment 17

[situmam]

(In reply to Lars Viklund from comment #15)
> As a note to someone also trying to piece together a
> ~/.config/gtk-3.0/settings.ini from scratch, the key must be under a
> [Settings] section and the line seems to need a trailing newline.
> 
> [Settings]
> gtk-key-theme-name = Emacs

I tried that with both FF 54.0b10 and the the nightly build (two days old) and I still have the same problem. Please do note that I change the GTK keybindings theme to "Emacs" using the Gnome-Tweak tool and I am running Ubuntu 16.04 Unity7.  

BTW, the "Emacs" keybindings works just fine (CTRL-n moves down one line) using the Hypertext test widget in the gtk3-demo application. However, when I do that in this text box (while writing this comment), I get a new window created.

Comment 18

[situmam]

I think this issue is more about how the hotkeys such as CTRL-N are interpreted if you are in editing text more or not.

Comment 19

[lilydjwg]

I have the same problem: some GTK keybindings don't work. Ctrl-p works for me with this textarea, but not Ctrl-n. Nor does Ctrl-w (to delete a word; however this one works in the urlbar).

Comment 20

[Karl Tomlinson (:karlt)]

Recent comments sound like bug 1307313, but e10s shouldn't have been enabled when this bug was first reported.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 22

[Negritas Sergiu, Desktop QA]

Hello! I have tried to reproduce the issue 95.0b4 (64-bit), 96.0a1(2021-11-08), 94.0.1 and 91.3.0esr on Ubuntu 20.
As in the description I have installed the Emacs gtk key theme and I can confirm that the keybindings are working on the latest firefox builds except for the CTRL+N which I brings up a new firefox window.

However CTRL+B does not bring the bookmarks menu.

From what I understand in the description the issue is for the CTRL+N. But I have tried using it in text a text editor and it has no function assigned to it.

Is this still a valid issue or we can close it as WFM?

Thank you!

Comment 23

[lilydjwg]

I can confirm that Emacs-style keys work in gtk3-demo's text view demo. Ctrl-P/N moves the cursor up or down as expected. Also Ctrl-W deletes a word. These keys do not work in Firefox's <textarea> or <input>. If I were trying to delete a word by Ctrl-W here, my tab would be closed instead.

My Firefox nightly is three-day old, and my GTK 3 version is 1:3.24.30+90+g20be04f7ac-1 on Arch Linux.

Comment 24

[Sylvestre Ledru [:Sylvestre]]

not sure why you need info me. redirecting to the reported.

Comment 25

[Akkana Peck]

Ctrl-W doesn't work, as lilydjwg mentioned. It used to be possible to override the "close window" binding so as to use ^W, but now it's hardwired in a stronger way that doesn't seem possible to override, so typing Ctrl-W to delete the last word instead closes the current tab and there's no option to prevent that. I accidentally close tabs in the middle of typing something fairly often (since Ctrl-W works in most other apps and is ingrained in my fingers).

Comment 26

[Andreas Vögele]

I just had to downgrade from Firefox 96.0 to Firefox 95.0.2 on Linux as the Emacs keybindings no longer work. It's not only the text fields that no longer accept the Emacs keyboard shortcuts. The whole user interface is affected.

Comment 27

[Markus Koller]

I'm running Firefox 96.0.1 on Linux, and Emacs shortcuts still mostly work here (I tried Ctrl+E, Ctrl+U, Ctrl+K, Ctrl+B/F, Alt+B/F).

But Ctrl+A now selects all instead of moving to the beginning of the line, which is especially annoying in the URL bar (and there we also already have Ctrl+L which does the same).

Comment 28

[Martin Stránský [:stransky] (ni? me)]

Can you try mozregression tool if that broke recently?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 29

[Markus Koller]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #28)

Can you try mozregression tool if that broke recently?

Thanks! Here's the result:

2022-01-28T14:46:21.098000: INFO : Narrowed integration regression window from [813c32c6, 853874de] (3 builds) to [67888a3f, 853874de] (2 builds) (~1 steps left)
2022-01-28T14:46:22.365000: DEBUG : Found commit message:

Bug 1376091 - For MOZ_WIDGET_GTK, change shortcut for cmd_selectAll from Alt+A to Ctrl+A. r=masayuki

With this patch, we stop registering Alt+A as a shortcut key for "Select All" on Linux and register Ctrl+A instead, which is the default shortcut for the command on other GTK applications, Chromium, and Windows. Alt+A was also causing a bug for menubar navigation because it hijacks Alt+A access key. This patch does not stop Linux environments from registering Alt+A as a shortcut key for "Select All"; it just drops Gecko's additional, non-standard shortcut key definition, and defaults to Ctrl+A instead.

Differential Revision: https://phabricator.services.mozilla.com/D131062

I checked with Firefox 95 again and I can indeed use Alt+A there to select all in text fields. Ctrl+A on the page (without having a text field focused) still selects all too, both in 95 and 96.

Maybe instead of Alt+A Firefox could use Ctrl+Shift+A as a fallback shortcut when Emacs keys are enabled. Or alternatively, not set a fallback shortcut at all (although I can see the usefulness).

Comment 30

[Markus Koller]

Oh wait, Ctrl+Shift+A already opens Addons 😅

Comment 31

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

The new issue was mentioned in the release note: https://www.mozilla.org/en-US/firefox/96.0/releasenotes/

It's been already fixed by bug 1743339 and bug 1743346, however, due to the release schedule, these fixes will be enabled by default in 97 (bug 1747326).

Comment 32

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

Ctrl-N etc cases are special cases. They are "reserved" by Firefox for making users who use only keyboard never locked into a web app which prevents focus move with handling all keyboard events.

However, indeed, native key bindings should be respected at checking whether reserved shortcut keys or not.

Comment 33

[Markus Koller]

Thanks, setting ui.key.textcontrol.prefer_native_key_bindings_over_builtin_shortcut_key_definitions = true fixed it for me!

Comment 34

[Akkana Peck]

In 96.0.3, downloaded from the website just now, setting ui.key.textcontrol.prefer_native_key_bindings_over_builtin_shortcut_key_definitions fixes ctrl-A but it doesn't fix ctrl-W. Go to a page with a text field on it, type some words and then ctrl-W, and firefox exits (if it's the only tab) instead of deleting the word to the left of the cursor.

Comment 35

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

It seems that I can fix this in a couple of days. I'm blocked by posted reviews now. Therefore, I'm trying...

Comment 36

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

Attachment: Bug 1191862 - part 1: Make `nsIWidget::NativeKeyBindingsType` independent from `nsIWidget` and defined in an independent header file r=smaug!

I'd like to use it in IMEData.h. However, adding new include into it may
cause bustage with MinGW, and it's included by nsIWidget.h because nsIWidget
requires some classes defined in IMEData.h. Therefore, I'd like to make a
new header file for avoiding the include hell.

Depends on D137610

Comment 37

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

Attachment: Bug 1191862 - part 2: Make `TextEventDispatcher` store writing mode at selection at receiving focus notification r=m_kato!

Querying selection for getting writing mode may run script in the main process
if focus is in it. For avoiding new users of writing mode at selection only
when the value is required during an editable content has focus,
TextEventDispatcher should always store writing mode at receiving focus
notification.

Depends on D138007

Comment 38

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

Attachment: Bug 1191862 - part 3: Make `GlobalKeyListener` not reserve key combination which is mapped to an edit command or a navigation command by native key bindings r=NeilDeakin!,smaug!

Users may map reserved shortcut keys of Firefox/Thunderbird as an editing
command or a navigation command. Therefore if and only if an editable element
has focus and a reserved key combination is mapped to an editing command or
a navigation command by the system settings, we should allow to dispatch it
into the content and work it as what user expects.

With this change, keyboard only users may loose some shortcut keys to leave
from a web content which blocks keyboard focus in it. However, there may
be another reserved shortcut keys to escape from such web apps only with
keyboard because it's hard to think that all reserved shortcut keys conflict
with users' settings.

Depends on D138008

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1972ca43bb03
part 1: Make `nsIWidget::NativeKeyBindingsType` independent from `nsIWidget` and defined in an independent header file r=smaug
https://hg.mozilla.org/integration/autoland/rev/04c035fb4297
part 2: Make `TextEventDispatcher` store writing mode at selection at receiving focus notification r=m_kato
https://hg.mozilla.org/integration/autoland/rev/d318d856d6bf
part 3: Make `GlobalKeyListener` not reserve key combination which is mapped to an edit command or a navigation command by native key bindings r=NeilDeakin,smaug

Comment 40

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/1972ca43bb03
https://hg.mozilla.org/mozilla-central/rev/04c035fb4297
https://hg.mozilla.org/mozilla-central/rev/d318d856d6bf

Comment 41

[lilydjwg]

Thank you, masayuki and all people who have worked on this! I've regained my Ctrl-w shortcut.