Firefox only wakes up event pages for listeners that were added at the top-level AND never removed after that. Any listeners registered after startup do not trigger event page wakeup, even if it is a sequence of removeListener(topLevelListener) + addListener(topLevelListener) calls.

Because of this, it is not possible to conditionally register listeners.
In contrast, in Chrome (120), the event page / service worker will wake up when an unregistered top-level listener is registered again.
(The wakeup even happens for listeners that are registered asynchronously (not at the top level). In that case the first event causes the event page to wake up (but not dispatch the listener). Any other events trigger the listener.)

I recommend a middle way: a listener should have the ability to participate as a trigger for event wakeup, if:

• the listener was registered at the top level
• the listener was not removed (with removeListener), OR
• if the listener was removed, it was added again with addListener.

Waking up in response to registering a non-top level listener is out of scope for this issue.

STR:

1. Load the extension at about:debugging
2. Visit example.com
3. Click on the extension button.
4. Confirm that the page has been modified by the extension ("Hello" text is added)
5. Wait 30 seconds for the event page to suspend (or click the "Terminate background script" button at about:debugging)
6. Repeat step 3: Click on the extension button.
7. Repeat step 4: Confirm that the page has been modified

Expected:

• The event page should have been awakened.
• The example.com page should have been modified.

Actual:

• The event page is still suspended.
• The example.com page has not been changed.

To test the behavior in Chrome: edit manifest.json, change _service_worker to service_worker, and scripts to _scripts, then load the extension at chrome://extensions/.

Note: there is a more detailed write-up for the use case of conditional listeners at https://github.com/w3c/webextensions/issues/501
That feature request in that WECG issue is not related to the bug reported here, but "The current approach is a hacky process" code example does not work in Firefox due to what I described in this bug.

The severity field is not set for this bug.
:willdurand, could you have a look please?

For more information, please visit BugBot documentation.

While discussing https://github.com/w3c/webextensions/issues/501 , there was consensus that the event page/SW should wake up if the listener was registered again. That means that we have to resolve this bug, by at least supporting the ability to wake up the listener when registered again. Not a must-have for this issue, but we could also consider registering a listener registered asynchronously, like Chrome. I'll try to get clarification on the desired behavior in the WECG before the implementation here.

There are no great work-arounds available... In one of my extensions, I worked around this issue by:

1. Register an alarms.onAlarm event listener unconditionally.
2. Waiting for the event page to suspend (runtime.onSuspend) and then create an alarm to wake up the event page.
3. Upon waking up the event page, the listener is registered (and not removed), resulting in the listener being persisted as desired.

(relevant diff is at https://github.com/Rob--W/crxviewer/commit/c2cd81055cadd111ace4adafcd5b924be82f1f20)

Depends on D211461

https://hg.mozilla.org/mozilla-central/rev/41807e1c5b9c
https://hg.mozilla.org/mozilla-central/rev/069aad7b428c