Please report any other irregularities here.
Periodically we have to do some kind of asynchronous operation, like an IPC bounce to the parent, under the auspices of a particular window or worker global. In these cases we often need to: 1. Hold the worker global alive since "bad things" happen if the thread goes away while we expect a dispatch back. 2. Get notified that the global wants to go away. While (1) is specific to workers, (2) is common to both. On workers we have the WorkerHolder API for detecting shutdown. On main thread code has to register an nsIObserver for DOM_WINDOW_DESTROYED_TOPIC and then filter out the right window. I think we should consider a common API that workers and windows nsIGlobalObject code can implement. It would do a WorkerHolder on workers and do a more direct notification on windows without the overhead of the observer service. In general i think we should try to hunt down places where we have "if workers this, else do this window stuff" and replace with common APIs.
> In general i think we should try to hunt down places where we have "if workers this, else > do this window stuff" and replace with common APIs. Yes, please!
Quantum DOM "fibers" may have similar problems to Worker threads in terms of lifecycle. Perhaps there is room to develop a common set of restrictions and API. For example, if fibers could fail Dispatch() to their event targets like Worker threads must, then we would end up with a more consistent behavior between windows+workers.
Note, we now consistently get DOMEventTargetHelper::DisconnectFromOwner() called on both window and worker globals. This slightly improves the "know when the global shuts down" situation, but doesn't address the other parts of WorkerHolder. Also, not everything is a DETH object.
You need to log in before you can comment on or make changes to this bug.