1544172 - Separate schemas for native messaging

Status: ASSIGNED

(WebExtensions :: General, task, P3)

Description

[Rob Wu [:robwu]]

Bug 1518843 wants to reuse the runtime.connectNative and runtime.sendNativeMessage APIs to support messaging from content scripts to the embedder (GeckoView).

To achieve that goal, the current patch at https://phabricator.services.mozilla.com/D22622 adds GeckoView-specific guards to toolkit code, like this:

    if (AppConstants.platform !== "android" ||
        !this.context.extension.hasPermission("geckoViewAddons")) {

... and also adds "allowedContexts": ["content"], to the API method, which also affects extensions in desktop Firefox.

Since the implementations of "native messaging" are completely different on desktop and mobile, it makes sense to have separae schemas and implementation files.

Comment 1

[Rob Wu [:robwu]]

Attachment: Bug 1544172 - Separate schemas for native messaging APIs

Desktop Firefox supports native messaging, and Fennec does not.
Because the connectNative and sendNativeMessage methods were
registered in runtime.json in toolkit/, extensions on Fennec still had
access to these APIs though. The methods are not documented, untested
and failed with an error when used.

To support extension messaging in GeckoView, bug 1518843 reuses the
connectNative and sendNativeMessage methods. The implementation is
completely different, and there is a wish to also expose the API to
content scripts.

Given these differences, it makes sense to separate the schemas and
implementations of these native messaging APIs.

Comment 2

[Rob Wu [:robwu]]

Should land in same version as bug 1518843 (i.e. Firefox 68) to avoid having one release where the nativeMessaging API is exposed to content scripts on Firefox desktop.

Comment 3

[Rob Wu [:robwu]]

runtime.sendNativeMessage and runtime.connect are existing APIs (and even predate Firefox, as the APIs were based on Chrome's). Therefore I hold a high bar for any changes to the public interface of this API.

In bug 1518843, as a side effect of adding the API to GeckoView, the API methods became available to content scripts (throws an error upon call; but previously only extension pages could see the methods at all). This change is observable by extensions, and therefore has potential to break them (if they have logic that is conditional on the existence of those APIs).

To reduce the risk of breaking extensions, I would like to restore the previous public API, before the changes of bug 1518843 reach a release version of Firefox.
Since the next ESR is going to be based on 68, I'd like to land the patch in 68 (whether on the train, or in an uplift).

Comment 4

[David Durst [:ddurst]]

I'm moving this to P3 since it isn't addressing a current breakage, and is technically a polish.

I still would like this in 68, but that's an issue for next week, at this point.