Vladimir D. Seleznev Reporter
	Description • 8 years ago

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.

	Makoto Kato [:m_kato]
	Comment 1 • 8 years ago

(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"?

	Vladimir D. Seleznev Reporter
	Comment 2 • 8 years ago

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

	Makoto Kato [:m_kato]
	Comment 3 • 8 years ago

confirmed using Firefox 52 on Debian/sid.

	Makoto Kato [:m_kato]
	Comment 4 • 8 years ago

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

	Makoto Kato [:m_kato]
	Comment 5 • 8 years ago

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

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 6 • 8 years ago

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

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 7 • 8 years ago

> It actually happens when multiprocessing is disabled.

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

	Jim Mathies [:jimm]
	Comment 8 • 8 years ago

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.

	Jim Mathies [:jimm]
	Comment 9 • 8 years ago

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

	Karl Tomlinson (:karlt)
	Comment 10 • 8 years ago

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

	Matthew Horan
	Comment 11 • 7 years ago

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.

	lilydjwg
	Comment 12 • 7 years ago

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.

	lilydjwg
	Comment 14 • 7 years ago

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?

	Vladimir D. Seleznev Reporter
	Comment 15 • 7 years ago

(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?