On minified source code, Extensions/Add-Ons are allowed to be deployed with minified source code as long as you provide the unminified versions to Google/Mozilla during review time.
On chrome vs. browser namespaces, a quick 'let chrome = browser;' can help you keep the diffs small between versions. I have yet to find a complete solution to fixing 'forked code' between Google/Mozilla Extensions/Add-Ons.
Also, storage mechanisms between browsers using the same extension code can be completely different. Beware if you're using caches, navigator.storage, and storage.local.
Finally, extensions don't consider themselves secure, depending on the browser. moz-extension:// is not considered secure for cache access, whereas chrome-extension:// is.
There lots of little 'gotchas' like these when developing browser extensions. :)
I'm curious how they could know that the source code is the same
I have been publishing extensions for a while and never found Google asking me for the source code, is there any hidden option to submit it?
Another detail I have missed is release notes, Firefox is supposed to provide those but I have never been able to add them, Chrome doesn't seem to display them but I have got my submission rejected just after "improving" the description.
> On chrome vs. browser namespaces, a quick 'let chrome = browser;' can help you keep the diffs small between versions. I have yet to find a complete solution to fixing 'forked code' between Google/Mozilla Extensions/Add-Ons.
Firefox actually supports the chrome namespace but you need to be careful as some other APIs are different, for example, in Chrome the notifications has a richer set of options but you need to be careful to not use the ones not supported by Firefox.
I definitely wish I would have known that.
1. Source code. You are allowed to minify source code. Chrome actually recommends minifying source to improve performance. If you require certain permissions you'll have to submit un-minified source for security review.
2. Cloud/subscription based models are the way to go if piracy is an issue, but it doesn't make sense for all products. Licensing hasn't been an issue for Sapling fortunately because the "brains" of our app are in the cloud. I know hacker news is very privacy conscious but our language models are too large to run on a user's end machine right now. Spier Pro seems like a useful web-scraping helper. People who can pirate a chrome extension probably can probably run xpath scripts or a free xpath testing extension themselves so if I were Amy I wouldn't worry _too_ much about piracy.
3. Forked Code. There should be no reason to do it. Firefox and Edge have done a lot of work to support most of the chrome apis. You can handle minor edge cases build time with a variable toggle. Keep the same manifest, even. Browsers are good about ignoring keywords in the manifest they don't recognize. My recommendation is to pretend they are the same platform until you find bugs/issues and hard code around them. Theres a handful but it's very manageable.
I've been so busy I haven't bothered to go try and "fix" the extensions. These are OSS extensions, nothing paid, so I all the code is available for the reviewer to read by the way.
The actual problem is that some APIs are different, for example, in Chrome the notifications has a richer set of options but you need to be careful to not use the ones not supported by Firefox.
> Keep the same manifest
Actually, it depends on which options you use, for example, i18n placeholders aren't supported in Firefox while they are in Chrome, in Edge, the manifest is drastically different.
Maintaining hundreds of lines of duplicate code can become a logistical mess. Most extensions will see 95-100% shared code between platforms.
EDIT: just wanted to add that you don't need to distribute your extension through Gumroad (though you can). You just make it so that anything behind a paywall requires adding the license key which is generated by Gumroad upon purchase and later verified via their licenses API.
This is what I did. I also had to create a licensing backend to handle cases such as only being able to use your license key on a single account, and for verifying that your license key was still valid (in case you cancelled or got a refund).
> However, I'd not recommend it for selling browser extensions because of: 1. It doesn't make sense to download extensions and manually install them. (The first version of Spider Pro worked that way, and lots of customers find it confusing). 2. There's no easy way to distribute post-installation updates.
What's wrong with putting your extension on e.g. the Chrome and/or Firefox web store where purchasing via your own site gives a login that unlocks paid features within your extension? That gets around 1 and 2, plus you gain organic traffic from being in the stores.
This is what I do for https://www.checkbot.io/, which is on the Chrome Web Store but I use Paddle for payments. This also means purchases aren't tied to the Chrome Web Store.
I went with Paddle over Gumroad as Gumroad seemed less flexible for team based subscriptions. Is anyone doing something like the above with Gumroad? How did it work out?
Also, I haven't used Chrome Web Store payments but I would steer well clear of integrating it. They've been disabling payment functional for various reasons the last few months as if it's not business critical to people: see https://www.theregister.co.uk/2020/01/27/google_disables_web... and more recently https://groups.google.com/a/chromium.org/forum/#!topic/chrom.... I wouldn't be surprised if they cancelled Chrome store payments soon.
- In the extension, get the user to log-in via your server, which includes checking the subscription is still valid e.g. log-in can be via email which you can link to the email used to buy the subscription.
- When the subscription expiration date changes, Paddle will send another web hook to your server to update the subscription data.
More integration info here: https://paddle.com/docs/reference-using-webhooks/
Hope that helps!