Closed Bug 1744580 Opened 2 years ago Closed 2 years ago

Ctrl+Shift+A won't open about:addons when an editor has focus

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 96
All
Linux
defect

Tracking

()

VERIFIED FIXED
97 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox95 --- unaffected
firefox96 --- verified
firefox97 --- verified

People

(Reporter: tgnff242, Assigned: masayuki)

References

(Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

  1. Start the latest Nightly (20211206092340).
  2. Try to open about:addons with Ctrl + Shift + A.

Actual results:

Most of the time the shortcut won't work.

Expected results:

Mozregression result: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e5a124646b3cab82d079b3f6be9fd976af8a9832&tochange=49043994c79b58ba521f30ed7e9cfc470039d7c7

It's either due to Bug 1743346 or Bug 1743339, but I can't determine which. I will needinfo the assignee.

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(masayuki)

I think that it's bug 1743339 (unless you reproduce this only when <input> or <textarea> has focus). Possible solution is:

  • Mark this as INVA due to winning users' system configulation
  • Stop considering a key combination is "Select All" if Shift is pressed but it's mapped to unshifted key combination too.

The second approach is not ideal one, but it helps shortcut keys which are foo + Shift + [a-z0-9].

This is Nighly channel only regression for now so that this is not an urgent bug for 95.

Assignee: nobody → masayuki
Severity: -- → S3
Status: UNCONFIRMED → ASSIGNED
Component: General → DOM: UI Events & Focus Handling
Ever confirmed: true
Flags: needinfo?(masayuki)
OS: Unspecified → Linux
Priority: -- → P3
Regressed by: 1743339
Hardware: Unspecified → All

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

(unless you reproduce this only when <input> or <textarea> has focus).

Actually, this might be the case. The shortcut seems to not work only when a text field of either the browser (eg. the urlbar) or web content has focus.

Thank you. (This is a regression of the both bugs if <input> has focus, and also this a regression bug 1743339 if <textarea> has focus.)

I tried to write a patch for this because of unexpected behavior change. However, while I'm writing the patch, I realized that if this should be fixed, i.e., if a native shortcut key definition accepts both Shift state, we should do same things for making all shortcut keys which have Shift state available when an editor has focus.

It'd be better if and only if Firefox's global shortcut keys to be preferred rather than native editor's shortcut key definitions. However, currently, I don't think so. When user tries to modify an editable context, shortcut keys which are commonly used in the other apps too should not work for different function. So, I'd like to mark this as INVALID for now. If you believe my decision is wrong, let me know with the reasons and examples. Then, I'd reopen this.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Regressed by: 1743346
Resolution: --- → INVALID
Summary: Ctrl+Shift+A won't open about:addons → Ctrl+Shift+A won't open about:addons when an editor has focus

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

if a native shortcut key definition accepts both Shift state, we should do same things for making all shortcut keys which have Shift state available when an editor has focus.

When user tries to modify an editable context, shortcut keys which are commonly used in the other apps too should not work for different function.

That's exactly the new behaviour, though: the Shift state is disregarded when input/textarea is focused, which reduces Ctrl + Shift + A to just Ctrl + A, which is the common combination to select all text in a text editor.
Why would a user expect Ctrl + Shift + A to select all text? Is there any editor that uses it?

Also, this change, introduces a difference between OSs. Is that desirable?

Oh, indeed, Ctrl-Shift-a does not work on GTK apps' editors, but works in Firefox. I was thinking that it comes from native key bindings since we should check Shift key state strictly.

Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Ah, okay, I got it. the callback for select-all signal has select argument, but we've not referred it. Therefore, we treat "Unselect All" command is also "Select All". Gecko does not support "Unselect All" command, therefore, we should just make it check the argument.

Status: REOPENED → ASSIGNED

https://docs.gtk.org/gtk4/signal.TextView.select-all.html
The callback for select-all signal is called for both "Select All" and
"Unselect All". The callback can distinguish them with select argument,
but Gecko has never refer it. Therefore, Gecko treated "Unselect All"
shortcut keys are "Select All". However, the standard shortcut key for
"Unselect All", Ctrl-Shift-a conflicts with the shortcut key to open
about:addons of Firefox, and Gecko does not support "Unselect all"
command. Therefore, this patch makes the callback refers the argument
and not treat as "Select All" if FALSE.

Note that this removes the GTK version check at adding select_all
signal handler because the version check is older than current system
requirements.

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/07ffff89e098
Make the callback of `select_all` signal check `select` argument r=stransky
Status: ASSIGNED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Component: DOM: UI Events & Focus Handling → Widget: Gtk

The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(masayuki)

Comment on attachment 9254269 [details]
Bug 1744580 - Make the callback of select_all signal check select argument r=stransky!

Beta/Release Uplift Approval Request

  • User impact if declined: If users want to use emacs like key bindings with configuring GTK settings, "Unselect all" works as "Select All" and it conflicts with the shortcut key opening about:addons.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: 1. Set ui.key.use_select_all_in_single_line_editor to true in about:config
  1. Verify Ctrl-Shift-A not working as "Select All" in <input> nor <textarea>
  2. Verify Ctrl-\ not working as "Select All" in <input> nor <textarea>
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple fix, and this changes Ctrl-Shift-A and Ctrl-\ of normal Linux users, and those shortcut keys must not be used for "Select All" by any Linux users.
  • String changes made/needed: none
Flags: needinfo?(masayuki)
Attachment #9254269 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9254269 [details]
Bug 1744580 - Make the callback of select_all signal check select argument r=stransky!

approved for 96.0b7

Attachment #9254269 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Hello I have managed to reproduce the issue with firefox 97.0a1 (2021-12-06) on Ubuntu 20.04, I can confirm that the issue is fixed on firefox 96.0b7 and 97.0a1(2021-12-20) under Ubuntu 20.

Thank you!

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: