[commands] shortcut doesn't work if active tab is remote

NEW
Unassigned

Status

()

Toolkit
WebExtensions: General
P2
normal
20 days ago
20 days ago

People

(Reporter: Kusanagi Kouichi, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [commands])

Attachments

(1 attachment)

543 bytes, application/x-xpinstall
Details
(Reporter)

Description

20 days ago
Created attachment 8923740 [details]
test.xpi

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170929042838

Steps to reproduce:

1. Enable e10s
2. Load the attached extension temporarily
3. Open about:plugins
4. Press Ctrl+Shift+Z


Actual results:

Nothing happens


Expected results:

Print "test"
This sounds potentially serious. I will investigate.
Assignee: nobody → bob.silverberg
Whiteboard: investigate[commands]
This is a bit odd. I was able to reproduce this issue, but only with this specific key combo. 

Running the extension in Nightly, with the command assigned to Ctrl+Shift+Z, and with 3 tabs open to: about:debugging (1), about:plugins (2) and https://www.mozilla.org/en-US/ (3):

Pressing Ctrl+Shift+Z (actually using Command+Shift+Z because I am on a Mac) does not fire the command on 2 or 3, but does fire the command on 1, which seems to confirm the "doesn't work if active tab is remote" report. I see the same behaviour if I explicitly map the command to Command+Shift+Z.

What's odd is that if I change the key combo to Ctrl+Shift+U then it fires the command for all 3 tabs. It also fires for all 3 for MacCtrl+Shift+Z. So it seems like there's something about that specific combination that causes it not to work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
After doing a bit more digging I have found the following patterns:

Some key combos do not issue commands for either remote or non-remote tabs. These include:

Command+F (Open find dialog)
Command+Shift+H (Open history sidebar)
Command+B (Open bookmarks sidebar)
Command+D (Open bookmark dialog)

Note that these are all shortcuts that are assigned to built-in Firefox commands (indicated in parentheses). I checked the docs and it doesn't say what behaviour is expected if you assign a command to a key combo that is already in use by Firefox. Does anyone know what we expect the behaviour to be? Note that no errors or warnings are issued either when the manifest is processed or when the key combo is pressed. It's just simply ignored for the purposes of onCommand.

Some key combos issue commands for only non-remote tabs. These include:

Ctrl+Z / Ctrl+Shift+Z (Undo / Redo)
Ctrl+A (Select All)
Command+C (Copy)

Note that these are all key combos in use by Firefox, but are also common to most apps on the OS. Also, it looks like these commands affect the content process whereas the commands listed above affect the parent process, so perhaps that is what differentiates them. Again the docs don't say what behaviour is expected if you assign a command to one of these types of key combos, but the fact that the command fires for non-remote tabs and not for remote tabs does seem like a bug.

I tested some key combos that are used by the OS, but not Firefox:

Command+H (Hide all the current application's windows). This causes the command to fire in both types of windows and the key combo is ignored by the OS. That is, the windows are not hidden.

Oddly, Command+M (Minimize the current window) behaves the opposite. The window is minimized and the command does not fire on any tabs.

It seems like we need to determine exactly how the commands API is meant to behave in these different situations and then either alter the API to act how we want, or at least document the expected behaviour. For the case where a command executes in only non-remote tabs, I think we need to fix that.

I looked through the code for ext-commands.js and don't see anything there that would be affecting this, so it seems like it's happening at the platform level.
Assignee: bob.silverberg → nobody
Whiteboard: investigate[commands] → [commands]
You need to log in before you can comment on or make changes to this bug.