Adapt ModuleCache::getAllModuleClasses to be compatible with workers
Categories
(Remote Protocol :: WebDriver BiDi, task, P3)
Tracking
(firefox142 fixed)
Tracking | Status | |
---|---|---|
firefox142 | --- | fixed |
People
(Reporter: jdescottes, Assigned: jdescottes)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webdriver:m16])
Attachments
(1 file)
In https://bugzilla.mozilla.org/show_bug.cgi?id=1726800 we are adding APIs in ModuleCache in order to discover all modules relevant for a given command from the parent process. This mostly relies on getAllModuleClasses, which returns the Array of classes which implement a given module to reach a certain destination.
For now, we only have 3 MessageHandler types:
- root
- windowglobal-in-root
- windowglobal
Assuming simple layouts such as this, you can build the paths to the module classes by simply combining: the current type, the destination type and the module name.
But this is no longer true for more complex folder layouts, when we introduce workers. To give an example, a command for a "foo" module with a "worker" destination might have module implementations in the following paths:
- worker-in-root/foo.jsm
- worker-in-windowglobal/foo.jsm (or worker-in-contentprocess/foo.jsm, depending on how we implement this)
- worker/foo.jsm
So from the Root MessageHandler, you can't guess the second item just based on the "root" type, the "worker" destination type and the "foo" module name. You also need to know the "layout" of the architecture, and that there is an intermediary layer between root and worker.
We can either describe the layout as a tree and rely on it to implement getAllModuleClasses. Or we can just hardcode it, assuming we should not really support that many layers in the long run.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•2 years ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Assignee | ||
Updated•10 months ago
|
Updated•9 months ago
|
Assignee | ||
Comment 1•7 months ago
|
||
Might not be necessary.
Assignee | ||
Updated•7 months ago
|
Updated•5 months ago
|
Assignee | ||
Comment 2•2 months ago
|
||
To be clear, this is only mandatory if we need more than one level of nesting for our message handler layers. The assumption was that, same as DevTools, we would need an intermediary process layer before reaching workers, but this is probably no longer necessary thanks to Bug 1899503. But I've had the patch for this ready for a while now, and I think it's still a better design than the current workaround in ModuleCache, so let's move forward with this.
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 3•2 months ago
|
||
Comment 5•1 month ago
|
||
bugherder |
Description
•