Closed Bug 1191862 Opened 9 years ago Closed 2 years ago

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

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
41 Branch
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
99 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox99 --- fixed

People

(Reporter: situmam, Assigned: masayuki)

References

(Regression)

Details

(Keywords: regression, Whiteboard: tpi:+)

Attachments

(3 files)

Bug 1191862 - part 1: Make `nsIWidget::NativeKeyBindingsType` independent from `nsIWidget` and defined in an independent header file r=smaug!
48 bytes, text/x-phabricator-request
Details | Review
Bug 1191862 - part 2: Make `TextEventDispatcher` store writing mode at selection at receiving focus notification r=m_kato!
48 bytes, text/x-phabricator-request
Details | Review
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!
48 bytes, text/x-phabricator-request
Details | Review 
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.
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
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.
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).
Do the bindings behave as expected in other GTK3 apps or in the File -> OpenFile dialog?
(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.
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).
(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.
(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.
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).
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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
Priority: -- → P2
Whiteboard: tpi:+
(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)
(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.
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.
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).
Recent comments sound like bug 1307313, but e10s shouldn't have been enabled when this bug was first reported.
See Also: → 1307313
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
Priority: P2 → P3

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!

Flags: needinfo?(sledru)

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.

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

Flags: needinfo?(sledru) → needinfo?(situmam)

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).

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.

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).

(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).

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

Severity: major → --
Depends on: 1376091
No longer regressed by: 1376091

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).

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.

Severity: -- → S3
Component: Widget: Gtk → DOM: UI Events & Focus Handling
OS: Unspecified → All
Hardware: Unspecified → Desktop
Summary: FF doesn't respect GTK Emacs keybindings in text fields → [GTK][Mac] Firefox does not respect native key bindings which are conflict with reserved shortcut keys
No longer depends on: 1376091
Regressed by: 1154183, 1052569

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

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.

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

Assignee: nobody → masayuki
Status: NEW → ASSIGNED

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

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

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

Pushed by masayuki@d-toybox.com:
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

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

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox99: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 99 Branch
status-firefox97: --- → wontfix
status-firefox98: --- → wontfix
status-firefox-esr91: --- → wontfix
Flags: needinfo?(situmam)

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

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: