feat: Inform user when Chrome autoupdates

[marcustyphoon]

Description

Resolves #2276:

I can't 100% verify that this is true—I guess I should go back to Chrome for a while for coverage, one of us probably should—but it's very possible and perhaps likely that when Chrome autoupdates an extension, while it doesn't invalidate the entire javascript context for the extension content script like Firefox does, it does make all browser.x namespaced functions throw "extension context invalidated", as can be simulated by disabling the extension. This, of course, breaks some of the extension.

In #1486 we slightly improved the error handler for this, but a) we apparently don't have error handling on everything that could throw, and b) honestly I think it would be a lot better to not wait for the user to do something to show an error message. Particularly if they have multiple Tumblr tabs open, it makes the most sense to me to show an informative modal on all tabs when an automatic update occurs, which (as mentioned in that PR) we could do via polling.

This shows a modal message if XKit Rewritten stops being able to access browser.x functions, which will occur in Chromium-based browsers if the user disables XKit or (possibly, unconfirmed) if there's an automatic update. Basically #1486 on steroids.

If we had a background script, we could try to make this happen only on update, not on disable, but for cross-platform-old-browser compatibility reasons we currently don't, and thus don't have access to the APIs that would let us differentiate.

Screenshots

Testing steps

• In a Chromium-based browser (npm start -- -t=chromium), enable XKit Rewritten, open a (logged-in) Tumblr tab, then disable the extension. Confirm that the referenced info modal appears after a short period. You may note that:
  • Enabling the extension again does nothing (unlike in Firefox).
  • If you decline to refresh immediately, you can get the Warn about unloaded/updated extension errors in Chromium #1486 messages by clicking various extension UI elements.
• Open any XKit modal, then disable the extension. Confirm that the the referenced info modal appears only after you dismiss the other modal.
• In a Firefox, enable XKit Rewritten, open a (logged-in) Tumblr tab, then disable the extension. Confirm that nothing occurs.

[AprilSylph]

Works as described.

I think this isn't the ideal user experience, but it is better than nothing.

(I'm pretty sure the UX I want would require a browser version bump, though, which will make it a hard sell for you!)

[AprilSylph]

Actually, there is a version of what I'm thinking of that doesn't require any manifest changes: with some expansion in capabilities of the notifications util, what if we called clean() on everything and added a non-fading notification?

Can't quite decide if clicking the toast would open this modal, or just refresh instantly, or what, but you get the idea. Something that would actually respect an intentional disabling of the whole extension without being too interruptive.

[marcustyphoon]

What's the UX you want? Background script that reinjects the content script?

Anyway, yeah, probably improvable. My first priority is "starting from the next release, users stop posting about our extension being broken when it's not actually broken;" beyond that I'm flexible. (Yes, kicking old-OS users off the update cycle does qualify for "users post about our extension being broken when it's not actually broken.")