feat: Firefox Support

[WayneKeenan]

Before submitting an issue, please check the following

• I have searched for similar issues (both open and closed) and cannot find a duplicate
• I agree to follow the Code of Conduct

Motivation

Current Firefox support needs looking at, see Issue #12

Solution

Revisit PR #6

ClintonCAT version

n/a

Platform

Desktop

Anything else?

No response

[RC-14]

Hi, great to see you wanting to support Firefox and making this extension in general!

A few notes because I've previously converted a private Manifest v3 Extension from Chrome to Firefox (some things have changed/improved since then so I looked everything up on MDN and Chrome Extension Docs):

This one is just in case you didn't know: You can use webextension-polyfill for compatibility between Firefox and Chrome. (types are here: @types/webextension-polyfill)
Alternatively (as you probably know) chrome also exists on Firefox (explicitly for Chrome Extension support) and I don't think this extension needs any APIs that aren't available on Firefox. (MDN Page regarding Chrome incompatibilities)

Regarding Issue #12: Firefox doesn't support background service workers so different manifests are required. background.scripts or a background page with a script tag is what should be used on Firefox. (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/background)

Last one: If you don't want to do anything on the webpage and just need the hostname I'd highly encourage you to use the tabs API and get rid of the content script.

If you'd like help with getting the extension running on Firefox I'd be happy to help. (though I have to admit that I haven't really worked with a team before and don't know react and webpack)

Greetings

P.S.: The part below was also supposed to be in this comment but you removed "type": "module" from the content script before I finished writing. (I'll leave it here just in case)

This one is kind of an extension to the previous one: I think a separate Firefox code base is neither necessary nor a good idea and that would require not using "type": "module" for content scripts. (it's not even listed on the MDN Page)
Loading content scripts as modules can be done on Firefox by generating dummy scripts that then load the real one with import(), but that's async and quite the ugly hack. Additionally the async nature of import() means that run_at isn't reliable anymore and I'd recommend using "document_start" and listening to the readystatechange event.