1827594 - Option to use new window instead of new tab for add-on protocol_handlers

Status: RESOLVED FIXED

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

Description

[max]

Steps to reproduce:

It is possible to specify that an extension may handle some URI scheme, see the bug #1757142. Unfortunately there is not way to choose that the page specified as protocol_handlers should be opened in a new window. It always appears in a tab of a mail window (having 3pane tab).

For messages behavior is controlled by the mail.openMessageBehavior preference.

Following the bug #1757142 comment 21, I tried to create a popup window for the handler and to close the tab originally created, see bug #1757142 comment 24.

Actual results:

I faced a couple of issues with such workaround:

• Original tab is not closed till I switch to the popup window. It happens if I switch to mail window instead of popup.
• If I switch to the created popup window at first then there is no handler tab in the mail window, but focus is lost, e.g. I can not scroll message body any more using cursor keys or PgUp/PgDn till I focus message body again.

bug #1757142 comment 0 and bug #1757142 comment 24 contain almost complete code to reproduce (<script> element should be added to the html file)

Expected results:

Either it is possible to specify that protocol_handlers page may be opened in a new window instead of new tab. (Third option may be an offsceen page, but the feature has not implemented in Firefox.)

Or issues related to the workaround are fixed: newly created tab may be reliably closed from its script and focused UI element is preserved during switching between tabs (there are improvements related to the bug #487386, but some issues remain).

Comment 1

[John Bieling]

Attachment: protocoll_handler_window.zip

When you have a complex issue, it is best to always include a reproducer add-on.

The attached add-on works for me on Windows. I first played around with your url-manipulation approach, which worked for me. I had a couple of endless open loops if I misconfigured my manifest, so I changed it for this test to simply let the script check where it has been opened. It re-opens itself in a window, if it has been opened in a tab. The tab is closed.

This works for me from the command line while Thunderbird is already loaded and when it has to be started first. Does it work for you?

If not: What OS?

Comment 2

[max]

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

This works for me from the command line while Thunderbird is already loaded and when it has to be started first. Does it work for you?

If not: What OS?

Behavior of your extension is the same: if I switch to the normal window at first then I see the handler tab. This tab disappears when I switch to the popup window.

Linux (Ubuntu-20.04 LTS focal), KDE.

I can not reproduce the issue in Firefox-111. Original tab is closed.

I have noticed the following message in thunderbird global console (for my extension):

Cannot send function call result: other side closed connection (call data: ({path:"windows.create", args:[{allowScriptsToClose:null, height:null, left:null, state:null, tabId:null, titlePreface:null, top:null, type:"popup", url:"moz-extension://83e89c63-1ae4-494d-99bd-53a6d914eda6/example.html#ext%2Bphex%3Atest%3Fa%3Dbbbb", width:null}]})) 

An additional observation: "Move to new window" item from tab context menu does not work for protocol_handlers tabs.

I have noticed that it is possible to specify tabId in windows.create properties to move the tab to new window, but it does not work as well.

Comment 3

[John Bieling]

Could you try to use

let currentTab = await browser.tabs.getCurrent();
browser.tabs.remove(currentTab.id);

instead of window.close(), does that change anything?

Comment 4

[max]

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

Could you try to use

let currentTab = await browser.tabs.getCurrent();
browser.tabs.remove(currentTab.id);

instead of window.close(), does that change anything?

I tried it before I have filed this issue. This time I have added tabs.remove to your add-on. Behavior is the same.

To some extent delegating the task to background script is a workaround:

Handler page script

	if (type !== "normal") {
		return;
	}
	await browser.runtime.sendMessage({"method": "popup"});
}

Background script

async function cphOnMessage(msg, sender) {
	if (msg?.method !== "popup") {
		console.log("Unsupported message", msg);
		return;
	}
	const moveTab = false;
	if (!moveTab) {
		await browser.tabs.remove(sender.tab.id);
	}
	await browser.windows.create(
		{type:"popup", url: sender.url, tabId: moveTab ? tabId : undefined });
	console.log("Window created, moveTab: %o", moveTab);
}

browser.runtime.onMessage.addListener((msg, sender) => void cphOnMessage(msg, sender));

The only problem is that focused element is not preserved in the mail window. E.g. if the reload button was focused on the add-on debugging page then after opening a protocol handler URI from command line, it is necessary to select this reload button again. It is inconvenient.

Comment 5

[Thomas D. (:thomas8)]

Marking as [snnot] per John's information. 20230419_1545

Comment 6

[max]

I am unsure concerning precise meaning of "[snnot]". I expect that if mail window tabs were properly implemented then the issue caused by a transient tab would be alleviated. In Firefox a focused element (e.g. a link on a web page) is preserved when I switch tabs by [Ctrl+PgUp], [Ctrl+PgDn] or when I create and remove tab a by [Ctrl+T], [Ctrl+W].

Of course, directly opening a window for protocol handler without flashing by a temporary tab would be even better. This way should be less dependent on UI implementation details.

Comment 7

[John Bieling]

[snoot] means "not supernova related". You can ignore it.

Comment 8

[John Bieling]

I was not able to reliably change the focus behavior of the debug add-on page or the account settings page. All other pages I tested (mail3PaneTab, mailMessageTab or Thunderbird settings tab) keep their focus, after the protocol_handler page has opened its tab, opened its window and then closed its tab again. If you bring the Thunderbird window back to the front, you can continue to use up/down keys to scroll a message or move up/down in the folder list or in the message list.

If this is still insufficient, I would like to propose something different: Instead of introducing a flag to open protocol_handler pages in windows or tabs (which needs to be set by the user), we could default to open such protocol_handler tabs (if opened from the console) in the background. Here: https://searchfox.org/comm-central/rev/55f55f32da68fbbae088de66b8d6c82976af191e/mail/components/MessengerContentHandler.sys.mjs#477

This allows the extension developer to decide, if

• the tab should become active (via the loaded page/script)
• the tab should remain in the background
• the tab should remain in the background, open a window and then close itself.

Comment 9

[John Bieling]

Attachment: Bug 1827594 - Open protocol_handler pages in the background, if opened from the console. r=#thunderbird-reviewers

Default to opening protocol-handler tabs in the background, if opened
via the console. Since this can be triggered externally (with
Thunderbird already running), the user might become distracted, if such
a tab suddenly opens and steals focus. If really necessary, the protocol
implementation itself can bring the tab into the foreground.

Comment 10

[max]

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

Default to opening protocol-handler tabs in the background, if opened
via the console.

Thanks, John, sounds like a reasonable workaround. Other options would require more efforts: introduce an event for add-on background script/service worker, give users and extension developers some knobs to control preferred behavior (tab/window), CLI options for new tab or window, etc.

Since this can be triggered externally (with
Thunderbird already running), the user might become distracted, if such
a tab suddenly opens and steals focus. If really necessary, the protocol
implementation itself can bring the tab into the foreground.

External call is likely caused by a user action, so it usually it is not distraction. It is rather lost context within Thunderbird.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/0fb60723835f
Open protocol_handler pages in the background, if opened from the console. r=mkmelin