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•2 years ago
|
Comment 1•2 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•2 years ago
|
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Comment 2•1 year 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.
Comment 3•6 months ago
|
||
There is a BrowsingContext.getCurrentTopByBrowserId()
helper available which actually let us find the current top-level browsing context based on the browser id. If we really have to use the browser element then we could get it via .embedderElement
.
Comment 4•6 months ago
|
||
I'm not sure yet but with the work on bug 1274251 we might not necessarily need this anymore. Lets mark as dependency for now.
Comment 5•6 months ago
|
||
Let me actually fix that issue separately via this bug. I'll have a patch that is using the above method later today.
Comment 6•6 months ago
|
||
I was totally wrong here. The source id here is actually not the browserId
but the unique navigable id. As such the proposed solution will not work.
Description
•