Closed Bug 1757142 Opened 4 years ago Closed 3 years ago

protocol_handlers do not work in thunderbird

Categories

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

Product:
Thunderbird
Component:
Add-Ons: Extensions API
Version:
Thunderbird 99
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
111 Branch

People

(Reporter: manikulin, Assigned: john)

References

Details

Attachments

(2 files, 1 obsolete file)

Bug 1757142 - Make WebExtension protocol_handler work for Thunderbird. r=kpatenio
48 bytes, text/x-phabricator-request
Details | Review
Bug 1757142 - Fix getContentWindowOrOpenURI() to not die if aOpenWindowInfo is not specified. r=#thunderbird-reviewers
48 bytes, text/x-phabricator-request
Details | Review

Steps to reproduce:

I have tried the following test add-on implementing a custom protocol handler (it works in Firefox) expecting to be able to add some action in response to command line argument (actually invoked from another application)

{
        "manifest_version": 2,
        "name": "cuprohaex",
        "version": "0.1",
        "protocol_handlers": [{
                "protocol": "ext+phex",
                "name": "Protocol Handler Example",
                "uriTemplate": "/example.html#%s"
        }]
}

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Custom Protocol Handler WebExtensions Example</title>
  </head>
  <body>
    <h1>Custom Protocol Handler WebExtensions Example</h1>
  </body>
</html>
  • Load it as a temporary add-on.
  • try thunderbird 'ext+phex:tsturi2'
  • I mostly interested in command line argument, but tried to compose and save a message with such link as well and to click on such link

Actual results:

Nothing useful

NS_ERROR_FAILURE: MessengerContentHandler.jsm:80

in response to command line argument

TypeError: can't access property "isChromeWindow", aWindow is null
PrivateBrowsingUtils.jsm:23:9
    pbu_isWindowPrivate resource://gre/modules/PrivateBrowsingUtils.jsm:23
    launchWithURI resource://gre/modules/WebHandlerApp.jsm:115
    handleURI Choo
    openLinkExternally chrome://communicator/content/contentAreaClick.js:256
    contentAreaClick chrome://communicator/content/contentAreaClick.js:226
    onclick chrome://messenger/content/messenger.xhtml:1
NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "can't access property "isChromeWindow", aWindow is null" {file: "resource://gre/modules/PrivateBrowsingUtils.jsm" line: 23}]'[JavaScript Error: "can't access property "isChromeWindow", aWindow is null" {file: "resource://gre/modules/PrivateBrowsingUtils.jsm" line: 23}]' when calling method: [nsIWebHandlerApp::launchWithURI] ContentDispatchChooser.jsm:288

in response to a click on custom click.

Expected results:

I do not mind to just handle event with URI in add-on background script, but at least I expect a new tab with the HTML page specified as the handler.

https://webextension-api.thunderbird.net/en/latest/ mentions protocol_handlers API as one that can be used in thunderbird as well.

Flags: needinfo?(john)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(john)

I am not at all able to get it working from the command line, but I added a browser-action popup with an html link to ext+phex:tsturi2 and I get the same error from the clickHandler.

The reason for the fail is the explicit check for navigator:browser here (we use firefox code here):
https://searchfox.org/mozilla-central/rev/478ecccb085b7efd3c4773edb0480a7b2b16754c/uriloader/exthandler/WebHandlerApp.jsm#112

Which was added by bug 1521596.

When I tested this for compatibility, I used

browser.browserAction.onClicked.addListener(() => {
  browser.tabs.create({
    url: "ext+phex:tsturi2"
  });
})

Which still works. Will try a few things.

I am mostly interested in namely an action in response to command line argument. It is great that thunderbird got support of "mid:" URIs, but I do not mind to open a message in a 3-pane window to see whole thread or to choose a folder from which the message should be opened.

Assignee: nobody → john
Status: NEW → ASSIGNED

I am able to fix the API for Thunderbird (needs a patch to m-c). This will however, not enable @max to use any of the registered protocols via a command line argument, because Thunderbird does not support urls as command line parameters any more (except mid: urls).

There is at least one other add-on which would benefit from such a command line option: thunderlink. It provides an alternative to the mid: url, which also encodes other parameters beside the messageId into the url, to get around the issue, that we can have multiple messages with the same messageId.

Are there security considerations, which prevent us from allowing this again?

Geoff, do you have any info on this? Who should be consulted, if not you?

Flags: needinfo?(geoff)

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

There is at least one other add-on which would benefit from such a command line option: thunderlink.

Actually I noticed the issue when I was trying to find an alternative to thunderlink. mid: support was not in ESR release that time and I did not like an approach with a native messaging application that opens a socket for listening like in
https://github.com/CamielBouchier/cb_thunderlink/

Thunderlink is currently doing extra heavy lifting for the OS integration. Once protocol_handler is fixed for us and we decide to also bring back url command line parameters (besides mid:), then thunderbird ext+thunderlink://<hash> should work again. But it is still a long way to go and I do not know if it is doable.

mid: urls seem to work on Beta, I have not tested ESR 102.

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

mid: urls seem to work on Beta, I have not tested ESR 102.

mid: URIs worked even in Thunderbird-91 ESR. Sorry that was unclear, but I was trying to say that my case is so similar that "one other add-on" is not applicable to thunderlink. Currently I rely on mid: links with text description (to make links reciprocal, I developed an add-on that marks messages that I have in my files with notes). A minor annoyance that after opening a mid: link I often do "open message in containing folder" and close the message display tab.

So you may think that this issue is related solely to thinderlink with crucial role of CLI arguments.

my case is so similar that "one other add-on" is not applicable to thunderlink.

Understood.

So you may think that this issue is related solely to thinderlink with crucial role of CLI arguments.

We first need to fix the general support for content_handlers. I am still working on the patch for our side, to make them work for links in messages (which is using the same code path which is triggered if we would support to use it in a command line argument).

We can then create a new bug for the command line thing or handle it here as well, if we want to open it up for ext+*:// urls only. That is still to be discussed and evaluated.

Pushed by john@thunderbird.net: https://hg.mozilla.org/integration/autoland/rev/4a56b99db323 Make WebExtension protocol_handler work for Thunderbird. r=kpatenio

https://hg.mozilla.org/mozilla-central/rev/4a56b99db323

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

The bug was closed too early. Only the m-c patch (finaly) landed. Now I can fix our side.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/4c13f02997bd
Fix getContentWindowOrOpenURI() to not die if aOpenWindowInfo is not specified. r=aleca

Keywords: checkin-needed-tb

@manikulin: This is the final part of the puzzle, I think. This allows users to type

thunderbird ext+phex:something

and the command handler of installed extensions are tried to resolve it. I decided to open a tab. The WebExtension can then do whatever it needs and close the tab. Does that allow you to do what you need to do?

Flags: needinfo?(geoff) → needinfo?(manikulin)
Attachment #9325219 - Attachment description: Bug 1757142 - Add ext+[a-z]+: url pattern as command line parameter for registered command handlers of WebExtensions. r=mkmelin → Bug 1757142 - Add (ext|web)\+[a-z]+: url pattern as command line parameter for registered command handlers of WebExtensions. r=mkmelin
Depends on: 1824976

Comment on attachment 9325219 [details]
Bug 1757142 - Add (ext|web)+[a-z]+: url pattern as command line parameter for registered command handlers of WebExtensions. r=mkmelin

Revision D173713 was moved to bug 1824976. Setting attachment 9325219 [details] to obsolete.

Attachment #9325219 - Attachment is obsolete: true
Status: REOPENED → RESOLVED
Closed: 3 years ago → 3 years ago
Resolution: --- → FIXED
Keywords: leave-open

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

This is the final part of the puzzle, I think. This allows users to type

thunderbird ext+phex:something

and the command handler of installed extensions are tried to resolve it. I decided to open a tab. The WebExtension can then do whatever it needs and close the tab. Does that allow you to do what you need to do?

Thank you, John. I quickly tried 113.0a1 daily build and it looks suitable for a kind of extended mid: URI scheme that falls back to e.g. search by subject if exact Message-ID is not found.

I would prefer to avoid a flashing tab, but I do not see another way to implement the feature since protocol handler should be a page. That is why I consider behavior as acceptable.

I am in doubts if the mail.openMessageBehavior preference should be respected since handler page, strictly speaking, is not a message. I do not know if a more suitable preference exist and if it is available from extensions (besides experiments API) to provide consistent behavior for some action. Per-extension preference is a worse option.

I have noticed that window is not marked as required attention to focus it using [Ctrl+Alt+A] as for e.g. mid: links.

Flags: needinfo?(manikulin)

I am in doubts if the mail.openMessageBehavior preference should be respected since handler page, strictly speaking, is not a message. I do not know if a more suitable preference exist and if it is available from extensions (besides experiments API) to provide consistent behavior for some action. Per-extension preference is a worse option.

I see two topics merged in this question, so I answer the best I can

  1. protocol_handler pages cannot be loaded in windows, it reverts to tab if tried and prints a warning to the console
  2. to open a message from your handler page, use browser.displayMessage.open() (https://webextension-api.thunderbird.net/en/stable/messageDisplay.html#open-openproperties) which honours mail.openMessageBehavior if no location is specified.

I have noticed that window is not marked as required attention to focus it using [Ctrl+Alt+A] as for e.g. mid: links.

I have no idea what that means.

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

I am in doubts if the mail.openMessageBehavior preference should be respected since handler page, strictly speaking, is not a message.

...

  1. protocol_handler pages cannot be loaded in windows, it reverts to tab if tried and prints a warning to the console
  2. to open a message from your handler page, use browser.displayMessage.open() (https://webextension-api.thunderbird.net/en/stable/messageDisplay.html#open-openproperties) which honours mail.openMessageBehavior if no location is specified.

I had an impression that an extension may choose to create a window and a tab for its own page, e.g. to display summary related to selected messages. My idea was that such choice should respect global preference. I did not expect that due to some limitation handler page can not be opened in a dedicated window without first 3 pane mail tab.

I have noticed that window is not marked as required attention to focus it using [Ctrl+Alt+A] as for e.g. mid: links.

I have no idea what that means.

Try to open a mid: link from command line and look at the state of the thunderbird window. Precise behavior depends of window manager. E.g. KDE highlights the label of the window in the task bar. It is possible to quickly switch to this window even if it is located on another virtual desktop.

protocol_handler pages cannot be loaded in windows, it reverts to tab if tried and prints a warning to the console

My statement may have not been true entirely. It was coming from here:
https://searchfox.org/comm-central/rev/f95030ece165c435eda2aab32848b4088869ff4e/mail/base/content/mailWindow.js#883

But that seems to apply only to calls from

Cc["@mozilla.org/uriloader/external-protocol-service;1"]
.getService(Ci.nsIExternalProtocolService)
.loadURI(Services.io.newURI("ext+phex://<payload>"))

or calls from the command line.

But it seems to be possible to use browser.windows.create({type:"popup": url:"ext+phex://<payload>"}) and get it open in a popup window.

Concerning [Ctrl+Alt+A] "Activate Window Demanding Attention" KDE global shortcut to switch to window where the handler page is opened, I tried to start from the Bug #264270. Perhaps the relevant code is mail3PaneWindow.focus(); https://hg.mozilla.org/comm-central/file/tip/mail/modules/MailUtils.jsm#l245

If I do not confuse it with something else, in Qt it is called activateWindow(), see https://wiki.qt.io/Qt_project_org_faq#QWidget_::activateWindow.28.29_-_behavior_under_windows and https://stackoverflow.com/questions/6087887/bring-window-to-front-raise-show-activatewindow-don-t-work

Let us move the "attention" discussion to a new bug: bug 1827060

So protocol_handlers page may drawAttention using windows.update and if it is going to close tab and to open a window instead then no attention by default may be an advantage.

However, I noticed a couple of issues attempting to use separate popup window to present handler result:

  • 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.

I have tried the following scrip loaded from protocol_handlers HTML page and URI like ext+phex:test?popup

"use strict";

async function main() {
	const currentUrl = new URL(decodeURIComponent(location.hash.substring(1)));
	const params = currentUrl.searchParams;
	const { windowId, id: tabId } = await browser.tabs.getCurrent();
	if (params.has("popup")) {
		params.delete("popup");
		const url = new URL(location.href);
		url.hash = encodeURIComponent(currentUrl.toString());
		const popup = await browser.windows.create({type:"popup", url: url.href });
		await browser.tabs.remove(tabId);
		//window.close();
	}
	if (params.has("attention")) {
		await browser.windows.update(windowId, { drawAttention: true,})
	}
}

main();

By the way, popup window gets drawAttention flag by default.

Please do not post to this closed bug. I have created bug 1827060 for the drawAttention issue.

I have created the bug #1827594 for a configurable preference to create a new window instead of new tab for protocol_handlers or to fix the issues with code that opens popup window and closes original tab.

P.S. Perhaps add-on developer docs for protocol_handlers should recommend await browser.windows.update(windowId, {drawAttention: true}) (I can not add comments to the closed bug #1827060).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: