Handle actions "Input state" on the top-level browsing context (navigable) and per WebDriver session
Categories
(Remote Protocol :: WebDriver BiDi, task, P3)
Tracking
(Not tracked)
People
(Reporter: whimboo, Unassigned)
References
(Blocks 5 open bugs, )
Details
(Whiteboard: [webdriver:m18])
Bug 1792090 will implement the basics for perform actions with the limitation that the input states are stored on the actual browsing context and not the top-level browsing context as it should be per WebDriver classic spec.
We should be able to use the WebDriverProcessData actor to store the state equally to the nodeCache but per top-level browsing context.
The question still is if it would be fine for the child actor or if we have to store the data in the parent actor.
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 1•2 years ago
|
||
As discussed today it might not happen that often that users will interact with elements in both the top-level browsing context and in child browsing contexts. That means the risk of mixing input state is low, but we will add this bug as optional for M7.
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 2•1 year ago
|
||
It would be good when working on this bug that we also implement the browsing context input state map as defined in the WebDriver classic specification at: https://w3c.github.io/webdriver/#dfn-browsing-context-input-state-map
With the work on bug 1904665 I'm moving the input states from the content to the chrome process first, which will help to actually get this bug fixed.
| Reporter | ||
Comment 3•1 year ago
|
||
Over on bug 1915798 I'm adding queuing of actions. When we implement this bug we should also add some more wdspec tests that exercise the parallel execution of actions when each action lives in a different browsing context.
| Reporter | ||
Comment 4•1 year ago
|
||
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #2)
It would be good when working on this bug that we also implement the
browsing context input state mapas defined in the WebDriver classic specification at: https://w3c.github.io/webdriver/#dfn-browsing-context-input-state-map
As the specification describes the browsing context input state map is actually a property on the WebDriver session and as such handles states of input devices per session, and should share it as well with Marionette. For the latter case we should write some interop tests.
| Reporter | ||
Comment 5•1 year ago
|
||
It's currently unclear if a cross-browser navigation should clear the input state map or not. I've filed https://github.com/w3c/webdriver/issues/1859 to get this discussed.
| Reporter | ||
Comment 6•1 year ago
|
||
As discussed in a W3C meeting the input state needs to survive a browsing context replacement. It means that it is bound to the top-level navigable. It means we have to maintain a separate map for it most likely with the browser element as key for the WeakMap.
| Reporter | ||
Updated•8 months ago
|
| Reporter | ||
Updated•8 months ago
|
Updated•5 months ago
|
Updated•2 months ago
|
Description
•