Replace startup workaround with persistent listener

[stoically]

The workaround introduced in #78 due to the report in #61 to catch loading Facebook tabs on Firefox startup could potentially be replaced by "persistent listeners" introduced in Bug 1447551.

For a listener to become persistent, it must be added during evaluation/initial execution of the background script. If it happens later (asynchronously or otherwise) then it is not persisted.

• Add documentation for persistent startup listeners in webextensions. mdn/sprints#1015

This would require to move the webRequest listeners to the global context and make sure to wait inside the listener for the required init work. A short example is here.

[Rob--W]

Someone reported this bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1748999.

It looks like it should be straightforward to resolve this bug, by moving the setupWebRequestListeners call to the start of init at

contain-facebook/src/background.js

Lines 659 to 676 in 058054e

	(async function init () {
	await setupMACAddonListeners();
	macAddonEnabled = await isMACAddonEnabled();
	relayAddonEnabled = await isRelayAddonEnabled();
	try {
	await setupContainer();
	} catch (error) {
	// TODO: Needs backup strategy
	// See https://github.com/mozilla/contain-facebook/issues/23
	// Sometimes this add-on is installed but doesn't get a facebookCookieStoreId ?
	// eslint-disable-next-line no-console
	console.error(error);
	return;
	}
	clearFacebookCookies();
	generateFacebookHostREs();
	setupWebRequestListeners();

.

[Myron-S]

Yep. Looks like this has been reported quite some time ago. I'm on 97.0b2 (64-bit) and this issue is present. I caught this because Facebook is logged in within its container, but not anywhere else so I get presented with the standard Facebook login page instead of the page referred to from the desktop shortcut.

Workaround is for me to start Firefox first and then invoke the shortcut on the desktop.