Closed Bug 1869125 Opened 8 months ago Closed 2 months ago

Top-level listener cannot be registered persistently again after calling removeListener


(WebExtensions :: General, defect, P2)



(firefox128 fixed)

128 Branch
Tracking Status
firefox128 --- fixed


(Reporter: robwu, Assigned: rpl)


(Blocks 2 open bugs)


(Whiteboard: [wecg][addons-jira])


(3 files, 1 obsolete file)

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.


  1. Load the extension at about:debugging
  2. Visit
  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


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


  • The event page is still suspended.
  • The 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
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.

Whiteboard: [wecg]

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

For more information, please visit BugBot documentation.

Flags: needinfo?(wdurand)

While discussing , 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

Severity: -- → S3
Flags: needinfo?(wdurand)
Priority: -- → P2
Whiteboard: [wecg] → [wecg][addons-jira]
Assignee: nobody → lgreco
Attachment #9401520 - Attachment is obsolete: true
Blocks: 1899767
Pushed by
Fix intermittent longer running time in test_ext_persistent_events.js test_eventpage_startup test task. r=robwu
Do not clear event pages persistent listeners unregistered asynchronously after the event page is fully started. r=robwu
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 128 Branch
You need to log in before you can comment on or make changes to this bug.