16:49:56 RRSAgent has joined #webdriver 16:50:00 logging to https://www.w3.org/2024/02/14-webdriver-irc 16:50:39 Meeting: WebDriver - February 2024 16:50:56 Chair: David Burns 16:51:34 Agenda: https://www.w3.org/wiki/WebDriver/2024-02-BiDi 16:51:47 Scribe: David Burns 16:51:59 ScribeNick: autoamatedtester 16:53:25 RRSAgent, make logs world-visible 16:54:24 rrsagent, make minutes 16:54:25 I have made the request to generate https://www.w3.org/2024/02/14-webdriver-minutes.html AutomatedTester_ 16:55:00 rrsagent, set logs world-visible 16:55:37 ScribeNick: automatedtester 16:55:51 karlcow has joined #webdriver 17:00:44 present+ 17:01:17 present+ 17:01:26 present+ 17:02:27 present+ 17:02:57 I'll drop at 18:30 as well 17:03:57 present+ 17:05:56 AutomatedTester: I have put forward a charter extension to the WG as it is coming to an end at this month and will be working with Mike and plh to make sure it is completed. 17:06:10 present+ 17:07:07 present+ 17:07:31 Topic: WPT use Undefined to signal missing param 17:07:42 github: https://github.com/w3c/webdriver-bidi/issues/642 17:08:25 sadym (IRC): This is a technical issue with wpt. Currently we use null for sending things over the wire. This is not always correct. 17:08:43 q+ 17:08:58 ... sometimes we use the special undefined when we want to test [missed] 17:09:01 q+ 17:09:07 q- 17:09:27 Python can actually not handle null and undefined with None 17:09:29 ... my suggest is that we move to using a unified way to show undefined when new tests are written when fields. shouldnt be sent 17:09:44 q? 17:09:47 ack next 17:10:09 whimboo: I agree we need somet 17:10:19 ...thing better here. I mentioned this before. 17:10:54 present+ 17:11:20 ... my initial proposal is we use null instead of undefined we make something that makes reading the spec and the tests the same 17:11:43 sadym (IRC): I was played around with something that was `optional` 17:12:43 whimboo: would this work as optional equal to none? 17:12:55 ... as none and null are not equal 17:13:06 sadym (IRC): that would work too 17:13:24 ... the only issue is that none is serialised to null in JS 17:13:55 whimboo: let's see if we can play with these in a test and see what works out best 17:14:02 q? 17:14:57 topic: Ability to get the default user agent (via capabilities) 17:15:06 github: https://github.com/w3c/webdriver-bidi/issues/446 17:16:00 orkon: Let me introduce it. In Puppeteer we need an API to know what browser we are talking to 17:16:37 ... I am wondering if we can do this via a capability? 17:16:47 q? 17:16:49 q+ 17:19:11 automatedtester: Computed capabilities can be fine especially we do this when looking at the differences between devices. The question here is why isn't browserName good enough here? 17:19:37 orkon: the browsername is fine but there ar e parts of the UA that are useful to our users and we want to be able to return that 17:20:13 Sam Sneddon [:gsnedders]: I'm not against allowing people to match on UA 17:20:28 ... having to start the browser to figure out if we can match is painful 17:21:36 ... in the PR my question was around if you pass in alwaysMatch that the UA and return something else that would be weird at a protocol level 17:22:22 ... and I don't think it would block the PR but we need to make sure we have a matrix test to show what we want. 17:22:23 q? 17:22:28 ack next 17:22:38 q? 17:23:48 q+ 17:23:56 s/we need to make sure we have a matrix test to show what we want./as the discussion on Matrix showed, we need to have some discussion about how we generally want to deal with output-only capabilities when passed in as an input./ 17:24:47 orkon: I think that I will need to have a look and improve the spec here on what we do if someone passes in a capability that is an output only capability that can never be matched 17:24:56 ack next 17:25:32 whimboo: it would make sense tohave a new issue filed around this and have a meaningful discussion around this 17:26:16 ... as for matching we are already have ways to do matching before the browser is up as much as possible but we need a way know. this 17:26:44 ... e.g. setWindowRect capability is missing for how we handle it 17:27:25 action: Raise an issue around capability matching on output only capabilities 17:28:19 not a problem 17:28:24 topic: Support emulation of the User-Agent 17:28:27 lola_ has joined #webdriver 17:28:36 github: https://github.com/w3c/webdriver-bidi/issues/448 17:28:48 present+ 17:28:59 orkon: this is a feature request I filed 17:29:07 and puppeteer supports it 17:29:29 ... and I am currently leaning towards closing this issue 17:29:43 ... and there is a way that we can implement it 17:29:54 q+ 17:30:11 q+ 17:30:58 automatedtester: from Selenium point of view we don't need this feature and are ahppy for you to close it 17:31:04 ack next 17:31:06 ack next 17:32:36 whimboo: if your fine then great. we can always see about adding this in the future if there are clients that are porting from CDP and are struggling to amek it work 17:32:40 q? 17:32:47 s/amek/make 17:33:12 present- 17:33:20 Topic: Emit browsingContext.navigationStarted before any navigation events 17:33:29 github: https://github.com/w3c/webdriver-bidi/issues/657 17:33:33 q+ 17:33:43 ack next 17:34:50 jrandolf: in the html spec that we have events that come out. Sometimes these events don't come back in an order that makes sense 17:35:22 ... we, chrome, want to propose that we move some of these events so that they happen earlier 17:35:23 q? 17:35:29 q+ 17:35:41 ack next 17:36:19 whimboo: for normal navigations this should be fine. I would need jgraham to review too. I am concerned about hash navigations on this 17:36:31 q+ 17:36:52 ... I think we should probably look into this more deeply 17:36:59 q? 17:37:59 jrandolf: on chromium side, we fragment navigation is sequential for us too 17:38:42 ... the cancellation event can still happen before the started and I think we should be sending that started event 17:39:01 ... and the started event could be faked on fragment navigation 17:39:15 ... and have the started before erroring can occur 17:39:18 q? 17:39:19 ack next 17:39:28 q? 17:40:30 whimboo: could we have some use cases here so we can see the scenarios and the expectations 17:40:40 present- 18:08:45 howard-e has joined #webdriver 19:03:44 karlcow has joined #webdriver 19:43:53 "tests that require the remote..." <- https://github.com/w3c/webdriver/issues/1792 and https://github.com/w3c/webdriver/issues/1793 I think capture all of this? 19:58:58 Zakim has left #webdriver 21:03:32 karlcow has joined #webdriver 22:09:47 karlcow has joined #webdriver 22:30:33 AutomatedTester: we have to make the minutes 22:30:45 not sure how it works :) 22:30:50 RRSAgent (IRC): make minutes 23:39:15 karlcow has joined #webdriver