Using emacs keybindings in Gnome, cannot close tab with Ctrl+W while address bar is in focus
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
People
(Reporter: koenvg.secondary, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
Steps to reproduce:
- Under Linux with Gnome, open the "Tweak Tool" application and change the Key Theme to "Emacs".
- In Firefox, focus the address bar (i.e. press Ctrl+L).
- Press Ctrl+W.
Actual results:
The selection or the last word of the text in the address bar gets deleted.
Expected results:
The current tab should have been closed.
This seems like a regression: it wasn't an issue before the new address bar was introduced in Firefox 75. Although I appreciate the emacs keybindings, the problem is that it is now quite hard to close a tab using just the keyboard once the address bar has come into focus. Pressing Escape doesn't remove the focus from the address bar. The only ways to close a tab once the address bar has come into focus are now either using the mouse to click the address bar out of focus, or pressing the Tab key to move the focus to the next button to the right of the address bar.
Thanks in advance for looking into this!
Comment 2•5 years ago
|
||
Assigning "Core - Widget: Cocoa" component.
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Yes, current behavior is unintuitive. As Escape is able to close main menu, I think it should be able to remove focus from address bar, too.
Comment 5•5 years ago
|
||
ESC has never removed focus from the address bar, we may be breaking another user workflow if we do that. ESC Closes the panel, then you can use tab/shift+tab to move to a different widget.
I'd be interesting to find the regrange with the new design always enabled, to better understand if it's an unxpected effect of some of the changes, or it was done on purpose. Maybe we just mark the event as handled while before it was not done.
When someone is looking for the regrange here, please try to always test with the new design enabled to come up to a specific bug and not an "enable design" meta.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 6•5 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #5)
When someone is looking for the regrange here, please try to always test with the new design enabled to come up to a specific bug and not an "enable design" meta.
Have we even established that this has anything to do with the new design?
Comment 7•5 years ago
|
||
My suspect is that it's related to auto-opening the panel. I didn't verify it yet.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
I installed gnome-tweak-tools on Ubuntu 18.04LTS, enabled emacs input (couldn't find a Key Theme field?).
I also ran "gsettings set org.gnome.desktop.interface gtk-key-theme 'Emacs'" just in case.
I see the same behavior in Firefox 74 and 75, after I enable Emacs input CTRL + W doesn't close anymore the tab, with it disabled instead CTRL + W works properly. It doesn't look like a regression to me, and unfortunately mozregression is broken today due to bug 1630940. For now I can only suggest to disable that options, that anyway will disappear in gtk 4, and ask us to support emacs bindings more broadly (for example the urlbar supports CTRL+n/p on Mac to move through results, we could extend that to Linux).
Considered Gnome is removing key themes support in gtk 4 (https://gitlab.gnome.org/GNOME/gtk/issues/1669), this seems pretty low priority.
The Address Bar code doesn't seem to do anything special about ctrl+w, so it may be something at the editor level.
Of course, if you can find a regression range pointing to an urlbar code change, we're happy to look into that.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 10•5 years ago
|
||
Note as a workaround you can use TAB to move to the next toolbar widget, after CTRL+L, that should remove focus from the urlbar.
Comment 11•5 years ago
|
||
I have attempted to find this issue's regressor, but it appears that this is not a regression since the issue occurs on versions as old as Nightly v35.0a1. Considering the status of the firefox74 flag, I also attempted reproduction on Nightly v74.0a1 and Release v75.0, Release v76.0, Beta v76.0 RC and Beta v77.0b2, but it occurs an all nevertheless.
Updated•5 years ago
|
Comment 12•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is --
(Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to --
(default, untriaged.)
Updated•5 years ago
|
Updated•4 years ago
|
Comment 13•2 years ago
|
||
I think that this was fixed in bug 1191862. Do you still reproduce this?
Comment 14•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:edgar, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 15•2 years ago
|
||
I still can reproduce this by following the STR in comment #0 on recent Nightly.
Comment 16•2 years ago
|
||
Ah, I misunderstand Actual Result vs. Expected Result. The actual result in comment 0 is what I've expected (it's probably not delete, it must be cut) because we've sometimes gotten the request to respect native key bindings in editors. Therefore, the behavior is by design. It seems that it might be better that there is alternative shortcut key to close current tab, but it's out of scope of handling key bindings, it's an issue of Firefox UI.
Description
•