Improve performance of getBrowserById with a map of UUID to browser element
Categories
(Remote Protocol :: Agent, defect, P2)
Tracking
(Not tracked)
People
(Reporter: jdescottes, Unassigned, Mentored)
References
(Blocks 1 open bug)
Details
(Keywords: perf, Whiteboard: [webdriver:backlog][lang=js] )
In Bug 1747222 we are introducing a getBrowserById method on remote/shared/TabManager.js which loops on all windows & tabs to see if any browser element matches the provided id.
Instead we could maintain a map from UUID to browser elements, but we therefore need to cleanup this map whenever a browser element is removed.
We will most likely have to keep track of all existing browser elements, similar to what is done in TargetObserver https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/remote/cdp/observers/TargetObserver.sys.mjs, and everytime a browser element is removed, cleanup the appropriate entry in the map. Note that our UUIDs are bound to the permanentKey of <browser> elements. We will have to make sure there are no scenarios where the same permanent key might be reused for several browser elements, or we'll need to take this into account in our cleanup logic.
Reporter | ||
Updated•3 years ago
|
Comment 1•3 years ago
|
||
We might have to fix bug 1691494 first to get parity between CDP and WebDriver even when we have to accept a performance regression.
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 2•2 years ago
|
||
This can be a mentored bug, but not setting as good-first-bug as this will require to understand a bit how the browser handles browsing contexts. Hopefully we can rely on the current implementation in https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/remote/cdp/observers/TargetObserver.sys.mjs as a starting point.
Description
•