Add the Element Origin concept

[jgraham]

This is really designed for BiDi, allowing actions to specify the origin relative to an element in the form:

{ type: "element" sharedId: }

rather than sending in a WebDriver-style element reference. For simplicit this allows the new construct to work irrespective of whether actions are being used in a HTTP session or a BiDi session (but a BiDi session is not expected to support the HTTP-style web element reference identifiers).

---

Preview | Diff

[jgraham]

I think @shs96c wanted to look at this.

Note: this doesn't impose any additional requirements on loca end authors. For WebDriver-Classic you can still send exactly the same actions that you always sent. It does impose new requirements on remote end authors: you have to support either Classic element syntax or BiDi element syntax when deserializing an actions chain with an element used as an origin.

The more general problem of serialization being different between BiDi and Classic is, I think, unavoidable given the different requriements. A local end will need to [de]serialise data differently depending on the specific protocol it's talking because BiDi has a general, extensible, representation of remote JS values, whereas Classic has support for JSON-serializable types plus some special cases around elements.

So my impression is that this adds the minimum additional complexity. We could change things so that Classic doesn't also support the BiDi syntax. That's a bit of a pain because you need to check where the data originated deep in the deserialization part of the spec. But it's not impossible, if we really want the minimum user-facing change.

[jgraham]

@foolip @sadym-chromium could one of you review this please?

[sadym-chromium]

So the suggested way is attractive, but I guess we should not extend the Classic protocol with BiDi format. To avoid that, we can pass a deserialization algorithm, or more hacky string elementIdField={'element-6066-11e4-a52e-4f735466cecf' | 'sharedId' }.

[foolip]

Passing in an algorithm to deserialize seems fine to me. @jgraham WDYT?

[jgraham]

Sure, if we don't want to just allow the new format in classic then passing in the deserialization steps is a pretty clean approach.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Element Origin (for BiDI actions).

The full IRC log of that discussion

<jgraham> Topic: Element Origin (for BiDI actions)
<jgraham> GitHub: https://github.com/w3c/webdriver/pull/1653
<sadym> I'll take a look at it
<jgraham> jgraham: New PR for deserializing element origins in classic is up. This allows passing steps in, so that classic can have exactly the same behaviour, but BiDi can use the BiDi serialization. This is blockingn landing actions / input support in BiDi.

[sadym-chromium]

Sure, if we don't want to just allow the new format in classic then passing in the deserialization steps is a pretty clean approach.

is element origin and get element origin solves it. LGTM

[whimboo]

@jgraham mind updating this PR so that we can get it merged? Or not sure what else is blocking here.