You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I pass setWindowRect as an alwaysMatch capability, what should behaviour be?
Currently, under "For each name and value corresponding to capability’s own properties:", this falls through out of the "Otherwise" clause because:
"If name is the name of an additional WebDriver capability" doesn't apply because an additional WebDriver capability is one defined in another spec, and setWindowRect is defined in this spec
"Otherwise, if name is the key of an extension capability" also obviously doesn't apply
This effectively means that we end up not doing any matching and we also don't fail as a result, and the returned value may well be different to the alwaysMatch value.
From a protocol point-of-view, it is exceptionally surprising that we end up with the returned value being different to the alwaysMatch value.
(Note I'm not super interested in setWindowRect specifically here—and indeed this is arguably a bug—but we do want to allow for other output-only capabilities, and we should define in general what should happen when they are passed in as a capability.)
The text was updated successfully, but these errors were encountered:
Split from discussion on w3c/webdriver-bidi#446 (c.f. #1790 (comment)).
Not everything in https://w3c.github.io/webdriver/#capabilities has defined matching behaviour under https://w3c.github.io/webdriver/#dfn-matching-capabilities.
If I pass
setWindowRect
as analwaysMatch
capability, what should behaviour be?Currently, under "For each name and value corresponding to capability’s own properties:", this falls through out of the "Otherwise" clause because:
"If name is the name of an additional WebDriver capability" doesn't apply because an additional WebDriver capability is one defined in another spec, and setWindowRect is defined in this spec
"Otherwise, if name is the key of an extension capability" also obviously doesn't apply
This effectively means that we end up not doing any matching and we also don't fail as a result, and the returned value may well be different to the
alwaysMatch
value.From a protocol point-of-view, it is exceptionally surprising that we end up with the returned value being different to the
alwaysMatch
value.(Note I'm not super interested in
setWindowRect
specifically here—and indeed this is arguably a bug—but we do want to allow for other output-only capabilities, and we should define in general what should happen when they are passed in as a capability.)The text was updated successfully, but these errors were encountered: