1869095 - Fire the pageActionInUrlbar trigger by dispatching events rather than accessing ASRouter and PageActions from toolkit modules

Status: NEW

(Firefox :: Messaging System, task, P2)

Description

[Shane Hughes [:aminomancer]]

This bug is to fix a mistake I made in my implementation of the pageActionInUrlbar trigger in bug 1857101. Urlbar buttons used to work through the PageActions API, and I wanted that trigger to work for arbitrary urlbar buttons so we wouldn't have to land more code in the future if we wanted to message on a new urlbar button (i.e. the translation button). So, I put a sendPlacedInUrlbarTrigger method in PageActions, but then I realized most urlbar buttons no longer use PageActions. So I had to call sendPlacedInUrlbarTrigger directly from all the individual urlbar button handlers.

That seemed reasonable at the time, since I heard desktop frontend optimistically wanted to use PageActions in the future. However, browser code (like PageActions and ASRouter, modules that are only bundled with Firefox) shouldn't be accessed from toolkit code (which is bundled with Thunderbird, and I guess other mozrunner apps in theory?). And the picture-in-picture button, while only part of Firefox frontend, is actually managed by toolkit code. This isn't a critical issue, since ASRouter and PageActions are only conditionally accessed by PiP. And although PiP code is bundled in TB, the urlbar button code can't be entered in TB due to different pref values. But it's a bit confusing and fragile, and there are other ways to go about it.

I propose to set up a trigger listener in ASRouterTriggerListeners, and then dispatch an event or observer notification from PiP (and PageActions, translation button, and reader mode button, since those also fire the trigger). That way, the button code just blindly sends an event out into the ether, and doesn't care if anyone is actually listening for it. In Firefox, ASRouterTriggerListeners will be present, so will be listening for it. In Thunderbird, it won't be present, so the event will just go unheard. It's more verbose, but it completely avoids this issue of confusing browser/toolkit imports.