1653541 - WebExtensions tabs.update API cannot open mailto links

Status: VERIFIED FIXED

(Firefox :: File Handling, defect)

Description

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

I am a developer of Send Link from context menu add-on. It does a very simple think, when you click the context menu item (or page action icon) it should open a compose window of the mail client, populated some information from the current website like title or URL link. However after Firefox 78 release, I got a report it stopped working.

Simplified STR:

1. From background context of a WebExtension, call browser.tabs.update({url: 'mailto:[e-mail]'});

Expected:

• Mail application opens the same way it would open when you click on the same mailto: link on any website.

Actual behaviour:

• Nothing happens.

I was able to reproduce this in latest Nightly, so I decided to try mozregression. This led me to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a76116eb180c3cacdd1cb555d1bc4ac54c9d2f5e&tochange=b4b26ce1c20ec113d9f36f5bd824e95dea4d40cd. If you would like to re-run mozregression yourself, I recommend --profile-persistence reuse, so you install the extensions just once and that you can just click on the page action icon in the URL bar.

Comment 1

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
Add-on regression. Andreas, any idea how common this pattern is?

This was addressed for 78/78esr by the pref flip that landed there in bug 1650162.

The eventual fix from that bug that has now landed on nightly does not fix this bug.

The issue is that you're loading an external URI into a browsingcontext whose origin is not subsumed by the web extension principal of the webextension.

As a workaround, things might work if you ran something like content.top.location.href = "..." in a content script instead. Creating a new tab with an explicit about:blank URI and closing it afterwards would also probably (I think?) work.

There are a few ways we can make this "just work" - the simplest is to carve an exception for webextensions at https://hg.mozilla.org/mozilla-central/file/c00b0b97ea6558d17a40a8750a6453e7d92e5136/uriloader/exthandler/nsExternalHelperAppService.cpp#l980 .
However, I'm wondering whether the ability to load external URIs into a given tab (which would potentially load a web handler in that tab, or show a prompt if the protocol is set to "always ask") should be guarded by any particular permission on the add-on side. The aim of the code in the helper app service is to stop website A from popping up a dialog in front of website B, which carries spoofing risks. It's not clear to me that webextensions do not carry the same risk (even if the use in this extension is obviously not malicious, other protocols and other extensions could be). Rob, can you comment on this? I'm a bit surprised that the existing checks aren't sufficient here - what content principals are subsumed by webextension principals? Does it depend on the add-on's requested permissions? (which?)

Finally, wondering if this bug is sufficient cause to flip the pref again for 79... Ryan?

Comment 2

[Ryan VanderMeulen [:RyanVM]]

(In reply to :Gijs (he/him) from comment #1)

Finally, wondering if this bug is sufficient cause to flip the pref again for 79... Ryan?

I think we should, yes. Issues like these have been dot release drivers in the past.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Disabled for 79.
https://hg.mozilla.org/releases/mozilla-beta/rev/249a14ce30f0

Comment 4

[Rob Wu [:robwu]]

(In reply to :Gijs (he/him) from comment #1)

There are a few ways we can make this "just work" - the simplest is to carve an exception for webextensions at https://hg.mozilla.org/mozilla-central/file/c00b0b97ea6558d17a40a8750a6453e7d92e5136/uriloader/exthandler/nsExternalHelperAppService.cpp#l980 .

However, I'm wondering whether the ability to load external URIs into a given tab (which would potentially load a web handler in that tab, or show a prompt if the protocol is set to "always ask") should be guarded by any particular permission on the add-on side. The aim of the code in the helper app service is to stop website A from popping up a dialog in front of website B, which carries spoofing risks. It's not clear to me that webextensions do not carry the same risk (even if the use in this extension is obviously not malicious, other protocols and other extensions could be). Rob, can you comment on this?

Extensions can already change focused tabs and windows, and navigate arbitrary tabs. The "Launch application" dialog already shows the extension's URL (moz-extension://[uuid] wants to open a [scheme] link). I don't think that there is a larger risk in allowing extensions to unconditionally open URLs with external protocol handlers in existing tabs.

Despite the restriction, extensions can already open multiple dialogs with: browser.tabs.create({url: "mailto:..."})

I'm a bit surprised that the existing checks aren't sufficient here - what content principals are subsumed by webextension principals? Does it depend on the add-on's requested permissions? (which?)

Content principals from extensions (moz-extension:-scheme) do not subsume other content principals (only an ExpandedPrincipal can subsume other content principals; a content script uses an expanded principal consisting of the web page and the extension's principal).
But BasePrincipal::AddonAllowsLoad does offer a way to allow add-ons to relax the restrictions if they have host permissions: cross-origin fetches, first/third-party checks (e.g. tracking protection, SameSite cookies).

The extension framework itself relies on checkLoadURIWithPrincipal to determine whether it can navigate to certain content (the result of the check is sometimes stricter than what regular web content can do with window.open() - see bug 1622986 for example; another example is the inability to load javascript:-URLs).

Comment 5

[Andreas Wagner [:TheOne] [use NI]]

(In reply to :Gijs (he/him) from comment #1)

[Tracking Requested - why for this release]:
Add-on regression. Andreas, any idea how common this pattern is?

I am not sure. If we can come up with a reliable and robust regular expression, I could query all add-ons.

Comment 6

[:Gijs (he/him)]

Attachment: Bug 1653541 - always allow webextensions to navigate to external protocol URIs, r?robwu

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/28e0364fa3ec
always allow webextensions to navigate to external protocol URIs, r=robwu

Comment 8

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/28e0364fa3ec

Comment 9

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

I can confirm it works now, at least in the current Nightly, with security.allow_disjointed_external_uri_loads set to false.

Thank you.

Comment 10

[:Gijs (he/him)]

Thanks!