Because ipfs-chrome-extension and ipfs-chrome-station don't support ipfs>=0.4.5.
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.
Things that make it impossible to load WebExtension under Chromium or connect to IPFS API.
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)browser_action, page_action can be specified in Chromium (we use both) (fixed in chromium-compat branch)- from key names)async / await yet (Firefox does and I plan to use it extensively)chromium-compat branch)version in manifest (fixed in chromium-compat branch)chromium-compat branch)Origin: null with XHR requests for /api/v0/swarm/peers which causes 403 - Forbidden error (fixed in chromium-compat branch)These produce feature regressions, warnings / ugly interface, but do not break main functionality.
protocol_handlers in manifest, this needs to be detected and manual handler needs to be installed.chromium-compat branch)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:
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.
Most helpful comment
Oh hey, look what the cat dragged in:
I made some changes and
chromium-compatbranch 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)