Bug: Messages with skip_in_tests shouldn't evaluate targeting or set up trigger listeners
Status: ASSIGNED
Priority: P1
Created: 2025-02-14 22:55:43+00:00
Resolved: 2025-03-03 18:05:14+00:00

We found a test failure in bug 1919598 despite the message having `skip_in_tests: true`. The culprit was the `activeNotifications` targeting attribute. It calls `gBrowser.getNotificationBox()`, which [creates a notification box](https://searchfox.org/mozilla-central/rev/08b7628708d8fc8a425ebd1f26bfce7ace1bbbaa/browser/components/tabbrowser/content/tabbrowser.js#906-918) if it does not already exist. That breaks tests that expect there to be no notification box until they create one. Of course, our targeting attributes should not have side effects, so Negin is going to fix that.

But we also shouldn't have evaluated targeting for this message in the first place, since it can't show. Right now, we let skipped messages go through the whole procedure, creating a trigger listener and evaluating it like any other message, only to fizzle it [right before rendering](https://searchfox.org/mozilla-central/rev/08b7628708d8fc8a425ebd1f26bfce7ace1bbbaa/browser/components/asrouter/modules/ASRouter.sys.mjs#1388-1401).

That is actually kind of a problem, because only 1 message can reach the end of this code path. It's potentially taking up the slot of other messages that maybe _could_ show. If we checked `skip_in_tests` in the targeting step, we'd exclude the message from the set of eligible messages, so another message would get the chance to show. But because we only check it in `routeCFRMessage`, it's possible for it to reach the top of the list, above other messages without `skip_in_tests`. In that case, it will try to show our skipped message and fizzle out, resulting in no message being shown. Because only the 1st message in the list can ever show.

So anything that can stop a message from being shown should really be handled in `handleMessageRequest`. Unfortunately, FeatureCallout also relies on anchor logic that can prevent a message from being shown, and that logic really can't be moved to `handleMessageRequest`. But for now we can make some improvement by moving `skip_in_tests` into `handleMessageRequest`.

In addition to that, we should not create trigger listeners for messages with `skip_in_tests`, since it's a waste of computational resources. If it's the only message with that trigger, then we end up creating a trigger listener we otherwise wouldn't, that will fire and do nothing, wasting some nonzero amount of time in every test. We can put a `skip_in_tests` check [over here](https://searchfox.org/mozilla-central/rev/08b7628708d8fc8a425ebd1f26bfce7ace1bbbaa/browser/components/asrouter/modules/ASRouter.sys.mjs#951) to achieve that. And since we'll be checking `skip_in_tests` in multiple places, we might as well create a helper function for it:

```js
shouldSkipForAutomation(message) {
  message.skip_in_tests &&
    // `this.messagesEnabledInAutomation` should be stubbed in tests
    !this.messagesEnabledInAutomation?.includes(message.id) &&
    (Cu.isInAutomation ||
      Services.env.exists("XPCSHELL_TEST_PROFILE_DIR") ||
      Services.env.get("MOZ_AUTOMATION"));
}
```