16:00:56 <RRSAgent> RRSAgent has joined #webdriver
16:01:00 <RRSAgent> logging to https://www.w3.org/2023/05/10-webdriver-irc
16:01:00 <Zakim> Zakim has joined #webdriver
16:01:32 <patrickangle_> present+
16:02:42 <jdescottes> present+
16:02:46 <jgraham_> Agenda: https://www.w3.org/wiki/WebDriver/2023-05-BiDi#Agenda
16:02:53 <jgraham_> Meeting: WebDriver
16:03:03 <whimboo> present+
16:03:14 <jfernandez> present+
16:03:14 <sasha> present+
16:03:28 <jgraham_> Chair: AutomatedTester
16:03:32 <jgraham_> present+
16:03:39 <jgraham_> RRSAgent: make minutes
16:03:40 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/10-webdriver-minutes.html jgraham_
16:03:45 <sadym> present+
16:03:46 <jgraham_> RRSAgent: make logs public
16:04:29 <AutomatedTester> https://www.w3.org/wiki/WebDriver/2023-05-BiDi
16:04:35 <orkon> present+
16:04:54 <jgraham_> ScribeNick: AutomatedTester
16:06:02 <lola> lola has joined #webdriver
16:06:06 <mathiasbynens> present+
16:06:41 <jgraham_> Topic: Naming conventions for WebDriver / extension specs
16:06:45 <AutomatedTester> Topic: Diverging driver behavior for "clear the modifier key state" in "Dispatch actions for a string"
16:06:49 <jgraham_> github: https://github.com/w3c/webdriver/issues/1725
16:06:51 <AutomatedTester> topic: Naming conventions for WebDriver / extension specs
16:07:02 <AutomatedTester> github: https://github.com/w3c/webdriver/issues/1725
16:07:26 <lola> present+
16:08:34 <AutomatedTester> jfernandez: I will be very brief. The issue is there are conflicts when enumerating driver extension commands
16:08:49 <AutomatedTester> ... I guess that it has never happened
16:09:02 <jgraham_> q+
16:09:23 <AutomatedTester> but now we have a conflict between secure payment and custom handlers
16:09:26 <AutomatedTester> ...  so I would like to get an agreement for enumerations
16:09:30 <AutomatedTester> ... I don't think there is a strong agreement which way like : or - or so on
16:09:44 <AutomatedTester> ack next
16:10:04 <AutomatedTester> jgraham_ (IRC): I think this is purely about the naming conventions. I have been looking through the specs and we are not consistent
16:10:41 <AutomatedTester> ... in bidi we use all lower case
16:10:42 <AutomatedTester> ... error codes have spaces
16:11:05 <AutomatedTester> ... worker types are - separated
16:11:44 <AutomatedTester> ... action types are camel cased
16:11:52 <AutomatedTester> ... where for property names in the json protocol we consistently use camel case
16:12:35 <AutomatedTester> ... we never use snake case. My opinion is that we standardise on space separated like error codes as they are nicely human readable
16:12:44 <AutomatedTester> jfernandez: for context, when <person> at Google did this suggested we do camel case
16:12:48 <AutomatedTester> ... I am not sure the rational
16:13:25 <AutomatedTester> jgraham_ (IRC): the only problem with camel case is that it is a outlier for the work we already have
16:13:42 <AutomatedTester> ... but there is not clear consensus
16:14:24 <AutomatedTester> jfernandez: the SPC editors are happy to changes here
16:15:22 <AutomatedTester> jgraham_ (IRC): since there are no opinions that people comment on the issue
16:15:48 <jgraham_> ScribeNick: jgraham
16:16:31 <mathiasbynens> q+
16:17:46 <jgraham_> jgraham_: I don't mind, but the error codes seem like the most fundamental part of the protocol
16:18:02 <jgraham_> mathiasbynens: We could follow the design guidelines for WebIDL enums
16:18:21 <jgraham_> gsnedders: We could have a straw poll in the GH issue?
16:19:00 <mathiasbynens> jfernandez: can you point me (offline) to the ChromeDriver CL/discussion where camelcase was suggested? thanks
16:19:04 <jgraham_> jgraham: Yes, let's resolve to have a strawpoll on the GH issue.
16:19:19 <jgraham_> Topic: Diverging driver behavior for "clear the modifier key state" in "Dispatch actions for a string"
16:19:29 <jgraham_> GitHub: https://github.com/w3c/webdriver/issues/1734
16:21:50 <jgraham_> 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
16:21:56 <jgraham_> Chrome/Firefox behaviour? That allows unsetting a specific modifier at a time.
16:21:59 <jgraham_> q?
16:22:02 <jgraham_> ack mathiasbynens
16:22:10 <simons> simons has joined #webdriver
16:22:19 <mathiasbynens> yes
16:22:43 <patrickangle_> q+
16:22:50 <jgraham_> acl patrickangle_
16:22:53 <jgraham_> ack patrickangle_
16:23:10 <jgraham_> patrickangle_: This feels like a bug on our end; it seems reasonable this should work.
16:23:33 <jgraham_> whimboo: I suspect this behaviour predates the spec.
16:23:57 <jgraham_> patrickangle_: The handling of NULL is in the spec?
16:24:26 <jgraham_> 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)
16:25:11 <jgraham_> jgraham: I suggest we propose the spec change here and if there are concerns we can discuss again.
16:25:24 <jgraham_> Topic: "Unsupported Operation" for Get Element(s) from Shadow root 'using' xpath and tagname
16:25:35 <jgraham_> GitHub: https://github.com/w3c/webdriver/issues/1610
16:27:10 <JimEvans> present+
16:27:15 <jgraham_> 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
16:27:59 <jgraham_> jgraham: Because the spec doesn't consider the possibility of the locator strategy not working?
16:27:59 <jgraham_> whimboo: Yes
16:27:59 <jgraham_> q?
16:28:22 <jfernandez> mathiasbynens (IRC): done
16:28:27 <JimEvans> q+
16:28:51 <jgraham_> jgraham: This is because the APIs the spec assumes exist aren't on shadowroot
16:29:12 <jgraham_> gsnedders: They also don't exist on document fragement.
16:29:20 <jgraham_> ack JimEvans
16:29:39 <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.
16:29:59 <JimEvans> A specific error would be better than not.
16:30:14 <JimEvans> Or more appropriate than “unknown error”
16:30:51 <jgraham_> 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.
16:32:50 <whimboo> q+
16:33:05 <jgraham_> 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
16:33:09 <jgraham_> ack whimboo
16:33:17 <simons> present+
16:33:21 <jgraham_> whimboo: We have "invalid selector", can we use that?
16:34:18 <jgraham_> jgraham: I assume that's more for invalid css selectors. The obvious one would be "invalid argument" but that's very non-specific
16:34:24 <jgraham_> q?
16:34:53 <jgraham_> Topic: Support emulation of device metrics (width, height, deviceScaleFactor, ...)
16:35:03 <orkon> q+
16:35:12 <jgraham_> github: https://github.com/w3c/webdriver-bidi/issues/415
16:35:31 <jgraham_> ack orkon
16:36:31 <jgraham_> orkon: A good starting point would be the ability to change the viewport and the device pixel ratio.
16:37:10 <jgraham_> orkon: Width/height and dpr for a given context, which should apply to all sub contexts.
16:37:13 <jgraham_> q+
16:37:19 <jgraham_> ack jgraham_
16:38:08 <jgraham_> jgraham: Use case is mobile-ish testing on desktop?
16:38:31 <patrickangle_> q+
16:38:32 <JimEvans> q+
16:38:58 <jgraham_> 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.
16:39:05 <jgraham_> ack patrickangle_
16:39:43 <jgraham_> patrickangle_: I get the pixel ratio emulation. I'm having difficulty understanding why the width/height is needed instead of resizing the window.
16:40:24 <jgraham_> 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
16:41:26 <jgraham_> 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.
16:42:17 <jgraham_> orkon: This isn't directly about the window size. In Chrome currently you can set the viewport size. Affects window.innerWidth and innerHeight.
16:42:40 <jgraham_> orkon: From what I understand it's like a screen size for the content area, but I"m not sure of the details.
16:43:08 <jgraham_> whimboo: Difference between resizing the window and the viewport is that you can set it just for a single tab in the window.
16:43:23 <jgraham_> orkon: It doesn't count the browser UI so it's clearer
16:43:28 <jgraham_> ack JimEvans
16:43:52 <JimEvans> q-
16:44:57 <jgraham_> jgraham: Are you thinking it would apply just to top level tabs and descendents or all contexts?
16:45:11 <JimEvans> I abdicate my place. I misunderstood the full context.
16:45:39 <jgraham_> orkon: It should apply to frames. If the main tab has multiple frametrees, maybe they should all use the same dimensions.
16:45:57 <jgraham_> jgraham: So basically a per-tab setting?
16:46:02 <jgraham_> orkon: Pretty much.
16:46:23 <jgraham_> q?
16:46:38 <whimboo> q+
16:46:43 <jgraham_> ack whimboo
16:47:07 <jgraham_> 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?
16:48:09 <jgraham_> 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
16:48:35 <jgraham_> whimboo: You need to make sure that layout has been updated after setting the overrides before continuing with other commands
16:49:04 <jgraham_> jgraham: Are you planning to write spec text for this?
16:49:12 <jgraham_> orkon: Yes; I may need some help
16:49:32 <jgraham_> Topic: Network request interception
16:49:53 <jgraham_> github: https://github.com/w3c/webdriver-bidi/issues/66
16:53:13 <jgraham_> jgraham: (tries to summarise what's in the comment at https://github.com/w3c/webdriver-bidi/issues/66#issuecomment-1542080588)
16:54:19 <jgraham_> q?
16:54:31 <simons> q+
16:54:43 <jgraham_> ack simons
16:55:01 <orkon> q+
16:55:19 <jgraham_> 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.
16:55:50 <jgraham_> simons: Notably the way people use this is to mock out backend infrastructure and provide canned responses without having to have the backend running.
16:56:12 <jgraham_> simons: The CDP model feels OK with continueRequest and fulfillRequest; it's not too hard to use.
16:58:08 <jgraham_> 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
16:58:20 <jgraham_> simons: People do sometimes want to do that e.g. for record/replay
16:58:47 <jgraham_> jgraham: You could also have a way to just get the entire body at the end.
16:59:02 <jgraham_> simons: Yes. We could add support for modifying the response later
16:59:24 <jgraham_> ack orkon
16:59:58 <jgraham_> 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.
17:00:08 <jgraham_> orkon: Are interceptions per context or global?
17:00:47 <jgraham_> jgraham: From an API point of view it seems to be easy to limit to a specific context
17:01:24 <jgraham_> 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.
17:02:20 <jgraham_> jgraham: We have a similar problem for events, we could reuse that mechanism
17:02:44 <jgraham_> orkon: It can be difficult with iframes. We need some flexibility
17:03:53 <jgraham_> RRSAgent: make minutes
17:03:54 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/10-webdriver-minutes.html jgraham_
18:38:27 <whimboo> jgraham_ (IRC): is manual work needed for that or did you fix it already?
18:41:24 <jgraham> I haven't fixed anything and I don't know how to fix anything
18:41:52 <whimboo> we could manually add the relevant comments to the right issues
18:42:37 <jgraham> I think the issue comments might be OK? It's the minutes that are broken
18:43:10 <jgraham> sideshowbarker: Do you know what's up with that?
18:43:14 <whimboo> ah ok. those I haven't checked. those could be manually created as what I did a while ago
18:43:36 <whimboo> but I can remember that I had some issues and it was troublesome to do
18:44:39 <whimboo> are the minutes really wrong?
18:45:13 <whimboo> there are two empty sections because we switched the ordering
18:45:25 <jgraham_> Oh, right then maybe it's fine
18:45:50 <jgraham_> I didn't notice the same topics were also below
18:45:55 <jgraham_> RRSAgent: bye
18:45:55 <RRSAgent> I see no action items