Ipfs-companion: Add support for chromium-based browsers

Created on 19 Mar 2017  ·  10Comments  ·  Source: ipfs/ipfs-companion

Because ipfs-chrome-extension and ipfs-chrome-station don't support ipfs>=0.4.5.

kinenhancement kinmaintenance

Most helpful comment

Oh hey, look what the cat dragged in:

2017-05-13-211205_897x506_scrot

I made some changes and chromium-compat branch loads under Chromium without "Hard Errors".

So far I noticed 3 issues that need additional work (see "Soft Errors"), but basic functionality works (redirect, Quick Upload, copying public URL, pinning etc)

All 10 comments

This may require some additional work due to incompatibilities between WebExtensions and Chrome APIs.
It may be easier/faster to just fix one of mentioned Chrome extensions, at least for now.

"Make it work in Chromium" TODO list 🚧 👷

🛑 Hard Errors

Things that make it impossible to load WebExtension under Chromium or connect to IPFS API.

  • [x] Chromium does not have browser object and requires a polyfill for standardized APIs (which is a subset of APIs provided by Firefox): https://github.com/mozilla/webextension-polyfill (there is also https://github.com/MetaMask/extensionizer) (fixed in chromium-compat branch)
  • [x] Only one of browser_action, page_action can be specified in Chromium (we use both) (fixed in chromium-compat branch)
  • [x] Chromium has some additional restrictions regarding locale files which needs to be addressed (fixed by removing - from key names)
  • [x] Chromium does not support async / await yet (Firefox does and I plan to use it extensively)
    In general, chrome target would probably need some kind of transpilling

    (supports since v55)
  • [x] Chromium complains about some i18 placeholders present in local files (fixed in chromium-compat branch)
  • [x] Chromium does not support "alpha/beta" suffix in version in manifest (fixed in chromium-compat branch)
  • [x] Chromium does not accept SVG as browserAction icon, PNG needs to be provided instead (https://stackoverflow.com/q/38457208, https://bugs.chromium.org/p/chromium/issues/detail?id=647182, https://bugs.chromium.org/p/chromium/issues/detail?id=29683) (fixed in chromium-compat branch)
  • [x] Chromium sends Origin: null with XHR requests for /api/v0/swarm/peers which causes 403 - Forbidden error (fixed in chromium-compat branch)

⚠️ Soft Errors

These produce feature regressions, warnings / ugly interface, but do not break main functionality.

  • [ ] Chromium does not support protocol_handlers in manifest, this needs to be detected and manual handler needs to be installed.
  • [x] Chromium does not ship with native CSS classes that are shipped with Firefox (fixed in chromium-compat branch)
  • [x] Chromium does not accept Alarm periods less than minimum of 1 minutes (fixed in #266)
    > On Chrome, unless the add-on is loaded unpackaged, alarms it creates are not allowed to fire more than once per minute. If an add-on tries to set delayInMinutes to a value < 1, or when to a value < 1 minute in the future, then the alarm will fire after 1 minute. If an add-on tries to set periodInMinutes to a value < 1, then the alarm will fire every minute. – alarms.create()
  • [x] Right-click "Upload to IPFS" does not work due to Origin mismatch

I just fixed ipfs-chrome-station, but it might take a while for xicombd/ipfs-chrome-station#15 to get merged, and the extension updated.
For now, you can use https://github.com/mateon1/ipfs-chrome-station/tree/fix/ipfs-0.4.5
To do so, clone the repo and switch to branch fix/ipfs-0.4.5. Run npm install and npm run build. You can then load the ./build folder in Chrome as an unpacked extension.

Following up https://github.com/ipfs/in-web-browsers/issues/54#issuecomment-300234021, we want to have this WebExtension serving both.

Is Only one of browser_action, page_action can be specified in chrome (we use both) the only thing missing?

I remember there were multiple errors about unsupported manifest keys, eg. recently introduced protocol_handlers. I've added them to first post. There is probably more.

This "write once, run everywhere" story provided by Mozilla does not pass reality check.
As soon as we use non-canonical API provided by Firefox, we are not Chrome-compatible.
And as you can see there are discrepancies even within APIs copied from Chrome.

I suspect we will end up with chunks of conditional code and dedicated manifest and build pipeline for each browser.

That being said, we can simplify stuff by merging "pageAction" back into "browserActions".
One thing less to worry about.

FYI I'll do my best in diagnosing / mitigating compatibility issues in chromium-compat branch this week.
Stay tuned. 👌

I came across extensionizer[0] from the same peeps that are developing MetaMask, maybe
incorporating it and help develop it further would be a good idea

I am afraid extensionizer is not enough, as it is still callback-based.

Firefox introduced promise-based syntax and that functionality for Chrome is provided by webextension-polyfill, which is safe to be enabled all the time.

Update:

I've added the polyfill and it should be possible to build via npm run build and load it into Chromium based browser.

Browser button does not work yet, but that's a start.
Each error can be now fixed while using Chromium developer tools.

I also updated the list of known issues.

Oh hey, look what the cat dragged in:

2017-05-13-211205_897x506_scrot

I made some changes and chromium-compat branch loads under Chromium without "Hard Errors".

So far I noticed 3 issues that need additional work (see "Soft Errors"), but basic functionality works (redirect, Quick Upload, copying public URL, pinning etc)

@lidel Is this published to the Chrome Web Store now?

Not yet, but thanks for asking! I created #268 to track that.

Was this page helpful?
0 / 5 - 0 ratings