Open Bug 1628655 Opened 5 years ago Updated 2 years ago

Using emacs keybindings in Gnome, cannot close tab with Ctrl+W while address bar is in focus

Categories

(Firefox :: Address Bar, defect, P3)

75 Branch
x86_64
Linux
defect
Points:
2

Tracking

()

Tracking Status
firefox-esr68 --- wontfix
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- affected

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:

  1. Under Linux with Gnome, open the "Tweak Tool" application and change the Key Theme to "Emacs".
  2. In Firefox, focus the address bar (i.e. press Ctrl+L).
  3. 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!

Assigning "Core - Widget: Cocoa" component.

Component: Untriaged → Widget: Cocoa
Product: Firefox → Core

Linux is "Widget: Gtk".

Component: Widget: Cocoa → Widget: Gtk
Priority: -- → P5

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.

Component: Widget: Gtk → Address Bar
Keywords: regression
OS: Unspecified → Linux
Priority: P5 → --
Product: Core → Firefox
Hardware: Unspecified → x86_64

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Flags: needinfo?(jan)
Blocks: 1630275

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

My suspect is that it's related to auto-opening the panel. I didn't verify it yet.

investigating...

Assignee: nobody → mak
Status: NEW → ASSIGNED
Iteration: --- → 77.2 - Apr 20 - May 3
Points: --- → 2

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.

No longer blocks: urlbar-update-1, 1630275
Status: ASSIGNED → NEW
Iteration: 77.2 - Apr 20 - May 3 → ---
Component: Address Bar → DOM: Editor
Product: Firefox → Core
Assignee: mak → nobody
Priority: P3 → --

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.

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.

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

Severity: normal → --
Severity: -- → S3
Priority: -- → P3

I think that this was fixed in bug 1191862. Do you still reproduce this?

Flags: needinfo?(mak)
Flags: needinfo?(koenvg.secondary)

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.

Flags: needinfo?(koenvg.secondary) → needinfo?(echen)

I still can reproduce this by following the STR in comment #0 on recent Nightly.

Flags: needinfo?(echen)

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.

Component: DOM: Editor → Address Bar
Flags: needinfo?(mak)
Product: Core → Firefox
You need to log in before you can comment on or make changes to this bug.