17:03:16 <RRSAgent> RRSAgent has joined #webdriver
17:03:20 <RRSAgent> logging to https://www.w3.org/2025/02/12-webdriver-irc
17:03:20 <Zakim> Zakim has joined #webdriver
17:03:28 <tidoust> RRSAgent, make logs public
17:03:30 <simons> present+
17:03:32 <AutomatedTester> scribe: David Burns
17:03:38 <AutomatedTester> scribeNick: Automatedtester
17:03:52 <AutomatedTester> Agenda: https://www.w3.org/wiki/WebDriver/2025-02-BiDi
17:03:53 <jimevans> jimevans has joined #webdriver
17:03:58 <AutomatedTester> present+
17:03:59 <jgraham> jgraham has joined #webdriver
17:04:01 <jimevans> present+
17:04:07 <orkon> present+
17:04:11 <tidoust> Meeting: WebDriver BiDi
17:04:15 <tidoust> present+
17:04:22 <sadym> present+
17:04:43 <jgraham> present+
17:04:48 <AutomatedTester> Topic: Display: None and DIsplay:contents
17:04:48 <spectranaut_> spectranaut_ has joined #webdriver
17:04:52 <AutomatedTester> github: https://github.com/w3c/webdriver/issues/1642
17:05:09 <AutomatedTester> whimboo: we've had this issue open for a while
17:05:50 <AutomatedTester> ... I noticed that if you do actions we have difference of how browsers do this. E.g. Firefox errors and the others dont
17:06:01 <AutomatedTester> ... it would be good to define what the behaviour should be here
17:06:17 <AutomatedTester> ... when speaking to jgraham we should likely error
17:06:22 <AutomatedTester> q+
17:06:22 <Nik> Nik has joined #webdriver
17:06:31 <AutomatedTester> ack next
17:07:06 <AutomatedTester> automatedtester: with display:none do we know the location of the element?
17:07:18 <AutomatedTester> jgraham: no, we don't. Display none has nothing in the layout
17:07:21 <AutomatedTester> q?
17:09:24 <AutomatedTester> automatedtester: with actions we should be going through the glass so I ma not sure the correct way here? Should we go up a level in the DOM? or just error?
17:10:07 <AutomatedTester> jgraham: I think we should solve this with an error as this is an edge case. Safari doesn't error but doesn't do anything. It would be to feed back to the end user
17:10:35 <AutomatedTester> whimboo: playwright does one thing different to use with display: contents
17:10:46 <AutomatedTester> q?
17:11:43 <AutomatedTester> action: Spec to be updated to throw an error for display:none
17:12:03 <AutomatedTester> action: whimboo to write a new issue for display:contents with test case and bring it back to the WG
17:12:31 <AutomatedTester> topic: Clarify how the double (triple) click tracking should work in the actions
17:12:43 <AutomatedTester> github: https://github.com/w3c/webdriver/issues/1772
17:13:20 <AutomatedTester> whimboo: this is another issue for actions. I have been checking different frameworks
17:13:59 <AutomatedTester> ... and they do things different ways for solving this e.g. in same chain or different chains
17:14:44 <jgraham> q+
17:14:47 <jimevans> q+
17:14:48 <AutomatedTester> ... so we should solve this to only allow in chain or not especially since separate chains could be tricky to see what people mean
17:14:51 <AutomatedTester> ack next
17:15:03 <sadym> q+
17:15:35 <simons> q+
17:15:38 <jimevans> q-
17:15:47 <AutomatedTester> jgraham: do we know what existing implementations are doing here? if I were building this this myself it would be in the same chain especially around network latency
17:16:12 <orkon> q+
17:16:18 <AutomatedTester> ... I am happy for state to be cancelled at the end of the chain but that might require client changes and that would be problematic
17:16:29 <AutomatedTester> ack next
17:17:14 <AutomatedTester> sadym: there is a potential if the user wants to do 2 single clicks. THey will have to wait a certain time accoridng to the OS
17:17:27 <AutomatedTester> ... so we need to be aware of how that plays out
17:17:27 <AutomatedTester> q?
17:17:29 <AutomatedTester> ack next
17:19:20 <AutomatedTester> simons: I think most clients would do the right thing here in a single chain. I quite like jgraham's suggestion here of cancelling state at the end of the chain
17:20:02 <AutomatedTester> ack next
17:20:03 <jgraham> (I should say I don't know how easy that is to implement)
17:20:34 <jgraham> q+
17:20:49 <AutomatedTester> orkon: how would we specify this behaviour in the spec? Do we want to improve how events are specified?
17:20:57 <AutomatedTester> ack next
17:21:28 <orkon> q+
17:21:40 <chrmod> chrmod has joined #webdriver
17:21:45 <whimboo> q+
17:22:01 <AutomatedTester> jgraham: from the spec point of view. It is quite reasonable for the event must not have the double click attr have it set unless it's part of the action chain and the previous item was a pointer down?
17:22:10 <chrmod> present+
17:22:22 <AutomatedTester> q?
17:22:26 <AutomatedTester> ack next
17:22:52 <AutomatedTester> orkon: I think the complexity is from there being a new event not just another click
17:23:30 <AutomatedTester> ... and it can be challenging for the event to be doing the right order
17:24:06 <AutomatedTester> ... if we don't have a "it must not have" we are making our own rules here
17:24:11 <AutomatedTester> q?
17:24:14 <AutomatedTester> ack next
17:25:17 <AutomatedTester> whimboo: one more comment to jgraham is that it's not only related to the time but it's also about the location of the mouse. E.g. a click, move 1 px, click won't be seen as double click even if it takes the same time as click, click
17:25:22 <AutomatedTester> q?
17:27:00 <AutomatedTester> consensus: we are going to have double clicks in a single chain and clear state at the end of the chain. Also need to check if this might break clients
17:27:16 <AutomatedTester> topic: Should navigables created and navigated via WebDriver BiDi commands be counted as script-closable
17:27:29 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/859
17:28:42 <AutomatedTester> orkon; navigables can be closable which means scripts can do window.close
17:29:13 <AutomatedTester> ... there is also should be differences between browsers
17:29:19 <jgraham> q+
17:29:33 <AutomatedTester> ... I think we should move away from html but do what we know users are expecting
17:29:35 <AutomatedTester> q?
17:29:39 <AutomatedTester> ack next
17:30:11 <AutomatedTester> jgraham: I think I agree with the conclusion here that we should do the same as if you are creating a new tab
17:30:58 <AutomatedTester> ... and that html isn't doing it for script closable and we should make these things unambiguously script closable
17:31:12 <AutomatedTester> q?
17:31:13 <jgraham> s/script/not script/
17:31:40 <tidoust> scribe+
17:31:58 <simons> I also need to leave
17:32:01 <tidoust> Topic: Support for "userContexts" argument to "browsingContext.setViewport" command
17:32:16 <tidoust> github: https://github.com/w3c/webdriver-bidi/issues/851
17:33:34 <tidoust> Alexandra: Would be good to have pre-setup viewports for all browsing contexts. I sketched a proposal for this. There was some concerns on the design. I thought it would be good to bring it here for discussion.
17:33:50 <orkon> q+
17:34:05 <tidoust> ack orkon
17:34:30 <jgraham> q+
17:35:07 <tidoust> orkon: Still need to review the PR on our side. It affects open navigables. That's a side effect. I guess it's not a big concern but maybe we should clarify whether we should activate, etc.
17:35:22 <tidoust> ... I don't think it's a big concern, it seems fine to proceed.
17:35:30 <tidoust> ack jgraham
17:36:15 <tidoust> jgraham: If it seems fine, let's do it. On the general conversation on attaching user contexts, you can already do that one context at a time.
17:36:36 <tidoust> ... I don't think it's making anything new in that case, just making things easier when there are many browsing contexts.
17:37:08 <sadym> q+
17:37:18 <tidoust> ... Useful for when running multiple tests with a given context, e.g., in mobile mode, etc. That helps set things up initially, and not having to worry about that at runtime.
17:37:22 <tidoust> ack sadym
17:37:43 <sasha> q+
17:37:59 <tidoust> sadym: I wonder how we will specify what happens when a new browser context is created. We'll have a viewport for it. Do we have a hook?
17:38:03 <tidoust> ack sasha
17:38:15 <sadym> s/browser/browsing
17:38:54 <tidoust> sasha: Another good topic to discuss. Roughly the moment when we detect the round creation. Pretty early when we have the contextcreated event.
17:39:06 <tidoust> ... Ideally, we would have a hook for that.
17:39:17 <tidoust> ... Early enough, but not sure exactly when.
17:40:35 <tidoust> ... If people have additional feedback on when that should happen, let me know. I'll draft something for further discussion.
17:40:51 <tidoust> jgraham: It should probably be tied to document creation.
17:41:02 <tidoust> ... I need to look into details.
17:41:11 <tidoust> ... Otherwise we could actually update HTML.
17:41:19 <tidoust> ... I suspect it's not observable.
17:41:43 <tidoust> Topic: Geolocation emulation
17:42:23 <tidoust> github: https://github.com/w3c/webdriver-bidi/issues/343
17:43:01 <tidoust> sacha: We would need to pick it up to work on it. Some discussion at TPAC on whether to move things here or in Geolocation spec. It would be good to clarify so we can work on it.
17:43:11 <jgraham> q+
17:43:16 <tidoust> ack jgraham
17:43:35 <tidoust> jgraham: I think we should consider pulling this stuff in our spec.
17:44:02 <tidoust> ... Extending WebDriver BiDi is good, but it has trade-offs that makes it harder to refactor things afterwards.
17:44:16 <orkon> q+
17:44:25 <tidoust> ... We know that emulation is a good feature that we want to have in BiDi and that it's a good idea to have alignment on a model for that.
17:44:45 <tidoust> ... I think there's a demand for such features, easiest way to make progress for me is to work on them here.
17:45:01 <tidoust> ... Of course, if Geolocation folks want to continue to work on this on their own, that's fine.
17:45:05 <tidoust> ack orkon
17:45:46 <jgraham> q+
17:45:55 <tidoust> orkon: A middle-ground here would be useful. Perhaps it makes sense if Geolocation spec provides some mechanism but then CDDL and wiring remains on our side.
17:46:24 <tidoust> ... I didn't review the draft. If it's already good and Geolocation editors want to maintain it, that's good.
17:46:28 <tidoust> ack jgraham
17:46:49 <tidoust> jgraham: We want the actual hooks and algorithms to exist in the spec, I agree.
17:47:29 <tidoust> ... We should talk to Geolocation people, ping that PR. If they can land the hook, we can work on the underlying bits.
17:47:44 <tidoust> ... We don't want to maintain the details of how Geolocation works.
17:47:54 <sasha> q+
17:47:59 <tidoust> ack sasha
17:48:13 <tidoust> sasha: That sounds good to me. I think we have agreement.
17:48:54 <jgraham> q+
17:48:57 <tidoust> ... Follow-up question is where to put it in our modules. It could be in browsingContext but maybe something more modular. Thoughts on this?
17:49:01 <tidoust> ack jgraham
17:50:01 <tidoust> jgraham: I think we should start the emulation module when we add the ability to add to userContext. browsingContext.setViewport. It's just about organizing things nicely.
17:50:05 <orkon> q+
17:50:22 <tidoust> ... There's a bunch of things that we believe that we will have here, e.g., locale override.
17:50:41 <tidoust> ... There's a fairly consistent API that we could end up with.
17:50:54 <tidoust> ... Pretending that you are a mobile device, in a different timezone, etc.
17:51:03 <jimevans> +1 to what jgraham said. "emulation" module for the win.
17:51:04 <tidoust> ack orkon
17:52:02 <jgraham> q+
17:52:02 <tidoust> orkon: An emulation module sounds good. In CDP, there's a problem of the domain. For BiDi, it makes sense to be able to define an alias for commands so that we don't have to duplicate things.
17:52:09 <tidoust> ack jgraham
17:52:29 <tidoust> jgraham: I think we can do that to a very large extent without anything new.
17:52:40 <tidoust> ... "This command uses the parameters from this other place".
17:52:48 <tidoust> ... I think we can make a very small wrapper.
17:53:57 <jgraham> RRSAgent: make minutes
17:53:58 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/12-webdriver-minutes.html jgraham
17:54:55 <jgraham> s/unambiguously script closable/unambiguously not script closable/
17:56:03 <jgraham> s/html isn't doing it for not script closable/html isn't expecting the script closable flag to apply to user created top-level traversables/
17:56:11 <jgraham> RRSAgent: make minutes
17:56:13 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/12-webdriver-minutes.html jgraham
17:56:39 <jgraham> RRSAgent: bye
17:56:39 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2025/02/12-webdriver-actions.rdf :
17:56:39 <RRSAgent> ACTION: Spec to be updated to throw an error for display:none [1]
17:56:39 <RRSAgent>   recorded in https://www.w3.org/2025/02/12-webdriver-irc#T17-11-43
17:56:39 <RRSAgent> ACTION: whimboo to write a new issue for display:contents with test case and bring it back to the WG [2]
17:56:39 <RRSAgent>   recorded in https://www.w3.org/2025/02/12-webdriver-irc#T17-12-03
17:56:48 <jgraham> zakim, bye