1574756 - Alt + A working as Ctrl + A and overriding the manual extension short-key provided to U-origin block

Status: NEW

(Toolkit :: Add-ons Manager, defect, P3)

Description

[Pranav bhattarai]

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

Steps to reproduce:

1. Install Firefox in Ubuntu 19.04
2. Install Uorigin block
3. Provide a shortkey which didn't override Firefox shortkey. So I used Alt + A in 'Element picker mode' option of Firefox.
4. Try to use it any website by pressing Alt + A.
5. Doesn't work.

Actual results:

Alt + A didn't respond to my shortcut. Neither it's listed in Firefox default shortcut.

Expected results:

Alt + A shortkey should be usable.

(And also allow the user to modify default shortkey if possible)

Comment 1

[Pranav bhattarai]

Attachment: Screenshot from 2019-08-18 14-25-39.png

Comment 2

[Miruna Curtean]

This issue can be reproduced on Ubuntu 18.04.2 LTS 64-bit on Fx Release 68.0.2 (20190813150448), Beta 69.0b15 (20190819184224)and Nightly 70.0a1 (20190822215453). As expected, it does not occur on Windows 10 64-bit.
The "Alt+A" shortcut is not functional for any of the uBlock Origin Shortcut fields when testing on websites such as Youtube or Amazon. Interestingly enough, using "ALT+A" with the "Open the logger" option on the about:addons and about:support pages has had successful results.
The "Enter element picker mode" and "Enter element zapper mode" options can be used in combination with other ALT + shortkeys, such as "ALT+U".
For more details please see the attached "Alt+A behavior" GIF.

Comment 3

[Miruna Curtean]

Attachment: AltA behavior.mov

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

From what I recall Alt+A is actually handled by default on Firefox, on Linux I'm 100% sure that it is and (with a tab content currently selected) when triggered it is selecting all the page content (as Ctrl+A, which is another keyboard shortcut that triggers the same "select all" command).

Unfortunately this shortcut doesn't seem to be currently detected by the "Managing Extensions Shortcuts" about:addons view as already been used and so we are allowing it to be set without warning the user about it, even if it is not going to be actually received by the extension.

It looks that this kind of shortcuts, differently from other keyboard shortcuts used in the Firefox UI, is defined internally in the C++ layer:

• https://searchfox.org/mozilla-central/rev/5cb522c7baba24e55874809e0e206b001494c1e9/dom/events/ShortcutKeyDefinitionsForBrowserCommon.h#16

ShortcutKeyDefinitionsForBrowserCommon.h has been introduced in Firefox 65 by Bug 1419091 (as part of migrating these shortcut out of the XBL),
I'm not currently sure if we do already have a way to programmatically check if a given keyboard shortcut is going to conflict with one of these.

I'm clearing my needinfo for now and assigning one to Mark, to put this in his radar and to double-check with him if he is already aware of this issue (and if we do have any duplicates) and if he did looked into this before.