Ctrl+Shift+A won't open about:addons when an editor has focus
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
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)
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details | Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0
Steps to reproduce:
- Start the latest Nightly (20211206092340).
- Try to open
about:addons
withCtrl + 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.
Assignee | ||
Comment 1•2 years ago
|
||
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.
(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.
Assignee | ||
Comment 3•2 years ago
|
||
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.
(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 haveShift
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?
Assignee | ||
Comment 5•2 years ago
|
||
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.
Assignee | ||
Comment 6•2 years ago
|
||
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.
Assignee | ||
Comment 7•2 years ago
|
||
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.
Updated•2 years ago
|
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
Comment 9•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Updated•2 years ago
|
Comment 10•2 years ago
|
||
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.
Assignee | ||
Comment 11•2 years ago
|
||
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
- Verify
Ctrl-Shift-A
not working as "Select All" in<input>
nor<textarea>
- 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
andCtrl-\
of normal Linux users, and those shortcut keys must not be used for "Select All" by any Linux users. - String changes made/needed: none
Assignee | ||
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Comment on attachment 9254269 [details]
Bug 1744580 - Make the callback of select_all
signal check select
argument r=stransky!
approved for 96.0b7
Comment 13•2 years ago
|
||
bugherder uplift |
Updated•2 years ago
|
Comment 14•2 years ago
|
||
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!
Description
•