If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

FF doesn't respect GTK Emacs keybindings in text fields

NEW
Unassigned

Status

()

Core
Widget: Gtk
P2
major
2 years ago
3 days ago

People

(Reporter: situmam, Unassigned)

Tracking

41 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+)

(Reporter)

Description

2 years ago
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.

Updated

2 years ago
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
(Reporter)

Comment 1

2 years ago
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

2 years ago
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?
(Reporter)

Comment 4

2 years ago
(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).
(Reporter)

Comment 6

2 years ago
(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 hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
(Reporter)

Comment 11

2 years ago
(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

a year ago
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.

Comment 14

a year ago
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

a year ago
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:+
(Reporter)

Comment 16

4 months ago
(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)
(Reporter)

Comment 17

4 months ago
(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.
(Reporter)

Comment 18

3 months ago
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

3 days ago
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: → bug 1307313
You need to log in before you can comment on or make changes to this bug.