What does HackerNews think of webextension-polyfill?

A lightweight polyfill library for Promise-based WebExtension APIs in Chrome

Language: JavaScript

This is pretty cool, bundle it with webextension-polyfill [0] and you can release it as a decent NPM package.

[0] https://github.com/mozilla/webextension-polyfill

There's standardization work being done at the moment with the W3C WebExtensions Community Group [1] which is definitely a step in the right direction!

Mozilla has also done some great work building a web extension polyfill library that attempts to abstract away the differences between the browsers [2] but the translation will always be imperfect, and edge cases are abundant.

[1]: https://www.w3.org/community/webextensions/

[2]: https://github.com/mozilla/webextension-polyfill

I've written extensions before and Firefox has a very good polyfill [0] that makes it quite easy to write extensions for all browsers. It does get a bit trickier if you also want to incorporate TypeScript [1] or React however.

[0] https://github.com/mozilla/webextension-polyfill

[1] https://github.com/Lusito/webextension-polyfill-ts

I used WebExtension polyfill[0] when adapting my FF addon to Chrome and admittedly all the intricate differences between APIs still costed me half a day of work.

I managed to have it done with only a few places where I branch on navigator.vendor, but If I wanted to ship different versions to AMO and CWS, I'd make use of something like DefinePlugin[1] for webpack to include/exclude code based on build target.

[0] https://github.com/mozilla/webextension-polyfill/

[1] https://github.com/webpack/docs/wiki/list-of-plugins#definep...

I mean, the browser apis are close (and Mozilla still has much better documentation) but there are a LOT of edges cases where behavior diverges.

Frankly - I'm a little peeved that Optional permissions in Firefox are STILL broken - The prompt can only be triggered in response to a user action, and Firefox blows the fuck up if you put a promise anywhere in between the user click and the call to the api. Which is hugely ironic, since Mozilla is the one pushing to move all the webext APIs to be promise based (and provides a nice helpful library for Chrome/Edge/Safari support: https://github.com/mozilla/webextension-polyfill) which... doesn't work on their platform. Doubly ironic, since the result is that most FF extensions just ask for more permissions up front, which is exactly the opposite of what you'd want in the "secure/private" world Mozilla claims they're pushing towards.

I'm going through converting a Chrome extension to Safari 14, and the process isn't nearly as seamless as shown, although it's nice to have the converter tool.

Chrome extensions only support the 'chrome' namespace, while Firefox supports 'chrome' and 'browser', but Safari 14 only supports 'browser'. So our extension had been using the 'chrome' namespace which worked under Firefox, but now needed to be converted. 'chrome' uses callback functions, while 'browser' uses Promises. So you have to port your Chrome extension to use 'browser' and use the following polyfill: https://github.com/mozilla/webextension-polyfill

Here's some incompatibilities between Chrome and Firefox to consider: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Also had some html/css glitches to fix in Safari. Some other issues others have mentioned such as notifications and webRequest APIs.

Browser vs chrome point is moot. Both namespaces exists in Firefox and there’s a polyfill to bring the browser namespace into chrome if you want to use promises over function callbacks. https://github.com/mozilla/webextension-polyfill
Thanks! It was a bit more work than I expected to be honest. I wish I had started originally using Mozilla's polyfill: https://github.com/mozilla/webextension-polyfill
Is there a good short answer for why uBlock is using constructs like this:

if ( self.browser instanceof Object ) { self.chrome = self.browser; } else { self.browser = self.chrome; }

Instead of using a polyfill like that one https://github.com/mozilla/webextension-polyfill?

The main difference between Chrome and Firefox extensions is that Chrome uses a callback-based API while Firefox's is based on promises. Other than that they're functionally the same aside from some differences in the manifest and the namespace (Chrome uses `chrome` while Firefox uses `browser`). I think Firefox has some backwards compatibility with the callback interface for easier porting but I haven't tried.

There's a nice polyfill by Mozilla so you can use their promise interface in Chrome but it was missing some important apis last I checked (sessions and optional permissions). https://github.com/mozilla/webextension-polyfill

For my extension Saka Key (https://github.com/lusakasa/saka-key), I decided to use the browser.* APIs on both Chrome and Firefox using Mozilla's web extensions polyfill.

https://github.com/mozilla/webextension-polyfill

The biggest challenge for me was addressing browser incompatibilities and Firefox bugs. This is a big one:

https://bugzilla.mozilla.org/show_bug.cgi?id=1193394

Another is that Firefox doesn't fire blur events when DOM elements are removed or hidden.

The Firefox approval process is slow. Mine took 3 months the first time, < 10 days the second time, and this third time it's taking over a month.

Chrome's reviewal process is really nice. It usually takes <30 minutes.

There is a polyfill written by mozilla devs that port the browser namespace and promise based api calls over to chrome if needed.

https://github.com/mozilla/webextension-polyfill