Closed Bug 1733242 Opened 4 years ago Closed 1 month ago

Adapt ModuleCache::getAllModuleClasses to be compatible with workers

Categories

(Remote Protocol :: WebDriver BiDi, task, P3)

task
Points:
2

Tracking

(firefox142 fixed)

RESOLVED FIXED
142 Branch
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.

Blocks: 1713438
Priority: -- → P3
Whiteboard: [webdriver:triage]
Blocks: 1873250
No longer blocks: 1713438
Points: --- → 3
Whiteboard: [webdriver:m13]
Whiteboard: [webdriver:m13] → [webdriver:m14]
Whiteboard: [webdriver:m14] → [webdriver:m15]

Might not be necessary.

Points: 3 → 2
Priority: P2 → P3
Whiteboard: [webdriver:m15] → [webdriver:backlog]
Whiteboard: [webdriver:backlog] → [webdriver:m15]
Whiteboard: [webdriver:m15] → [webdriver:m16]

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: nobody → jdescottes
Status: NEW → ASSIGNED
Pushed by jdescottes@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/edd7f3b6033a https://hg.mozilla.org/integration/autoland/rev/6c673975befc [remote] Update MessageHandler ModuleCache to handle nested layers r=webdriver-reviewers,whimboo
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 142 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: