[HN Gopher] Ask HN: Browser-extension creators, how do you write...
___________________________________________________________________
Ask HN: Browser-extension creators, how do you write for multiple
browsers?
How do you avoid repeating code for, say, both a Firefox and Chrome
extension? Chrome recently mandated that only manifest V3
extensions can be submit to their online store, and that introduces
quite the number of breaking changes from V2 (even with the
polyfill package). As far as I can tell, Firefox does not yet
support V3 (I could be quite mistaken there). As someone new to
writing extensions and trying to write something for at least both
Firefox and Chrome, how should I go about it? Or do I have to
accept writing separate background.js files, separate manifest.json
files, etc.?
Author : falafelite
Score : 75 points
Date : 2022-02-12 16:40 UTC (6 hours ago)
| onassar wrote:
| I ended up writing a build script that makes the required changes
| for chrome/ff extension.
|
| This will become harder when mv3 gets pushed out broadly, but
| it's def not pretty :(
| L1quid wrote:
| For our browser extension, The Camelizer, I wrote Spader:
| https://github.com/cosmic-shovel/spader
|
| It lets me use Ruby in my html/css/js files, and also sass in the
| css, letting us use one codebase for all target browsers.
|
| Definitely a work in progress, and lacks the exciting auto-reload
| functionality of other similar projects, but it works for us.
| Issuing one build command and having an extension for all our
| target browsers is pretty nice.
| bunya017 wrote:
| If you're familiar with Vue js, you should consider using
| Quasar[0]. It'll handle the compatability across browsers while
| you work on the extension.
|
| [0] https://quasar.dev/quasar-cli/developing-browser-
| extensions/...
| freedomben wrote:
| Is there anything like Quasar that supports React? (Question
| directed at the hive, not you specifically)
| falafelite wrote:
| Ah interesting! I've written mine in Svelte (as far as the
| popup part goes) but this is a good resource if anyone sees
| this thread and uses Vue, thanks for sharing
| klntsky wrote:
| 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...
| falafelite wrote:
| Yeah that's the polyfill extension I use! Thanks for the
| validation, I am finding that I have to make manual changes
| anyway as well. Thanks for sharing the DefinePlugin, it looks
| like it could be quite useful
| gnicholas wrote:
| My company's main products are browser extensions. At first, our
| Chrome extension was the most popular, but I anticipate with the
| upcoming changes we may say goodbye to Chrome and just be on
| Firefox and Safari, depending on how they deal with V3 issue. We
| simply don't make enough money from our Chrome extension to deal
| with all of their big changes. Last year they ditched the
| Webstore Payments, last summer they migrated Google Docs (one of
| our most popular use cases) from DOM to canvas-based rendering,
| and now this. We can't keep rewriting major parts of our codebase
| at the whim of big G.
| MaknMoreGtnLess wrote:
| > My company's main products are browser extensions
|
| How well does the "WebExtensions API cross-browser technology"
| [0] work to build ONE code base and have to work well across
| Google Chrome, Firefox or even Safari?
|
| [0] https://developer.mozilla.org/en-US/docs/Mozilla/Add-
| ons/Web...
| gnicholas wrote:
| It has worked well for the last several years when we could
| easily deploy changes to Chrome and Firefox. I have no idea
| what we're going to do with the upcoming manifest schism.
|
| Safari is just mobile for us, though if Chrome goes through
| with V3 we may offer safari for desktop also.
| MaknMoreGtnLess wrote:
| > I have no idea what we're going to do with the upcoming
| manifest schism
|
| OK - is this issue then that the upcoming Chrome manifest
| changes break Chrome's compatibility with the standard or
| these were features that were never part of the standard to
| begin with and very specific to Chrome?
| gnicholas wrote:
| From talking with my dev, my understanding is this has to
| do with scripts and service workers. I believe these were
| not specific to Chrome previously, but I'm not sure.
| gnicholas wrote:
| Does anyone know how Brave will handle manifest V3?
| Glench wrote:
| I made ExtensionPay[1] (a service to help you take payments in
| extensions) and I used Mozilla's `browser` shim in the extension
| library itself. MV3 is not available on Firefox yet so I support
| both MV2 and MV3, but yeah it's a pain in the butt to have one
| MV2 version and one MV3 version.
|
| [1] https://extensionpay.com
| azeirah wrote:
| Unless something changed in the past 3 weeks, you can still
| upload manifest V2 plugins to chrome, I uploaded one a few weeks
| ago.
|
| Otherwise, what I did to support v2 for firefox and v3 for chrome
| is fairly straightforward.
|
| You write your code and compile it all with webpack into a single
| file, all you have to do is write two manifest files which are
| 70% the same.
|
| There are some incompatibilities between v2 and v3, like v3
| having promises for the extension api. I wrote wrappers for the
| non-promise versions myself (I'm sure there are packages that do
| this for you). Webpack takes care of a lot of the other
| inconsistencies like module support.
|
| Also note that you should 100% make sure that you follow the
| guidelines for how to structure a plugin for the v3 version, ie
| that it is event based. Your background scripts will be shut down
| randomly every now and then and you will get insanely buggy code
| when running in v3 if you don't follow the guidelines strictly.
|
| For now, I just ship v2 to both firefox and chrome, it's easiest
| for me. Note though I have had this plugin for a couple years
| now, maybe it's not possible to create _new_ plugins with v2.
| falafelite wrote:
| Yeah there has been a recent change: "As of January 17, 2022
| Chrome Web Store has stopped accepting new Manifest V2
| extensions. We strongly recommend that new extensions target
| Manifest V3."[0]
|
| I guess I made the mistake of developing for Firefox first with
| their documentation/guides. I am using rollup and the polyfill
| plugin per some suggestions, but it certainly isn't generating
| anything compatible for v3, and I believe it breaks on the
| background script vs. worker thing.
|
| [0] https://developer.chrome.com/docs/extensions/mv2/
| insin wrote:
| Urgh, not accepting new V2 extensions is terrible, I didn't
| realise they'd done that.
|
| Up until now I've just been publishing the exact same
| extension for Firefox/Chrome/Edge (and also as a user
| script), as Firefox supports using the global `chrome` object
| for everything I've needed it for. The only browser-specific
| stuff has been targeting different browsers with CSS in the
| options page to make it blend in with the default light and
| dark mode themes in Firefox/Chrome/Edge.
|
| Looks like I'm in the same boat the next time I need a new
| extension.
| isodev wrote:
| I usually keep a common source folder for all browsers. This
| includes a common manifest (V2, still experimenting with V3). At
| build time a script generates a browser specific flavour of the
| manifest and copies all resources into a target folder (e.g
| /dist-chrome, /dist-safari, /dist-firefox) to create a bundle per
| browser and apply browser specific tweaks (like copying resources
| into an Xcode project for Safari etc).
| dewey wrote:
| How do you develop it (having the extension enabled in the
| browser) with this strategy? Are you just continuously re-
| building on changes and the browser picks it up?
| falafelite wrote:
| Interesting! I've got something like that (doesn't work
| properly for Chrome yet) going; if it is open source on git
| somewhere, I'd love to see it. If not, no worries!
| nextlevelwizard wrote:
| I just don't support Chrome.
| kiru_io wrote:
| Since this thread is full of Browser-extension creator. I have a
| related question: How do you make money with Browser-Extension
| (without selling data)?
| gnicholas wrote:
| We charge a subscription fee of a couple dollars per month.
| We've been approached by data brokers and the like, but that's
| not our style.
|
| We once did a lifetime subscription event in conjunction with
| StackSocial. It was worth it, but not amazingly so.
| porkbrain wrote:
| I worked with extensions for roughly 4 years on a handful of
| separate projects. I had managed a framework which abstracted
| over all APIs (including the insane old Safari one).
|
| While I can't share the framework, I have designed a code base
| architecture which allows incremental abstraction of APIs, uses
| typed message passing between scripts (with errors being
| propagated too), unit and integration tests or automation for
| compilation of the extension for each store according to their
| respective rules. This architecture is my IP and although I don't
| actively work with extensions on day to day basis anymore, I
| still do take on contracts to lay foundations or migrate existing
| projects.
|
| If this is something you're interested in, reach out to me via
| email in my bio.
| bambax wrote:
| I could be very wrong about this, and yes, it's also mostly
| wishful thinking, but my guess is Chrome will have to walk back
| V3 at some point. The reasoning is that V3 makes uBlock Origin
| impossible, and Chrome without uBlock (or any browser really) is
| unusable.
|
| So maybe you can just wait? Although it may take a long time.
|
| Also, FF said in May of last year (2021) that they would start
| accepting V3 extensions in "early 2022" [0] but I don't know if
| they have kept their schedule.
|
| [0]
| https://blog.mozilla.org/addons/2021/05/27/manifest-v3-updat...
| freedomben wrote:
| I hope you're right. You're certainly right in my case: I will
| switch completely to FF when that happens. I was an early
| adopter of Chrome and while I do use FF quite a bit as my
| "work" profile, breaking extensions that make the web usable
| will cause me to leave and never look back (unless you are rate
| and the walk back v3)
| pvity wrote:
| > Chrome without uBlock (or any browser really) is unusable.
|
| I use a recent version of Safari and uBlock origin doesn't work
| there. I rely on Ka-Block![1], which blocks popular ad serving
| domains. For other annoyances like newsletter popups, etc., I
| use a "Kill sticky headers" script[2], with some hacks; I'll
| try to post my version of that script sometime soon.
|
| It works good enough for my needs. I also have Firefox with
| uBlock installed, but with that earlier setup I end up still
| using Safari.
|
| [1]: https://github.com/dgraham/Ka-Block
|
| [2]: https://alisdair.mcdiarmid.org/kill-sticky-headers/
| gnicholas wrote:
| I've wondered this as well, especially since the primary effect
| of the change appears to be undermining adblockers.
|
| I could see Congress looking into a change like this, and
| hopefully an inquiry would be enough to get them to hold off.
| falafelite wrote:
| Ah okay thanks for sharing the Mozilla update. And I suppose I
| am less optimistic than you, since they have so much browser
| market share I'd guess they're happy to let devs figure out how
| to make our stuff work if we want access to their users. It's
| also notable that so far v3 is only mandated for new
| extensions, though I'm not sure if that applies to updates of
| existing extensions.
| jaredsohn wrote:
| It applies to updates of existing extensions in January 2023.
| https://developer.chrome.com/blog/mv2-transition/
| catlifeonmars wrote:
| > Chrome without uBlock (or any browser really) is unusable.
|
| Source? If this is anecdotal, it seems unlikely that it's
| representative.
| OptionX wrote:
| It's axiomatic based on its self-evident nature.
| [deleted]
| zerr wrote:
| Also interesting, how do you monetize? (Besides acquiring a lot
| of users and selling out)
| Bilal_io wrote:
| > Chrome recently mandated that only manifest V3 extensions can
| be submit to their online store
|
| Can someone provide a source for this please?
|
| My company has an extension with the old manifest V1 and I'd like
| to propose upgrading or getting rid of the extension all
| together.
| Bilal_io wrote:
| Update: here is the source
| https://developer.chrome.com/blog/mv2-transition/
| Animats wrote:
| I gave up and deleted my plug-in for Chrome.
| dewey wrote:
| I just wrote my first extensions for a new side project
| (https://getbirdfeeder.com) a few weeks ago. Initially I thought
| that now after a few years everything will be mostly standardized
| with "web extensions" and I just upload the extension to the
| three big extension stores. Turns out it's nothing like that and
| I wrote a little bit about my misconceptions in my blog [1]. It's
| still not a great development workflow. If there's any good
| strategies I'll gladly give that a try.
|
| My initial plan to have a private package that I just import in
| my extensions but turns out you can't really do that as imports
| don't work. Right now I'm kinda stuck in copy pasting code back
| and fort hand keeping a V2 Extension for Firefox (and Safari) and
| a V3 Extension for Chrome. I also keep separate manifest files as
| they have different features.
|
| [1] https://blog.notmyhostna.me/posts/building-web-extensions-
| fo...
___________________________________________________________________
(page generated 2022-02-12 23:01 UTC)