ipfs/ipfs-companion

Move to WebExtensions

lidel opened this issue · 29 comments

lidel commented

Why?

We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers. [..]

Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback. Add-ons that are built using the new WebExtension API will continue to work. We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.

Source: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

ipfs-companion Migration Status

  • make sure current version runs fine in multiprocess firefox (#18, #26)
  • confirm WebExtension add-ons can be uploaded to and signed on addons.mozilla.org (AMO)
  • create webextensions branch
  • create addon boilerplate (moved to #144)
  • update JPM(web-ext?) to a version capable of building WebExtension addon
  • find a way to write and run test suite (moved to #145)
  • switch development to master branch, delete webextensions one, move legacy code to legacy-sdk
  • [MVP done] Rewrite add-on as WebExtension
  • 🚧 [in progress - awaiting review] 🚧 release WebExtension to stable channel at http://addons.mozilla.org/

References:

lidel commented

I started migration in webextensions branch. Progress can be traced in dedicated Project.

Due to limited time I can't promise any solid deadline, but I will port it, eventually 🐫

  • 👍1
ShadowRZ commented

Don't forget to make it supports Mobile Firefox!

lidel commented

There is a dedicated issue for that at #109 (comment) :)

whyrusleeping commented

@lidel Wheres the best place to see the latest state of the webextensions work? I've been playing around with making a webextension start up its own ipfs node and redirect ipfs.io requests to it here: https://github.com/whyrusleeping/ipfs-webext

lidel commented

@whyrusleeping List of already implemented/missing WE APIs: http://arewewebextensionsyet.com (generated from Firefox sources)
Mozilla's roadmap: https://trello.com/b/PC9kB14s/webextensions-roadmap

It would be awesome if we had PoC that ships js-ipfs with addon, fingers crossed. 👍

cvan commented

hey there, I've been eager to see this done. glad to see this being worked on! unrelated to IPFS, I've been playing around a lot lately with Web Extensions (and even specifically the Native Messaging API). let me know if you have any questions; if I don't have an answer, I could direct you to my Mozilla colleagues (and file bugs, talk to folks, etc.) as needed.

  • ❤️1
cvan commented

also, in addition to AWWEY, these are my two favourite resources (though I'm sure you've likely seen them already):

  • 👍1
victorb commented

It would be awesome if we had PoC that ships js-ipfs with addon, fingers crossed. 👍

I am currently working on such a PoC! See this: https://github.com/VictorBjelkholm/js-ipfs-in-the-browser

Currently having issues passing streams from cat from the background-script > content-script > web page, probably related with xrays...

  • 👍1
lidel commented

@victorbjelkholm that sounds fantastic! I hope the issue is solvable: would be very exciting if we could deliver js-ipfs with v2.0.0 of this add-on (created ticket for that in #183).

whyrusleeping commented

@cvan I had one question, how are native messaging extensions meant to be packaged and installed?

lidel commented

If anyone is interested in testing WebExtension version of this add-on, I made it available on AMO's Development Channel. It is an opt-in: every development release needs to be installed manually.

I'll be posting following Alpha, Beta and RC updates in this thread, so feel free to subscribe if your are interested in living on the bleeding edge 🙃

Current plan is to refine UX, add test suite until Firefox 54 is released with basic protocol handler and Sidebar API). Basic functionality should work fine with Firefox >= 51.0

v2.0.0alpha2

Release Notes: https://github.com/lidel/ipfs-firefox-addon/releases/tag/v2.0.0alpha2
Installation: https://addons.mozilla.org/en-US/firefox/addon/ipfs-gateway-redirect/versions/2.0.0alpha2

cvan commented

@whyrusleeping: So, I talked to the AMO team: they recommended creating an .msi for the installation process and shipping that to users through your own channel. It's not ideal, but I think once more people are making Native Messaging WebExtensions, folks will be able to better inform developers + users on best practices here.

  • 👍1
lidel commented

Status update from dev-addons@mozilla.org:

There's been questions in bugs and other places about the expectations
of what will be implemented between now and Firefox 57. There's
currently over 750 bugs on WebExtension, so following bugs can be a
rather tiring experience.

I've tried to summarise the plan here:

https://wiki.mozilla.org/WebExtensions/RoadMapFirefox57

We've also got a public trello board here:

https://trello.com/b/PC9kB14s/webextensions-roadmap

lidel commented

v2.0.0alpha5

Release Notes: https://github.com/lidel/ipfs-firefox-addon/releases/tag/v2.0.0alpha5
Firefox Installation: https://addons.mozilla.org/en-US/firefox/addon/ipfs-gateway-redirect/versions/2.0.0alpha5

Note: this version comes with experimental support for running in Chromium-based browsers
(see "Manuall Chromium Installation" in Release Notes for more details)

jefft0 commented

I'm using v2.0.0alpha5 in Firefox 54.0b10. The following HTML with an embedded image works in extension version v1.6, but it doesn't work on v2.0. Is WebExtensions able to load embedded links?

<html><body>
Image: <img src="web+fs:/ipfs/QmX7mna7G3BLx2UCdAHviaDastbnvLiVmM2pQ5azBa1H7D">
</body></html>
lidel commented

I am afraid this is no longer supported in WebExtension world.
web+fs is no longer a real protocol, it is just a simple redirect.
See #164, especially #164 (comment)

jefft0 commented

The link says "the address in the location bar changes". What happens when someone is viewing an IPFS page and bookmarks the link? Does it bookmark the idiosyncratic, temporary link with the gateway address, or does it bookmark the long-living, useful, location-independent IPFS link with just the hash? If it bookmarks the idiosyncratic, temporary link with the gateway address, then it is not sustainable for the long term.

lidel commented

v2.0.0alpha5 will bookmark URL from address-bar (as-is), so it will be either a public or custom HTTP gateway URL.

I agree there should be some kind of "normalization" that makes bookmark gateway-agnostic,.
I've created #254 to track that use case. Feel free to discuss it there.

lidel commented

According to this roadmap Firefox 57 will be released on November 14th.
This milestone release will only run WebExtensions which means v1.x versions (legacy-sdk branch) of this addon will stop working.

AMO community noticed the deadline and rushed to rewrite legacy addons to WebExtension.
I've been reading various horror stories about unlucky developers having addon update in review queue for weeks.

ipfs-companion WebExtension was released to Development Channel only, so most of our Firefox users are still using the legacy version (~400 active daily users).

I think it is a good play to start the process now. Polish what we have, make an official 2.x release sooner than later and submit it to AMO review. We may not get accepted right away due to use of eval and other security constraints, but even a rejection will be a step forward. It will highlight areas we should focus on.

My strong opinion is that we won't see any change in state of protocol support (#164) before Firefox 57. This means there will be functional regression (no fs://, only web+fs:// and even that will be just a simple redirect), but i feel we can't do anything about it.

Let's timebox this decision: if there is no negative feedback till 22nd of June I'll submit latest v2.x.x to the "stable channel" at AMO.

jefft0 commented

+1 for switching to v2.x.x sooner than later. Will this work in Firefox for Android?

lidel commented

I am following Bug 1185785 (and its dependencies) and it is a mixed bag right now, for example BrowserAction API is not yet implemented on Android. See my summary in #109 (comment)
But it will work, at some point in future :)

ShadowRZ commented
lidel commented

In preparation for v2.0.8 release I created PR with README updates: #267
Let's wait for feedback until 26th. Then I'll merge it and make a release which will be submitted to Mozilla for full review.

lidel commented

I've just submitted v2.0.8 to AMO for official review.
There is a long queue, so it may take 5-10+ days until we get any feedback.

lidel commented

Wow, that was fast :-)
We got some valuable feedback:

Your add-on, IPFS Companion 2.0.8, has been reviewed and did not meet the criteria for being hosted in our gallery.

Comments:
This version did not pass the review because of the following issues:

  1. The use of 'unsafe-eval' is not allowed in the manifest.json's CSP as it can cause major security issues.

Please fix them and submit again. Thank you.

I created #269 for addressing the usafe-eval thing.

  • 👍1
lidel commented

Status update:

According to this wiki Firefox 57 release is planned for 2017-11-14.

It will no longer support legacy version. AMO review takes up to a week or two, so we have time to submit working version til the end of October. I quietly hope they will move release date due to developer pressure, but I would not bet on that.

Review is blocked by #269, which is still open. To mitigate the problem I've updated description at AMO, as it would be the first place user looks at:

2017-09-02-155306_663x41_scrot

lidel commented

I've just published v2.0.13 to AMO.
We've already had a reviewed legacy version, so new release got automatically approved. 🎉 ✨
Users should get a nice update in the following days.

It is still pending manual review, but I hope my explanations on how #269 got addressed are enough.
I feel it is a right moment to close this.

  • 🎉1
whyrusleeping commented

Woo! Great work @lidel :)