1307313 - [e10s] Some keyboard shortcuts are processed incorrectly with emacs keybindings theme when Electolysis is enabled (tabs close when attempting to delete words)

Status: NEW

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

Description

[Vladimir D. Seleznev]

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

Steps to reproduce:

Enabled GTK+ Emacs keybinding theme; enabled multiprocessing in Firefox (tested on 48, 49 and Developer Edition on Linux).


Actual results:

When Ctrl-W is pressed while textarea or input field is focused, the tab closes.


Expected results:

The previous word to the cursor should be deleted. It actually happens when multiprocessing is disabled.

Comment 1

[Makoto Kato [:m_kato]]

(In reply to Vladimir D. Seleznev from comment #0)
> User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101
> Firefox/49.0
> Build ID: 20160929132155
> 
> Steps to reproduce:
> 
> Enabled GTK+ Emacs keybinding theme; enabled multiprocessing in Firefox
> (tested on 48, 49 and Developer Edition on Linux).

Does it mean that you set gsettings set org.gnome.desktop.interface gtk-key-theme "Emacs"?

Comment 2

[Vladimir D. Seleznev]

(In reply to Makoto Kato [:m_kato] from comment #1)
> Does it mean that you set gsettings set org.gnome.desktop.interface
> gtk-key-theme "Emacs"?

Yes, it does.

$ gsettings get org.gnome.desktop.interface gtk-key-theme
'Emacs'
$ grep Emacs .gtkrc-2.0
gtk-key-theme-name = "Emacs"
$ grep Emacs .config/gtk-3.0/settings.ini
gtk-key-theme-name = Emacs

Emacs keybinding theme seems to work when multiprocessing is disabled.

Comment 3

[Makoto Kato [:m_kato]]

confirmed using Firefox 52 on Debian/sid.

Comment 4

[Makoto Kato [:m_kato]]

Native key biding is implemented by bug 977904 for e10s, but this doesn't seem to work for this situation...

Comment 5

[Makoto Kato [:m_kato]]

Ah, ctrl-k seems to work.  So maybe, ctrl-w is reserved key for our keyboard binding.

Comment 6

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

Yes, it is. I guess that native key binding is handled at keypress but reserved key is handled at keydown (the system group, in bubbling phase, on chrome's window object).

Comment 7

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

> It actually happens when multiprocessing is disabled.

Ah, this would be fixed by the fix of bug 1257617.

Comment 8

[Jim Mathies [:jimm]]

I don't understand why we expect our default ctl-w handling to be overridden by the "GTK+ Emacs keybinding theme". Is this really what we expect to happen?

Also note, under e10s we appear to have a bug with ctrl-w which closes the tab vs. closing the window. Will file that separately.

Comment 9

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #8)
> Also note, under e10s we appear to have a bug with ctrl-w which closes the
> tab vs. closing the window. Will file that separately.

nm, not a bug. ctrl-shiift-w closes the window.

Comment 10

[Karl Tomlinson (:karlt)]

(In reply to Jim Mathies [:jimm] from comment #8)
> I don't understand why we expect our default ctl-w handling to be overridden
> by the "GTK+ Emacs keybinding theme". Is this really what we expect to
> happen?

Event handlers on the elements with keyboard focus typically take priority and stopPropagation()/preventDefault() so that their ancestors do not perform any action.

It is important, for example, for text editing keyboard operations to take priority.

The widget code seems to be handling the events it receives correctly.
Current theory is that it is not getting the events.

Comment 11

[Matthew Horan]

This change in behavior is extremely surprising, upon my return to Firefox after years of using an alternative browser. In filling out text boxes throughout the day, I've accidentally closed numerous windows by accident, sometimes losing all information entered in forms on those pages.

The ctrl-w behavior is pretty ingrained in muscle memory at this point (in fact, I just closed this page by accident). In addition, there is plenty of documentation describing the previous behavior, for example: http://kb.mozillazine.org/Emacs_Keybindings_(Firefox)#The_Keybindings.

Comment 12

[lilydjwg]

I have the same issue with nightly 57. I have to be careful while typing or I'll accidentally close the tab....

However, it works in the urlbar.

Comment 14

[lilydjwg]

I just lost my progress due to this bug....

Why is nothing happening for this bug? Any thing I can do to move this bug forward?

Comment 15

[Vladimir D. Seleznev]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #7)
> > It actually happens when multiprocessing is disabled.
> 
> Ah, this would be fixed by the fix of bug 1257617.

Sorry, I found it quite ambiguously. Please, clarify: what behavior actually would be fixed: either Emacs keybinding theme would work after the bug 1257617 is fixed or Emacs keybinding theme will never work again?