1233406 - How to implement web extensions in browser.html

Status: RESOLVED INVALID

(WebExtensions :: General, defect, P5)

Description

[Alexandre Poirot [:ochameau]]

Let's say we would like to implement web extensions in browser.html, or something similar like gaia. It means that the UI isn't browser.xul. It isn't XUL anymore and above all, it is no longer running in system principal.
Instead, it uses HTML and a lower privilege context. It may have some extra permissions, but it isn't chrome/system.

The concrete issue is about implementing the various ext-windows, ext-tabs, ext-browserAction javascript modules.
These modules would most likely be running with the same privileges and may be in the same context than browser.html/gaia. So it's not system principal.
We could easily implement them in chrome, by running some jsm, xpcom or something alike, but that involves having to play with xraywrappers and unecessarely involve chrome permissions whereas we just do some DOM operations.

So. I had an idea: What about using WebIDL to implement the chrome APIs?

This is great for two reasons:
 - we get a nice WebIDL file specifying what we implement,
 - we don't have to do any Cu.cloneInto/Cu.exportFunction nor any wrapper crasyness.

The blocker is defining them from content. With some limited hacks in chrome, I've actually been able to implement a WebIDL from a content scope.
(I just had to call MyInterface._create(targetScope, contentImplementation) from chrome scope)
But I couldn't implement any API involving a function argument.
The implementation living in the content is denied to call it as it seems to be considered as an object, or just, we forbid calling this function.

Here is the various scopes we have:

# browser-html/ext-tabs.js (content)

  var myImpl = {
    create(properties, callback) {
      // Play with browser.html DOM
      callback(); // <= here, I can't call this function given that I'm trying
                  // to call another content function, which is from another
                  // content.
                  // But I wish the WebIDL would somehow allow that if I say
                  // that I'm expecting a function.
    }
  };

# some chrome glue (chrome)

  var tabsAPI = MyInterface._create(backgroundPageScope, myImpl);
  setBackgroundPageAPI("tabs", tabsAPI);

# background page (another, different, content)

  chrome.tabs.create({..}, function () {});

# MyInterface.webidl

callback VoidFunction = void ();
interface MyInterface {
  void create(object properties, VoidFunction callback);
};


I would easily accept "Just use chrome" as an answer, but I think it is worth asking given WebIDL possible benefits.

Comment 1

[Gabor Krizsanits (INACTIVE)]

I'm CC-ing Bill because I wonder what does he think in general about using WebIDL to describe the Web Extensions API, plus he can correct me here. I see some advantages of it but also feels a bit too heavy weight maybe, so I never pushed this idea too hard. Not to mention that it would be a huge change now.

Anyway right now, it is not the general direction we're moving forward, so I would prefer a more traditional approach to inject WebExtensions API into browser.html. I think we should just recognize this scope from it's URI and then just apply injectAPI on it automatically from WebExtensions (Extension.jsm?). That should solve all your problems.

That being said, I don't think there is a (safe/sane) way to solve the callback problem in your case, and I don't see why would you want your API implementation have content privilege on the first place. You're myImp implementation couldn't do much interesting without system principal anyway.

Comment 2

[Alexandre Poirot [:ochameau]]

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #1)
> That being said, I don't think there is a (safe/sane) way to solve the
> callback problem in your case,

It would be about having a magic keyword in WebIDL to do something like what Cu.exportFunction does, but in the C++ wraper WebIDL craft. But I really doubt it exists as WebIDL has never been designed for implementing it from content.

> and I don't see why would you want your API
> implementation have content privilege on the first place. You're myImp
> implementation couldn't do much interesting without system principal anyway.

I think you confused as everything is chrome in existing Firefox desktop.
But it is very wrong on FxOS in gaia. The system app handle manyyy things and has a content principal.
browser.html has the same layout. Everyone wants to get away from the "everything is chrome", which is commendable effort.

See all these ext-*.js APIs here:
  http://mxr.mozilla.org/mozilla-central/source/browser/components/extensions/
They need to be rewritten for FxOS or browser.html. But most of the related components, if not all, live in the system app or the browser html page which are content.

Also note that all toolkit apis from here:
  http://mxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/
seem to all work as-is on browser.html and may be also fxos?
And I don't suggest to change anything to these one. I'm mostly wondering for the other one related to browser UI.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

A lot of the WebExtension code uses Components, and not just for injecting APIs into content. We also use it for web request blocking, monitoring navigations, injecting JS and stylesheets into web pages, etc. I don't know how that would be expected to work in browser.html, but I don't think that WebIDL is going to help much.

Comment 4

[Alexandre Poirot [:ochameau]]

I had this idea while porting the UI APIs. Like browserAction and tabs. There is no need of Components for them (In FirefoxOS or Browser.html). But yes, you are true for most of the toolkit APIs you have to be chrome anyway and use xpcom and all sort of privileged stuff.

I will bring this subject back once I can show you something. It may be easier to see what I have in mind.

Comment 5

[Andy McKay]

Is this still something you are thinking about Alexandre?

Comment 6

[Alexandre Poirot [:ochameau]]

This bug was mostly here to highlight the opportunity to reuse WebIDL mechanism.
But WebExtension APIs went for another interface description language: Schemas.
Surely more powerful, but I'm wondering what is the performance cost of it?
WebIDL seems to be an efficient and secure way of exposing defined APIs.

But I imagine it is too late now and you are commited to use Schemas.