Meeting minutes
<jgraham_> RRSAgent: make minutes
<jgraham_> RRSAgent: make logs public
Naming conventions for WebDriver / extension specs
Diverging driver behavior for "clear the modifier key state" in "Dispatch actions for a string"
<jgraham_> github: w3c/
Naming conventions for WebDriver / extension specs
github: w3c/
jfernandez: I will be very brief. The issue is there are conflicts when enumerating driver extension commands
… I guess that it has never happened
but now we have a conflict between secure payment and custom handlers
… so I would like to get an agreement for enumerations
… I don't think there is a strong agreement which way like : or - or so on
jgraham_ (IRC): I think this is purely about the naming conventions. I have been looking through the specs and we are not consistent
… in bidi we use all lower case
… error codes have spaces
… worker types are - separated
… action types are camel cased
… where for property names in the json protocol we consistently use camel case
… we never use snake case. My opinion is that we standardise on space separated like error codes as they are nicely human readable
jfernandez: for context, when <person> at Google did this suggested we do camel case
… I am not sure the rational
jgraham_ (IRC): the only problem with camel case is that it is a outlier for the work we already have
… but there is not clear consensus
jfernandez: the SPC editors are happy to changes here
jgraham_ (IRC): since there are no opinions that people comment on the issue
jgraham_: I don't mind, but the error codes seem like the most fundamental part of the protocol
mathiasbynens: We could follow the design guidelines for WebIDL enums
gsnedders: We could have a straw poll in the GH issue?
<mathiasbynens> jfernandez: can you point me (offline) to the ChromeDriver CL/discussion where camelcase was suggested? thanks
jgraham: Yes, let's resolve to have a strawpoll on the GH issue.
Diverging driver behavior for "clear the modifier key state" in "Dispatch actions for a string"
GitHub: w3c/
whimboo: This is WebDriver classic. We had a bug report / regression on this behaviour. It affects Send Keys; there's a difference between setting an unsetting modifiers. In the spec only sending NULL as a key unsets the modifier. But in Firefox/Chrome sending the same modifier again unsets the modifier. This isn't supported in SafariDriver. This is an interop problem. Can we standardise on the
Chrome/Firefox behaviour? That allows unsetting a specific modifier at a time.
<mathiasbynens> yes
acl patrickangle_
patrickangle_: This feels like a bug on our end; it seems reasonable this should work.
whimboo: I suspect this behaviour predates the spec.
patrickangle_: The handling of NULL is in the spec?
whimboo: Yes, NULL is in the spec, but resending the modifier key to unset it isn't in the spec. There's a workaround (see issue)
jgraham: I suggest we propose the spec change here and if there are concerns we can discuss again.
"Unsupported Operation" for Get Element(s) from Shadow root 'using' xpath and tagname
GitHub: w3c/
whimboo: Firefox now supports finding elements from a shadow root. We have different locator stratgies. Currently it doesn't work to use xpath or tagname from a shadow root. Should we have a specific error? Currently we emit unknown error
jgraham: Because the spec doesn't consider the possibility of the locator strategy not working?
whimboo: Yes
<jfernandez> mathiasbynens (IRC): done
jgraham: This is because the APIs the spec assumes exist aren't on shadowroot
gsnedders: They also don't exist on document fragement.
<JimEvans> In the ideal world, all locator strategies would work in all find cases. We are not in an ideal world. It’s a cause of confusion that they don’t work.
<JimEvans> A specific error would be better than not.
<JimEvans> Or more appropriate than “unknown error”
gsnedders: TagName seems like it should work. That doesn't have much complexity so it's not surprising. XPath is harder, and DOM people might have opinions on whether that's reasonable.
jgraham: I propose that we redefine the tag name locator strategy to not depend on getElement(s)ByTagName so it can work on shadow roots. I also propose that in general we allow the find elements commands to fail if the strategy isn't supported for some reason
whimboo: We have "invalid selector", can we use that?
jgraham: I assume that's more for invalid css selectors. The obvious one would be "invalid argument" but that's very non-specific
Support emulation of device metrics (width, height, deviceScaleFactor, ...)
github: w3c/
orkon: A good starting point would be the ability to change the viewport and the device pixel ratio.
orkon: Width/height and dpr for a given context, which should apply to all sub contexts.
jgraham: Use case is mobile-ish testing on desktop?
orkon: It's mostly about responsive design at this stage, but we could extend it to mobile in the future. It's important for screenshots and testing that elements are in the right places.
patrickangle_: I get the pixel ratio emulation. I'm having difficulty understanding why the width/height is needed instead of resizing the window.
orkon: For mobile emulation you probably need more e.g. portrait/landscape and device scale(?), so it's partially related to mobile enulation, but it's a subset
patrickangle_: We want it to be very well specified what happens when you set the viewport. Different people have different expectations. In Safari RDM, we don't adjust the screen size because ideally that's not what people are using to test against, even for mobile devices that might not be the actual device screen size.
orkon: This isn't directly about the window size. In Chrome currently you can set the viewport size. Affects window.innerWidth and innerHeight.
orkon: From what I understand it's like a screen size for the content area, but I"m not sure of the details.
whimboo: Difference between resizing the window and the viewport is that you can set it just for a single tab in the window.
orkon: It doesn't count the browser UI so it's clearer
jgraham: Are you thinking it would apply just to top level tabs and descendents or all contexts?
<JimEvans> I abdicate my place. I misunderstood the full context.
orkon: It should apply to frames. If the main tab has multiple frametrees, maybe they should all use the same dimensions.
jgraham: So basically a per-tab setting?
orkon: Pretty much.
whimboo: Should it be possible to set this globally so that it inherits into new tabs, or should you have to call it explicitly for each tab?
orkon: I think we might want both options. You can't currently intercept creation of a new context, so maybe the context could be optional. But a specific context seems like it would work for most use cases. So maybe it doesn't have to be enabled from the beginning
whimboo: You need to make sure that layout has been updated after setting the overrides before continuing with other commands
jgraham: Are you planning to write spec text for this?
orkon: Yes; I may need some help
Network request interception
github: w3c/
jgraham: (tries to summarise what's in the comment at w3c/
simons: We will need to set the response body quite often, and we'll need to block outgoing requests. I see you say that changing the response might be difficult, but we need that option.
simons: Notably the way people use this is to mock out backend infrastructure and provide canned responses without having to have the backend running.
simons: The CDP model feels OK with continueRequest and fulfillRequest; it's not too hard to use.
jgraham: Replacing the network response is supported, but what's not supported at the moment is editing a response from the network as it arrives
simons: People do sometimes want to do that e.g. for record/replay
jgraham: You could also have a way to just get the entire body at the end.
simons: Yes. We could add support for modifying the response later
orkon: CDP allows fetching the response and providing a different response. I agree we could start without that and see how much interest there is at a later point.
orkon: Are interceptions per context or global?
jgraham: From an API point of view it seems to be easy to limit to a specific context
orkon: What about service workers or iframes? In CDP it's difficult to configure interceptions for new targets. Would be good to specify it per tab.
jgraham: We have a similar problem for events, we could reuse that mechanism
orkon: It can be difficult with iframes. We need some flexibility
RRSAgent: make minutes