Closed Bug 1376091 Opened 5 years ago Closed 10 days ago

Alt+A fails to work as an access key on Linux, triggers cmd_selectAll instead (change Alt+A to Ctrl+A for MOZ_WIDGET_GTK)

Categories

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

54 Branch
Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
96 Branch
Tracking Status
firefox75 --- wontfix
firefox96 --- fixed

People

(Reporter: bensberg, Assigned: thomas8)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(2 files, 4 obsolete files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612121707

Steps to reproduce:

In the Dutch version of Firefox, press Alt+D to put the cursor in the address bar and type a few letters.  Then change your mind and press Alt+A.


Actual results:

All of the text in the address bar gets selected.


Expected results:

The Bookmarks menu should have opened -- in Dutch it is called "Bladwijzers", with the "a" underlined.

This happens also when the cursor is in the search bar (next to the address bar) or in a text input field (like the one I am typing this into), but NOT when the "cursor" is somewhere in the regular text of a webpage.  An equivalent problem has been reported for Swedish in bug 1308726.  From other Dutch people I have heard this does not occur with the Windows version: there Alt+A always opens the Bookmarks menu, no matter where the cursor is.

For some reason Firefox for Linux has Alt+A for "Select All" baked into it for some contexts.  Others have wondered and complained about this before: see bug 239040#c1 and bug 279163#c7.

Attached patch removes the Alt+A binding for "Select All" from the Linux version, leaving Ctrl+A to do "Select All" now everywhere.

(I can make a Mercurial patch if you wish, if you tell me how to make a shallow checkout of the relevant component.)

By the way: this is not a problem only with version 54.0 -- it has been a problem for at least seven years.
Component: Untriaged → Selection
Product: Firefox → Core
Hello, Benno, and thank you for working on this. Alt+A for selecting all is a relic from the program Emacs that has been causing trouble in the Linux version of Firefox for over ten years.
Hello Magnus.  To be precise, the Alt+A is not a relic from Emacs.  The Alt+A for "Select All" is an invention of the earliest Firefox/Netscape people, in order to allow Ctrl+A in text fields to work like it does on the Unix command line (and in several other terminal programs, like Emacs, joe, pico...).  But thirteen years ago, Ctrl+A was made to do "Select All" by default everywhere in Firefox, and only when setting "KeyThemeName" to "Emacs" somewhere in the GTK configuration files would Ctrl+A in text fields again move to the beginning of line.  But the Alt+A invention stuck around.  It should be active only when the Emacs key theme is chosen, but... on Linux it is active always, getting in the way of some Dutch and Swedish people, and probably a few others as well.
OK, Benno, so Alt+A for "Select All" was created to have Ctrl+A continue to move the cursor to the beginning of the line. I knew about the Emacs settings in the GTK configuration files.
Benno, apart from a mercurial-styled patch, you also need to ask for review. I'm a bit unsure of whom to ask, but perhaps jet might know.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bugs)
I think the file you actually want to change is:
dom/xbl/builtin/unix/platformHTMLBindings.xml
Component: Selection → Event Handling
Flags: needinfo?(bugs)
(In reply to Jet Villegas (:jet) from comment #5)
> I think the file you actually want to change is:
> dom/xbl/builtin/unix/platformHTMLBindings.xml

Is it lines 38 and 124 in http://searchfox.org/mozilla-central/source/dom/xbl/builtin/android/platformHTMLBindings.xml?
(In reply to Magnus Johansson from comment #6)
> (In reply to Jet Villegas (:jet) from comment #5)
> > I think the file you actually want to change is:
> > dom/xbl/builtin/unix/platformHTMLBindings.xml
> 
> Is it lines 38 and 124 in
> http://searchfox.org/mozilla-central/source/dom/xbl/builtin/android/
> platformHTMLBindings.xml?

Wrong link. It should have been http://searchfox.org/mozilla-central/source/dom/xbl/builtin/unix/platformHTMLBindings.xml

See lines 14, 15, 26, 27, 69 and 79.
In Firefox version 52.2.0 the cursor doesn't even have to be in a text field for having Alt+A select all. When opening a Settings tab and there press Alt+A it, however, opens the menu Arkiv.
Priority: -- → P3
Component: Event Handling → User events and focus handling
Duplicate of this bug: 1633185
Duplicate of this bug: 1308726
Component: DOM: UI Events & Focus Handling → Keyboard Navigation
Product: Core → Firefox

Turns out cmd_selectAll keys are defined here now: dom/events/unix/ShortcutKeyDefinitions.cpp

Component: Keyboard Navigation → DOM: UI Events & Focus Handling
Product: Firefox → Core
Attachment #8881025 - Attachment is obsolete: true
OS: Unspecified → Linux
Hardware: Unspecified → Desktop
Summary: Alt+A does "Select All" on Linux when cursor is in text field, instead of accessing a menu → Alt+A always does "Select All" on Linux, instead of accessing the relevant menu

Nowadays it doesn't matter where the cursor is: Alt+A always does the same as Ctrl+A: it selects all text in the active field.

Martin, do you think we can remove Alt+A as a shortcut to select all text on Linux?

Flags: needinfo?(stransky)

(In reply to Dão Gottwald [::dao] from comment #13)

Martin, do you think we can remove Alt+A as a shortcut to select all text on Linux?

Yes, I think we can use CTRL+A only, it matches recent Gtk3 settings.

Flags: needinfo?(stransky)

(In reply to Martin Stránský [:stransky] from comment #14)

Yes, I think we can use CTRL+A only, it matches recent Gtk3 settings.

Will it still be possible (by setting gtk-key-theme-name [1] to point to a file with the appropriate assignments) to make Ctrl+A go to start-of-line in text fields and make Alt+A do a select-all? Because that was the original idea behind binding Alt+A to select-all by default: to have an alternative keystroke for selecting all text when a keytheme grabbed Ctrl+A for beginning-of-line. (See comment #2.)

[1] https://developer.gnome.org/gtk3/unstable/GtkSettings.html#GtkSettings--gtk-key-theme-name

Guys, I really really think we need to do away with this Alt-A behavior.
This entails a serious accessibility issue, with menus being unreachable
by their keyboard mnemonic shortcuts because of the A key being
intercepted by its Ctrl-A -like behavior.
After a quick test of some localized versions:

  • firefox-it: the “_Aiuto” (Help) menu doesn’t open with Alt-A.
  • firefox-fr: the “_Affichage” (View) menu doesn’t open with Alt-A.
  • firefox-es: the “Archivo” (File) menu doesn’t open with Alt-A.

Ctrl-A to select all has become fairly standard IMO (only adept command
line users remember its beginning-of-line behavior, others will rather
use the Home key).

See Also: → 1739148

(In reply to Martin Stránský [:stransky] (ni? me) from comment #14)

Yes, I think we can use CTRL+A only, it matches recent Gtk3 settings.

Yes, here's some evidence: https://docs.gtk.org/gtk3/signal.TextView.select-all.html

(In reply to Dão Gottwald [::dao] from comment #11)

Turns out cmd_selectAll keys are defined here now: dom/events/unix/ShortcutKeyDefinitions.cpp

Now here:
https://searchfox.org/mozilla-central/rev/a48e21143960b383004afa9ff9411c5cf6d5a958/dom/events/ShortcutKeyDefinitions.cpp#189-197

#if defined(MOZ_WIDGET_GTK) || defined(USE_EMACS_KEY_BINDINGS)
    {u"keypress", nullptr, u"a", u"alt",         u"cmd_selectAll"},  // Linux, Emacs
#endif  // MOZ_WIDGET_GTK || USE_EMACS_KEY_BINDINGS

    /**************************************************************************
     * Emacs specific shortcut keys in <input>.
     **************************************************************************/
#if defined(USE_EMACS_KEY_BINDINGS)
    {u"keypress", nullptr, u"a", u"control", u"cmd_beginLine"},                // Emacs

Tests are here:
https://searchfox.org/mozilla-central/rev/a48e21143960b383004afa9ff9411c5cf6d5a958/dom/events/test/gtest/TestShortcutKeyDefinitions.cpp#292-294,304-305

    // charCode Modifiers,      Windows           macOS             Linux             Android           Emacs
    {0, 'a',    MODIFIER_ACCEL, u"cmd_selectAll", u"cmd_selectAll", nullptr,          u"cmd_selectAll", nullptr},
    {0, 'a',    MODIFIER_ALT,   nullptr,          nullptr,          u"cmd_selectAll", nullptr,          u"cmd_selectAll"},
    // charCode Modifiers         Windows  macOS    Linux    Android  Emacs
    {0, 'a',    MODIFIER_CONTROL, nullptr, nullptr, nullptr, nullptr, u"cmd_beginLine"},
Depends on: 1510500

Hi masayuki, you have nicely consolidated the relevant files in Bug 1510500.

Here's a proof of concept wip patch (untested).
For MOZ_WIDGET_GTK, we want to change the shortcut for cmd_selectAll

  • from Alt+A (which interferes with access keys, this bug)
  • to Ctrl+A (consistent with GTK defaults).

I've also tried to fix the test.
Not sure if there's anything else needed.

Would you be able to test and finish this on phabricator? Tia!
(Unfortunately, I'm not doing m-c phabricator patches nor cpp, and I couldn't test Linux anyway.)

Assignee: nobody → bugzilla2007
Status: NEW → ASSIGNED
Attachment #9250251 - Flags: feedback?(masayuki)
Severity: normal → S3
Keywords: access
Summary: Alt+A always does "Select All" on Linux, instead of accessing the relevant menu → Alt+A fails to work as an access key on Linux, triggers cmd_selectAll instead (change Alt+A to Ctrl+A for MOZ_WIDGET_GTK)
Blocks: 1739148
See Also: 1739148

Comment on attachment 9250251 [details] [diff] [review]
1376091_ShortcutKeyDefinitions.wip.diff

Looks fine to me. However, I don't have much time to work on this because of fixing some urgent bugs. Could you find somebody to write and test it if you want to land this ASAP?

Flags: needinfo?(bugzilla2007)
Attachment #9250251 - Flags: feedback?(masayuki) → feedback+

Cover all elements.

Attachment #9250251 - Attachment is obsolete: true
Flags: needinfo?(bugzilla2007)

Another iteration to fix another test.
A bit more aggressive in cleaning up complex expected results in input-events-cut-paste.html.ini; should work imo; try will show.

Attachment #9250532 - Attachment is obsolete: true

Test iteration

Attachment #9251465 - Attachment is obsolete: true
Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/integration/autoland/rev/853874dee29b
For MOZ_WIDGET_GTK, change shortcut for `cmd_selectAll` from Alt+A to Ctrl+A. r=masayuki
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/31723 for changes under testing/web-platform/tests
Status: ASSIGNED → RESOLVED
Closed: 10 days ago
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch
Upstream PR merged by moz-wptsync-bot

I was wondering why I started to make mistakes today and find this.
Sigh...one more Emacs-style editing key gets overridden.

(In reply to lilydjwg from comment #29)

I was wondering why I started to make mistakes today and find this.
Sigh...one more Emacs-style editing key gets overridden.

If your environment is configured as that Alt-a works as "Select All", Gecko should respect it.
https://searchfox.org/mozilla-central/rev/4aae583beac98b934e2457dbd1eb6c8d7b9e3215/widget/gtk/NativeKeyBindings.cpp#203-207
https://docs.gtk.org/gtk3/signal.TextView.select-all.html
https://docs.gtk.org/gtk3/key-bindings.html

If you see the code does not work, please file a new bug.

If your environment is configured as that Alt-a works as "Select All", Gecko should respect it.

Yes, Gecko respects it in <textarea>, in additional to Ctrl-a (which is hard-coded in Firefox), so Ctrl-a still doesn't go to beginning of line. Also there is no select-all signal for GtkEntry.

The proper solution, I think, is to provide a way to customize Firefox's own key bindings. That would be quite a lot of work though.

(In reply to lilydjwg from comment #31)

If your environment is configured as that Alt-a works as "Select All", Gecko should respect it.

Yes, Gecko respects it in <textarea>, in additional to Ctrl-a (which is hard-coded in Firefox), so Ctrl-a still doesn't go to beginning of line.

Ah, okay. It's opposite reason against my idea. So, if you configure (if possible) Ctrl-a to move caret to beginning of a line, it should be respected too since we have move_cursor signal handler:
https://searchfox.org/mozilla-central/rev/4aae583beac98b934e2457dbd1eb6c8d7b9e3215/widget/gtk/NativeKeyBindings.cpp#270-271
https://searchfox.org/mozilla-central/rev/4aae583beac98b934e2457dbd1eb6c8d7b9e3215/widget/gtk/NativeKeyBindings.cpp#152-153

Also there is no select-all signal for GtkEntry.

Indeed, it's a problem. I think that Gecko should respect select_all even in <input> if the key combination is not mapped anything other command.

The proper solution, I think, is to provide a way to customize Firefox's own key bindings. That would be quite a lot of work though.

Yes, it's really long standing issue, and one of what I want to fix, but I still don't have concrete idea how to fix it due to impacting performance...

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #32)

So, if you configure (if possible) Ctrl-a to move caret to beginning of a line, it should be respected too since we have move_cursor signal handler:

I have been configuring Ctrl-a to move to beginning of line for years, even before GTK 3 is out. These edit keys worked in Firefox for a long time until Firefox Quantum was out. Ctrl-w / n died in page content because Firefox thinks these keys shouldn't be overridable. Now Ctrl-a is gone.

The text is all selected. Maybe it moves the cursor at first, and then selects all. The result is the same.

Yes, it's really long standing issue, and one of what I want to fix, but I still don't have concrete idea how to fix it due to impacting performance...

What about a pref to turn on reading a configuration file, like the userChrome.css one? In this way at least for the majority who don't do the customization the performance is not impacted.

(In reply to lilydjwg from comment #33)

The text is all selected. Maybe it moves the cursor at first, and then selects all. The result is the same.

It shouldn't work as so. Only one command should be handled per key event. Perhaps, we fail detecting the command with signal handlers or we refer native key bindings in wrong order.

Yes, it's really long standing issue, and one of what I want to fix, but I still don't have concrete idea how to fix it due to impacting performance...

What about a pref to turn on reading a configuration file, like the userChrome.css one? In this way at least for the majority who don't do the customization the performance is not impacted.

No, initializing customizable database makes startup slower. That's the main problem to do it.

You need to log in before you can comment on or make changes to this bug.