1828089 - Windows API: add function to open URLs in Firefox, including in private windows

Status: RESOLVED INVALID

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

Description

[Teal Dulcet [:tdulcet] (TB Council)]

This is a follow up to bug 1716200. This probably should be a built in Thunderbird feature available to all users, but as a start it could be made available to extensions. Geoff had an add-on that somewhat supported this, but it is no longer maintained and it also required setting up an external Python application to use.

Anyway, the windows.openDefaultBrowser() function of course supports opening HTTP/HTTPS URLs in the user's default browser, but this just uses the browser's defaults and does not allow the user to specify if they want a new tab, a new window or a new private window. I need a function like windows.openFirefox() that includes a disposition parameter to allow the developer to specify how the open the URL. (Disposition is the term used by other Web Extension APIs for this functionally, such as the search API and the omnibox API.) This could also support other URI types that Firefox supports, but is not a registered protocol handler for, such a data:, file: and view-source:.

Many users may not want to open all URLs with their browser's defaults, which is typically just a new tab in the last focused regular window. For example, if the user notices that a URL includes tracking parameters, they may want to open it in a private window. Currently the only workaround is for the user to copy the URL, manually open a new private window with their browser and then paste it in.

Firefox already includes a CLI to support this, which could be used by Thunderbird:

$ firefox --help | grep '<url>'
  --new-window <url> Open <url> in a new window.
  --new-tab <url>    Open <url> in a new tab.
  --private-window <url> Open <url> in a new private window.

Of course, other browsers could be supported as well, but I suspect most people using Thunderbird would also be using Firefox.

Comment 1

[John Bieling (:TbSync)]

I am leaning towards considering this request as invalid. It is beyond the Thunderbird API to define what other applications should do. We do not even know if Firefox is installed.

I explored alternative means, this is what comes to mind:

1. The native messaging approach, where you bundle your add-on with a local service script.
2. A buddy add-on for Firefox/Chrome/Edge, which registers a tabs.onCreated listener, and you forward a special crafted http(s):// url, which is picked up by the listener and evaluated. The original URL is payload and the Firefox/Chrome/Edge add-on can decide whether to update the non-private handler tab with the payload url, or close the handler tab and open a private tab
3. A buddy add-on for Firefox/Chrome/Edge, which registers a custom potocol_handler, which does the same handler logic as #2. A custom_protocol handler is the nicer and correct approach for this, but I do not know if we can get the protocol_handler url to be sent to Firefox/Chrome/Edge. With our current WIP patch for tabs.update() of bug 1716200, I fear that Thunderbird claims all such protocol_handler links (ext+*: and web+*:) for itself.

I therefore propose to change the scope of this bug to make #3 work.

Documentation for protocol_handler:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers

Comment 2

[Teal Dulcet [:tdulcet] (TB Council)]

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

I am leaning towards considering this request as invalid. It is beyond the Thunderbird API to define what other applications should do. We do not even know if Firefox is installed.

OK, I understand that this is probably my most outlandish request for a new Thunderbird API. However, there is already existing Experiment API code for this, including checking if Firefox is installed: https://stackoverflow.com/q/19010303. That code is from 2013, so I am sure it would need to be updated to work in modern Thunderbird, but that at least shows that this is possible. There are also instructions for changing some about:config settings to do this: https://kb.mozillazine.org/Changing_the_web_browser_invoked_by_Thunderbird. I am only requesting a new function to be able to do this from a pure Mail Extension.

1. The native messaging approach, where you bundle your add-on with a local service script.

Yes, this is what Geoff's add-on did, but unfortunately, it was way too complex for the average user to setup. Thunderbird can do this natively, so there should be no need for the user to have to install and setup an external application to simply open a link in a private window in their browser.

I therefore propose to change the scope of this bug to make #3 work.

Thanks for taking the time to find a workable solution for my use case. This would of course not be my ideal solution, but it could be acceptable for my use case. If you were trying to prioritize things, for my Link Creator add-on, fixing bug 1828102 and bug 1828110 would be a much higher priority for TB 115. Unrelated to this, but I am also still holding out hope that your existing patch for bug 736169 will be checked in... 😉

Comment 3

[Thomas D. (:thomas8)]

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