Remove all Xul Dependencies

[smcgregor]

The day of reckoning has arrived and Mozilla has (finally) deprecated Xul. It looks like we are in good shape with the JetPack extension since we make minimal use of the XPCom and require("chrome"). Still, we need to refactor all these references so the JetPack extension will not get swept up in the Firefox extension apocalypse.

[hitesh96db]

Future of Mozilla Extensions.

Things we need to get rid of --

• Everything in chrome/content/.

Using Chrome URL's and chrome is a no-no now. This means we would have to find a different way to open up the privly-applications pages. I think there are several ways to open up extension pages, chrome:// was just one of them. The unit tests and coverage boilerplate will be the most affected(maybe not? because we don't include them in the packaged extension but Jetpack might just remove the xpcom object from the supported API's and so the tests won't work). We've used XPCOM to the fullest extent to run the tests. So the boilerplate would have to change as well.

• Preferences storage.

We've used preferences via the Components object in privly-applications. Components is part of XPCOM and so this has to go out too. Only when we get privly-applications out of chrome/content/ will we know what are the options/api's for storage.

Yes, we don't use much of chrome and xpcom(apart from testing) and we're in a much better position than privly-firefox, so things still look good for now...(technology changes at such a fast pace that, "for now" is a scary thing to say ;)).

[irdan]

It looks like the new extension API will support localstorage and is aimed at mirroring the chrome.storage api.

This may remove any need to keep the storage shim around!

[hitesh96db]

@smcgregor @irdan

Using chrome and Components is restricted, but I'm not so sure about how they feel about using chrome:// URL's. IMO they shouldn't have a problem with it if we don't use Components. I've tried opening up the privly-applications pages using resource:// , which looks something like this --

resource://privly/privly-applications/Pages/Login.html

But now the ajax calls fail due to a Cross-Origin-Request. But I was thinking if we should go about solving this first rather than removing the usage of Preferences. Preferences would have to be removed anyways regardless of whether we use chrome:// or resource://. Once we remove that, even if we use chrome:// URL's, Mozilla should not have a problem with the extension.

So if we were to remove Preferences, one way would be to use the context messenger to send and receive stored content from the Extension scripts(that could make use of simple-storage).

Do you know what can be done to solve the Cross-Origin-Request issue ? Some changes in the server side can correct this ? I haven't looked much into the network services.

[hitesh96db]

When using resource://, LocalStorage is available, though the extension scripts don't have it, LocalStorage can help in caching the data sent from the extension scripts(that will most likely use simple-storage).

I realized that jsonp can be used to solve CORS, which is also done in some parts of privly-web. The part where I got stuck is authentication, because privly-web doesn't support jsonp for authentication? (I remember very little of RoR).

[smcgregor]

We should be able to solve all the server cross-origin issues within a resource:// URL since we can support CORS on the server as necessary. Another potential problem with a non-chrome URL is whether it is considered privileged for the purposes of x-frame-options and the CSP. Basically, we should only move off of the chrome:// URLs if we know we can't use them. We need to run a few experiments to know whether resource:// will work, but we should figure out if the experiments are even necessary.

[hitesh96db]

We need to run a few experiments to know whether resource:// will work, but we should figure out if the experiments are even necessary.

+1. I think we should go ahead with submitting the add-on for review and then based on the review, try out the experiments if necessary.

[smcgregor]

Sounds good. I don't think the new policies are in effect at this point, so we should be able to ask these questions over the next few reviews.

[irdan]

I spoke with a mozilla dev on irc today - chrome:// urls will not be allowed once the WebExtension API is in place. Experimentation will definitely be needed. They mentioned needing to add the web_accessible_resource to the manifest just like in chrome in order to support the injected use case.

[hitesh96db]

But the question is if we should continue enhancing Jetpack ? Or wait and switch to WebExtensions? :cry: With the WebExtensions API we can have one extension with minor changes for both Firefox and Chrome, which would help in maintainability. But if we plan to keep two separate extensions, then we might as well start making changes in Jetpack. (I think it would take around 5-6 months for the WebExtensions API to be released and another few months to gain stability. In the meantime, we should try to get this extension out to the public).

[smcgregor]

This whole thing is a repeat of history from the introduction of JetPack. This time it is WebExtensions playing the part of JetPack, and JetPack is the new Xul.

JetPack has everything we need and we apparently have a small number of changes to make for the post-Xul world. Further, the only major change we need in JetPack to reach parity with Chrome is to support seamless posting. Since the seamless posting changes are mostly in content scripts, things are unlikely to change if we move to WebExtensions.

I would expect we have 2-4 years before Mozilla deprecates JetPack and we have about a year until we would want to migrate to WebExtensions. I think this constitutes a "want" rather than a "need" because most Privly development will not be inside privly-JetPack when WebExtensions is released. privly-applications is slowly eating the extension-specific code.

Mozilla says they really want input on the WebExtensions API, which we may need to give in the next 6 months if we want to decrease the likelihood of them blocking our use case.

My proposal:

1. Finish JetPack and push out to users with or without seamless posting.
2. Make a test repository that builds a WebExtension for Firefox that only injects a local iframe into a web page.
3. Periodically ensure that local iframe injection is included in Firefox nightly