Move back to message-passing (though more directly)

[matatk]

When the DevTools panel was introduced, I thought it'd be good to re-write Landmarks' internal communications with the background script tracking state and supporting things like having the pop-up (if open, on Firefox) and sidebar (Firefox/Opera) being automatically updated when new landmarks are discovered in pages (#201). That's how DevTools needs to work, and this change would make everything consistent. The work to convert to port-based long-lived connections was mainly done in #204 and refined in #216.

However (and maybe I should've considered this more at the time) it is considered best practice on Chrome to use "Event" (non-persistent) background pages (not yet supported on Firefox). At the time, it seemed like the easiest (or only) way to achieve smooth GUI auto-updating would be to use port-based centralised communications. Since then, the draft "Manifest v3" proposals from Google have come out, which make it clear that the event-based direction of travel is continuing.

Having done some research, I've (re-)discovered that the "background context" (i.e. the sphere of bits and bobs that receives runtime.sendMessage() messages) includes the pop-up/sidebar (if open) and background scripts, that they'll each get a copy of each message and all of them have access to privileged APIs, so it seems like it should be possible for the content script and the other components to communicate more directly. This might solve some of the DRY issues in the current message handling—originally I was thinking of just having one message handler, but the DevTools differences appear to make that hard, plus there should be some simplification from moving away from centralised communication.

It seems most communication could be simpler by moving back to message-passing, but this time missing out the background script as middleware. The only thing that might be more complex is supporting updating the pop-up on Firefox whilst it remains open when switching between tabs. It should result in fewer messages being sent by the extension's code, though more messages being received and needing to be discounted at the other end (e.g. when landmark updates are for a non-active tab, though maybe a way around sending them in that case might be found), and if most of the state-tracking isn't really needed, it's best to not have it.

The DevTools would still need to use the port-based communications because of the need to track state in the background script, but I assume in future an API will be created to handle that.

Ideas on how the communications could be done:

• Updating the badge: message from content to background script; background checks it's relating to the active tab.
• Landmarks to pop-up: the same message could also be picked up by
• Updating the pop-up after a mutation: as above :-).
• Updating the pop-up when switching tabs (on Firefox): The content script would have to know when to send the landmarks again, even if they've not changed since last time. However, the background script already monitors for changing between tabs, so that seems to be the place to trigger it.
• Landmarks to sidebar: as above with "updating the badge" above.
• Updating the sidebar after a mutation: ditto :-).
• Updating the sidebar when switching tabs: as with the pop-up above.
• Landmarks to DevTools: needs to be via the background script, as it is now, so DevTools connections can be tracked.
• Updating the DevTools after a mutation: (as it is now.)
• Updating the DevTools when switching tabs: (same again :-).)

References:

• Communicating with a page in the background context
• Messaging from Content Scripts to the DevTools Page
• Obtaining “this” tab ID from content script in Chrome extension?