1787203 - Add active tab information to commands.onCommand listener

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, enhancement)

Comment 1

[John Bieling]

Attachment: Bug 1787203 - Add active tab information to commands.onCommand event. r=mkmelin

Depends on D155564

Comment 2

[John Bieling]

Try-run for check-in (updated):
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=3f45b6644ecb4e74c740b80b3da8e0813568bd70

Comment 3

[John Bieling]

I re-triggered bct5 on Linux in my try-run.

It does not fail like that locally, and I have no idea how this patch could affect those tests. The changes are solely in the WebExtension API.

Comment 4

[John Bieling]

We have a green one:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=3f45b6644ecb4e74c740b80b3da8e0813568bd70&selectedTaskRun=RP2PPv0RRxOiHWilj7ZJCQ.0

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d6d577277257
Add active tab information to commands.onCommand event. r=mkmelin

Comment 6

[max]

The feature looks promising for me. I am curious why it was not included from Chromium extensions API from the beginning. Was it intended for initiation of background actions only or are there some corner cases when determining of tab is more tricky? Determining of active tab was what I had to add to my browser add-on during implementation of keyboard shortcuts.

I have not thoroughly tested behavior in various cases like special tabs, own and foreign browser action popups, maybe something else.

Comment 7

[max]

Does it allow to reliably distinguish messageDisplay tab of normal mail window (open message in new tab) and messageDisplay window (open message in new window) without asynchronous actions? The only difference I have noticed is that tab index: 0 property is specific to messageDisplay windows. In normal mail windows first tab always contains message list. However Bug #1775246 may alleviate the issue.

Comment 8

[John Bieling]

The tab object has a type member of the current active window:
#1: "mail" for normal mail window
#2: "messageDisplay" for message tab/window
#3: "messageCompose" for message compose window

For your use case #2 does not need to be differentiated further, because both (tab and window) now have a browser_action and you can use the same code path.

If you really need to differentiate more, then looking at the tab index is a good hint I was not able to generate a condition, where (in a normal window) the first tab is not a mail tab. So if the tab type is "messageDisplay" and the tab index is 0, then it should be a stand-alone message display window.

Comment 9

[max]

(In reply to John Bieling (:TbSync) from comment #8)

If you really need to differentiate more, then looking at the tab index is a good hint I was not able to generate a condition, where (in a normal window) the first tab is not a mail tab. So if the tab type is "messageDisplay" and the tab index is 0, then it should be a stand-alone message display window.

I hope, some day the Bug #487386 and Co will be addressed, real tabs will make all windows equal and as the consequence the limitation that first tab has 3 pane layout will have no sense any more.

Comment 10

[John Bieling]

Comment on attachment 9291548 [details]
Bug 1787203 - Add active tab information to commands.onCommand event. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined:
The onCommand event is a user input event handler which has special powers and can execute certain functions. Those special powers are lost, if the event is defined as async (reason: to limit the time span between the user action and the triggered action). Requesting the current active tab is an async function call, so it is not possible for an onCommand event to learn what tab is currently active without losing its special powers. Many other events deliver the current tab as a parameter, so we do that now here as well.

Testing completed (on c-c, etc.):
On BETA for 2 months.

Risk to taking this patch (and alternatives if risky):
This looks like a huge changeset, but we just cloned the Firefox schema file for the commands API and modified our own copy. It should not cause issues.

Comment 11

[Wayne Mery (:wsmwk)]

Comment on attachment 9291548 [details]
Bug 1787203 - Add active tab information to commands.onCommand event. r=mkmelin

[Triage Comment]
Approved for esr102

Comment 12

[Wayne Mery (:wsmwk)]

Comment on attachment 9291548 [details]
Bug 1787203 - Add active tab information to commands.onCommand event. r=mkmelin

[Triage Comment]

Comment 13

[Rob Lemley [:rjl]]

Thunderbird 102.3.3:
https://hg.mozilla.org/releases/comm-esr102/rev/6abd3e2bd6e3