(In reply to Geoff Lankow (:darktrojan) from comment #11)
This looks good, on the whole.
The big question now, as I see it, is do we want to keep the
chrome.manifest file? If we do, we'll need to steal this part of ext-legacy.js to register it, but it does save us from a lot of work. It would mean we could keep using
chrome:// URLs everywhere rather than changing every one of them to be a
moz-extension:// URL. It would also do component registration for us, meaning all of the calendar components should carry on as they have been.
We should only be using moz-extension:// on the WebExtension side of things. Everything else is likely better a resource:// uri, which should be fairly easy to register/unregister even without a chrome.manifest (nsIResProtocolHandler)
On the other hand, it's something we don't really want extensions to do in future. It ties us to a bunch of things from the past that may not be around much longer, and they're not the sort of things we want to fix in a rush if they are removed. Perhaps we should keep the file for now, but work towards getting rid of it.
+1 on working towards getting rid of it
...and it would make switching L10n to Fluent possible. I don't know what the L10n story is for Firefox system add-ons, but I think it's something along the lines of "don't".
My understanding is that we can register l10n directories for fluent for Lighting just as well, using
L10nRegistry. I'm not sure l10n is really the blocker here.
We've been going back and forth on system add-on vs integrated a lot, to me it feels hard to commit to a specific decision. Each have their advantages, and no downside is great enough that it would make the decision obvious.