Open Bug 1821460 Opened 2 years ago Updated 2 months ago

Handle actions "Input state" on the top-level browsing context (navigable) and per WebDriver session

Categories

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

task
Points:
3

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.

Summary: Make → Handle actions "Input state" on the top-level browsing context

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.

Severity: -- → S3
Priority: -- → P2
Whiteboard: [webdriver:backlog]
Points: --- → 3

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.

Depends on: 1904665

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.

Depends on: 1915798

(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 map as 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.

Summary: Handle actions "Input state" on the top-level browsing context → Handle actions "Input state" on the top-level browsing context and per WebDriver session

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.

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.

Summary: Handle actions "Input state" on the top-level browsing context and per WebDriver session → Handle actions "Input state" on the top-level browsing context (navigable) and per WebDriver session
Blocks: 1935324
Whiteboard: [webdriver:backlog] → [webdriver:m16]
Whiteboard: [webdriver:m16] → [webdriver:m17]
Priority: P2 → P3
Whiteboard: [webdriver:m17] → [webdriver:m18]
You need to log in before you can comment on or make changes to this bug.