Follow-up from a discussion: https://phabricator.services.mozilla.com/D168543?id=675957#inline-931308

Introduced in the scope of bug 1806413 observer in the script module potentially can be moved to https://searchfox.org/mozilla-central/source/remote/shared/listeners/LoadListener.sys.mjs.

The observer notification as referenced here is actually document-element-inserted. The EventEmitter that we use is basically synchronous but correctly handling the blocking promise might be an issue with multiple consumers of this potential API especially when callbacks require async code.

As best lets have some implementation for pre-load scripts working in BiDi to see if that might cause side-effects.

might be an issue with multiple consumers of this potential API especially when callbacks require async code

For reference, DevTools had a use case where we wanted the emitter to be able to await on all async callbacks, so we added an emitAsync API on our event-emitter: https://searchfox.org/mozilla-central/rev/2d820afafbe62b0148e2766a4d371556edefe36f/devtools/shared/event-emitter.js#244-254,264-266

That might help with the scenario you have in mind here?

To me it's still not quite clear how much other consumers of the event should wait for the blockParsing promise to resolve? blockParsing should only block the script parsing in the page, how could this impact other internal consumers of this event. Note that we also have no control over the rest of the codebase which might be using the observer notification.

Right, we don't know if other consumers need to block the parser or not. As such the observer notification handler should not return until any consumer that actually has to block the parser has finished setting up the blocking promise.