Port to WebExtensions

[Shugabuga]

This should port BPM to WebExtensions. This doesn't change anything with the current Firefox addons, but provides additional support for WebExtensions (when built, it is named appropriately).

The file you want to submit to Mozilla is build/firefox_webextension.xpi. The build/firefox_webextension folder is the corresponding addon folder.

Everything in the below tests work in both Chrome Canary, Firefox Nightly, and Safari:

Tested:

• Emote browser
  • Emote Insertion
  • Help Menus
  • Resizing/Moving
  • Escape-To-Close
  • Prevent Dragging Off Screen
• Animotes
• Collapse Emotes
• Effects
• ExtraCSS effects
• Preferences
• RES Support
  • Live Preview
  • Night Mode
  • Show In Front-Page Preview
• Everything From This Thread works
• [](/spoiler)
• Text Effects ([Hello](/red!-center) works as intended)

(This should also resolve #47, and also resolve #15 because I updated the syntax needed for the manifest)

EDIT: Realized #15 was still closed

[Rothera]

Not that my target filenames are in any way sensible most of the time, but can we rename this to something less authoritative sounding like webext.zip? Or is there some particular utility to this name?

[Rothera]

Since we are unifying Chrome and WebExt, would like to rename these to we- or similar. Ideally also s/Chrome/WebExt/ where appropriate (possibly also in random "browser type" constant strings). Though exactly which bit of text to use in which places may not always be perfectly clear.

[Rothera]

Similar complaint: long name, just call it build/webext.

[Rothera]

Should be writing out firefox.zip (or webext.zip if we rename). Or else change the Makefile rule target to match.

[Rothera]

I don't know that I'd call it "fixing" #15 per se, since I still can find no evidence that they changed the required property in the Jetpack manifest.

My guess is they just don't give a damn and the documentation is wrong, but whatever.

[Rothera]

Unrelated, since you've now done far more research than I have, did Mozilla just completely can developer signatures or are they simply not implemented?

[Shugabuga]

I honestly have no clue. ;-;

[Shugabuga]

Just a heads up that Firefox sent out their about:addons newsletter about the mandatory WebExtensions push, especially that it’s a few days away. Either this or #49 needs to be merged and submitted as soon as possible if we want to limit downtime. I hate to have to be this urgent and pushy (and I apologize ahead of time if this comes off as rude), but we are running low on time, and the last thing I want is for BPM users to notice that it’s broken.

Hell, don’t even ship newer emotes with the new update if that helps to get the support out faster.

[bb010g]

@Shugabuga I concur. (Also, this needs a rebase if it's going to be merged.)

To try and help you figure out which PR you want to merge, I did some research off of #49 (comment):

[Packaging an XPI] is also probably required if I want to pretend I support the various forks, though I could not say who is left of those users either.

The major FX forks I know of are Pale Moon, SeaMonkey, and Waterfox. Out of those browsers, only Waterfox supports WebExtensions at the moment. SeaMonkey has a plan to introduce them (they're currently based on the 52 FX ESR which runs WebExt BPM just fine) soon due to concerns about keeping up to date with upstream with a small team, and Pale Moon just doesn't want to include them because they think they'll never be powerful enough to be as useful as XPI. (This seems beside the point to me because every major extension developer will be working on WebExtensions and the new Firefox releases, like how the developer of Tree Style Tabs worked with Mozilla (example Bugzilla issue) to figure out how to keep it functioning while not restricting what Firefox can refactor internally. They're going to be left with a couple of people who maintain Pale Moon exclusive extensions, fall further and further behind, and not be able to take advantage of WebExtensions that people, organizations, and companies are writing like they have with XPIs in the past.)

So, you can either continue to maintain what really should be 2 XPIs for the users who are running SeaMonkey (until they transition) and Pale Moon (because they've completely forked from upstream and can introduce unique & fresh compatibility problems when they refactor), and hope all 5 of them file issue reports whenever they find a bug, along with actually maintaining your WebExtension, or you can cut over now and reduce your complexity by a ton.

[Rothera]

This ended up being the PR I mostly referred to while working out webext support, though I think it wasn't quite enough. Seems to run in the two versions I care about, though.

I will refrain from further comment. You place far too much trust in a hypocritical, treacherous corporation.