Move to WebExtensions

[lidel]

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 (Multiprocess Firefox (e10s) #18, Test and Adapting to Multiple Processes #26)
• confirm WebExtension add-ons can be uploaded to and signed on addons.mozilla.org (AMO)
• create webextensions branch
• create addon boilerplate (moved to WX: add-on boilerplate (locale, settings persistence) #144)
• update JPM(web-ext?) to a version capable of building WebExtension addon
• find a way to write and run test suite (moved to Recreate Test Suite #145)
• switch development to master branch, delete webextensions one, move legacy code to legacy-sdk
• [MVP done] Rewrite add-on as WebExtension
  • All activities are tracked in a dedicated project:
    https://github.com/lidel/ipfs-firefox-addon/projects/1
  • There is also Milestone view for v2.0.0 with remaining Issues:
    https://github.com/lidel/ipfs-firefox-addon/milestone/3
• 🚧 [in progress - awaiting review] 🚧 release WebExtension to stable channel at http://addons.mozilla.org/

References:

• https://wiki.mozilla.org/Electrolysis#Enabling_and_Disabling_Electrolysis
• https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003063.html
• https://blog.mozilla.org/addons/2016/03/14/webextensons-whats-in-it-for-developers/
• https://developer.mozilla.org/en-US/Add-ons/WebExtensions
  • Comparison with the Add-on SDK
  • Comparison with XUL/XPCOM extensions
• https://wiki.mozilla.org/Add-ons/developer/communication
• https://compatibility-lookup.services.mozilla.com/
• http://arewewebextensionsyet.com/
• https://blog.mozilla.org/addons/2016/07/21/new-webextensions-guides-and-how-tos-on-mdn/
• https://blog.mozilla.org/addons/2016/07/27/linting-and-automatically-reloading-webextensions/
• https://blog.mozilla.org/addons/2016/08/25/webextensions-in-firefox-50/
• https://wiki.mozilla.org/WebExtensions/Experiments
• https://trello.com/b/PC9kB14s/webextensions-roadmap
• https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/
• https://github.com/mdn/webextensions-examples

[lidel]

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 🐫

[ShadowRZ]

Don't forget to make it supports Mobile Firefox!

[lidel]

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

[lidel]

@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]

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

[lidel]

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]

@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.

[lidel]

v2.0.0alpha3

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

[lidel]

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]

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]

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]

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]

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]

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]

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]

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

[lidel]

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]

Hopefully. 于 2017年7月15日 GMT+08:00上午5:04:36, Marcin Rataj <notifications@github.com> 写到:

…

I am following [Bug 1185785](https://bugzilla.mozilla.org/show_bug.cgi?id=1185785) (and its dependencies) and it is a mixed bag right now, for example [BrowserAction API is not yet implemented on Android](https://bugzilla.mozilla.org/show_bug.cgi?id=1330159). But it will work, at some point in future :) -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #20 (comment)

-- 使用 K-9 Mail 发送自我的Android设备。

[lidel]

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]

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]

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.

[lidel]

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:

[lidel]

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.

[whyrusleeping]

Woo! Great work @lidel :)