16:01:39 <RRSAgent> RRSAgent has joined #webdriver
16:01:43 <RRSAgent> logging to https://www.w3.org/2026/01/14-webdriver-irc
16:01:53 <Zakim> Zakim has joined #webdriver
16:02:15 <sadym> present+
16:02:33 <jdescottes> present+
16:02:38 <sasha> sasha has joined #webdriver
16:02:45 <jgraham> Meeting: WebDriver
16:02:59 <orkon> present+
16:03:02 <shs> present+
16:03:02 <lauromoura> present+
16:03:08 <jgraham> Agenda: https://www.w3.org/wiki/WebDriver/2026-01-BiDi#Agenda
16:03:25 <jgraham> present+
16:03:29 <whimboo> present+
16:03:30 <jgraham> RRSAgent, make logs public
16:03:36 <jgraham> RRSAgent, make minutes
16:03:37 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/14-webdriver-minutes.html jgraham
16:04:12 <tidoust> present+
16:04:28 <jimevans> present+
16:05:46 <jugglinmike> jugglinmike has joined #webdriver
16:05:52 <sasha> present+
16:06:00 <jugglinmike> present+
16:06:35 <hbenl> hbenl has joined #webdriver
16:19:33 <jgraham> Topic: Proxy configuration
16:19:48 <jgraham> github: https://github.com/w3c/webdriver/issues/1920
16:21:20 <jgraham> sadym: We want to enable scenarios that are supported by all the browsers, different proxies for different traffic, different proxies for diffrerent protocols e.g. http via SSL, some traffic to one proxy some to another. Have proposed some solutions there. Are the scenarios mentioned supported by all browsers? Do we want to enable it? What the best
16:21:20 <jgraham> way to do it?
16:22:36 <tidoust> scribe+
16:23:10 <tidoust> jgraham: My concern is that it assumes that some schemes exist such as socks or socks5 that don't currently exist.
16:23:22 <tidoust> ... But the principle seems fine to me.
16:23:58 <jgraham> sadym: The updated protocol allows passing either a string or a detailed JSON object, like for unhandledPromptBehaviour
16:24:28 <jgraham> sadym: That would avoid defining a socks schema, so that should address the concern and be more extensible
16:24:57 <gsnedders> gsnedders has joined #webdriver
16:26:54 <jgraham> jgraham: This addresses the concerns I had about coining new protocols or schemes. Historically the spec has been underdefined here, so if possible we should clean it up and have explicit outs for implementations that don't support specific configurations.
16:27:10 <jgraham> q?
16:27:11 <whimboo> q+
16:27:18 <jgraham> ack whimboo
16:27:42 <Yoav> Yoav has joined #webdriver
16:27:45 <jgraham> whimboo: As long as we don't have compatibility issues I'm fine with these changes. If some browsers don't support all configurations that's fine. The cross-protocol configuration sounds good.
16:28:39 <jgraham> gsnedders: We need to make sure there are outs for implementations that don't support configuring certain schemes
16:29:19 <jgraham> action item to review the PR
16:29:41 <jgraham> Topic: Media queries emulation
16:30:29 <jgraham> Topic: Autofill trigger
16:30:41 <jgraham> github: https://github.com/w3c/webdriver-bidi/pull/706
16:30:47 <tidoust> s/Topic: Media queries emulation//
16:32:17 <jgraham> Yoav: On the PR blaze left some comments that we could discuss here. Some comments are discussing going back to a two-phase model where we have a call the registers the data and one that tests using the data. I think there were security objections for that earlier. I'd like to get agreement on which one we should go forward with. If there's
16:32:17 <jgraham> consensus on moving to a two-phase API I can move the API to that.
16:32:54 <sadym> q+
16:33:03 <jgraham> blaze: Most of my concerns at this point are a lack of testcases, so I can't check what to do. One vs two phase doesn't matter to me.
16:33:20 <jgraham> Yoav: If I created a body of tests using this, would that be useful to you?
16:33:27 <jgraham> blaze: Yes
16:34:03 <sadym> q-
16:34:13 <jgraham> Yoav: I can do that, we have some tests from the previous iteration, we have an implementation which we can use. How would you like those tests a PR against wpt?
16:34:18 <jgraham> blaze: Yes, wpt is best
16:34:42 <jgraham> blaze: I can leave more comments on the test.
16:34:56 <jgraham> ACTION: Yoav to create some tests for this API
16:35:17 <AutomatedTester> AutomatedTester has joined #webdriver
16:35:30 <sadym> Here are examples of using that command: https://github.com/GoogleChromeLabs/chromium-bidi/blob/1f4a9e9389597f99e0bde231b0506b11a03cc740/tests/autofill/test_autofill_trigger.py
16:35:33 <AutomatedTester> present+
16:35:41 <Yoav> https://github.com/WICG/autofill-event
16:35:57 <Yoav> https://wicg.github.io/autofill-event/
16:36:17 <jgraham> Yoav: One more thing that would be potentially useful is that we have a spec for a web-exposed API for autofill; that would be tested by this WebDriver API
16:39:04 <jgraham> sadym: The concern was about the expected effect of the atuofill. We have an implementation and you can check that autofill is triggered and that the fields are filled in. That might address blaze's concern.
16:40:11 <jgraham> Topic: Media queries emulation
16:40:28 <jgraham> scribe+ AutomatedTester
16:40:32 <AutomatedTester> scribe: David Burns
16:40:35 <jgraham> RRSAgent: make minutes
16:40:36 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/14-webdriver-minutes.html jgraham
16:41:13 <AutomatedTester> Topic: Media features emulation
16:41:19 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/750
16:41:51 <AutomatedTester> sasha: This could be similar to the mobile emulation topic
16:42:37 <AutomatedTester> ... this for doing dark/light mode etc. There has been some feedback that a number of people would like this and it would be good to discuss what the API would look like
16:42:55 <AutomatedTester> ... sadym I am not sure if you want to discuss your proposal
16:43:16 <AutomatedTester> sadym: the proposal was to extend the parameters of what could be emulated and related features
16:43:22 <AutomatedTester> q?
16:43:27 <sasha> q+
16:43:37 <AutomatedTester> ack sasha
16:43:54 <AutomatedTester> sasha: one of the proposals was to extend how to do the viewport
16:44:02 <AutomatedTester> ... and a command for media queries
16:44:15 <sadym> q+
16:44:21 <AutomatedTester> ... and another command for media features and each command would have different parameters
16:44:24 <AutomatedTester> ack next
16:45:05 <sasha> q+
16:45:06 <AutomatedTester> sadym: the main concern with different commands is that if you mix emulations
16:45:23 <AutomatedTester> ... it could be quite long to set up the emulation on first run
16:45:41 <AutomatedTester> ... there could be issues with race conditions if we do multiple commands
16:45:47 <jgraham> q+
16:45:59 <AutomatedTester> ... I think that it would be better to have one command that sets all the emulation features all at once
16:46:04 <AutomatedTester> ack next
16:46:45 <AutomatedTester> sasha: I think that for rendering that would be a good thing to make sure we don't rerendering
16:47:02 <AutomatedTester> ... it might be also be good to discuss how we do multiple commands at once
16:47:56 <sadym> q+
16:48:05 <AutomatedTester> ... it would also like to discuss the mobile modes. I think that having a number of commands are better as things could override how other specs are done. E.g. Print features don't need to work with mobile features and so on
16:48:07 <AutomatedTester> ack next
16:48:50 <jdescottes> q+
16:48:53 <AutomatedTester> jgraham: it is true that with the ability to batch commands that we would could benefit from commands that run atomically
16:49:25 <AutomatedTester> ... there are times where commands don't always merge in nicely and would that benefit from the batching
16:49:29 <AutomatedTester> ack next
16:49:41 <gsnedders> q+
16:50:22 <AutomatedTester> sadym: it would be great to do batching... should we invest time now on that
16:51:09 <AutomatedTester> ... if we decide on extending set viewport... do we want to specify what features we want to emulated or do we want to keep it open ended by passing in a map of features and you may get a not supported response?
16:51:13 <jgraham> q+ to say "no" to it being open ended
16:51:30 <AutomatedTester> ack next
16:51:31 <sadym> Proposed and alernative solutions: https://github.com/w3c/webdriver-bidi/issues/750#issuecomment-3682131297
16:52:19 <AutomatedTester> jdescottes: on the topic of command optimizer vs batcher... I am not sure that we have something that is going to be a strong argument
16:52:58 <AutomatedTester> ... on the question of which layer which should group things, I am not sure that bidi is the correct place to descrivbe what mobile emulation should mean
16:53:18 <AutomatedTester> ... I would prefer to keep separate commands
16:53:21 <AutomatedTester> ack next
16:54:18 <AutomatedTester> gsnedders: the thing I wanted bring up, which is similar to proxy, there are some things that some implementation and we need to handlke the case where an implementation doesn't support a given media feature
16:54:22 <AutomatedTester> ack next
16:54:23 <Zakim> jgraham, you wanted to say "no" to it being open ended
16:55:12 <AutomatedTester> jgraham: to sadym saying should we list ieverything or have it open ended... we need to spec this properly and means describing it all
16:55:40 <sadym> q+
16:56:06 <AutomatedTester> ... and having 1 command vs multiple is how do we deal with the case that an implementation can do 8/10... how do we descrive the 2 things that cant be done back to the client
16:56:21 <AutomatedTester> ... and I agree with jdescottes that there is value in batching
16:57:01 <AutomatedTester> ... however, that making that for everything is that it can be very hard to optimise the reading in of the payload
16:57:28 <AutomatedTester> ... since its a specific mechanism it might be easier to optimise this
16:57:48 <AutomatedTester> q?
16:57:50 <AutomatedTester> ack next
16:58:23 <AutomatedTester> sadym: so technically we can return not supported params in this command or other commands
16:58:35 <jgraham> q+
16:58:39 <AutomatedTester> ...so it would have to return all the unsupported features
16:58:56 <AutomatedTester> ... and then it would be up to the client on how to proceed
16:59:00 <AutomatedTester> ack next
16:59:43 <AutomatedTester> jgraham: there are semantics that we can define there... it feels a little like reinventing capabilities but across the protocol
16:59:58 <AutomatedTester> ... and it adds complexity
17:00:11 <sadym> q+
17:00:49 <AutomatedTester> ...you could, and i am not proposing, that we can do like capabilities and we would have mandatory/not mandatory in what people want
17:01:13 <AutomatedTester> ack next
17:02:21 <AutomatedTester> sadym: given that situation of geolocation. If the remote end doesn't handle bearing... they try emulate and remote end doesn't it errors, the client could try again or deal with it accordingly. it will create a lot of traffic
17:02:37 <jgraham> q+
17:02:46 <AutomatedTester> ... or we could collect them together. It's tradeoffs between protocol, speed, etc
17:02:48 <AutomatedTester> ack next
17:03:28 <sadym> q+
17:03:35 <AutomatedTester> jgraham: that's fair. We can discuss this async around discussing how this would return a standardised way of saying this key would be error
17:03:47 <AutomatedTester> ack next
17:04:28 <AutomatedTester> sadym: if I understand what you're saying is that it is similar to what I was saying with each command would have a standardised response
17:06:04 <AutomatedTester> jgraham: if we have a bunch of commands that it has an extension to the error format about which parts were unsupported when returning to the user. Currently the protocol doesn't support that
17:06:08 <AutomatedTester> q?
17:07:29 <AutomatedTester> sadym: there is consensus that it is wanted but we need to work on the commands/errors and how that is sent back and forth
17:09:15 <jimevans> q+
17:09:18 <orkon> q+
17:09:41 <AutomatedTester> sadym: to jimevans, what are your thoughts as a client author
17:09:45 <AutomatedTester> ack next
17:10:24 <AutomatedTester> jimevans: my general philosophy that we can make the protocol less chatty we should take advantage of that
17:11:01 <AutomatedTester> ... one of the drawbacks is that it it tends to do things with a lot of round trips and if we can make that avoidable I would prefer that
17:11:39 <AutomatedTester> ... if we can do a single command it is a better design so that could be command batching, which I am proponent of, or a single command
17:12:09 <AutomatedTester> ... I think that command batching will be useful for multiple clients
17:12:17 <AutomatedTester> ack next
17:12:19 <jdescottes> q+
17:12:54 <AutomatedTester> orkon: I think the round trip argument doesn't matter for bidi since we can do things in a event driven way
17:13:17 <jgraham> https://github.com/w3c/webdriver-bidi/issues/447 is the command batching proposal
17:13:29 <AutomatedTester> ... in puppeteer and cdp they have separate commands so I prefer that
17:13:33 <jgraham> q+
17:13:37 <AutomatedTester> ack next
17:14:16 <AutomatedTester> jdescottes: one concern with separate commands is that we had a case with too many commands being sent at once that could lead to race commands
17:14:43 <AutomatedTester> ... if people want to improve performance could cause problems that batching would solve
17:15:04 <AutomatedTester> ... so if performance is wanted we should look at how batching can help
17:15:07 <AutomatedTester> ack next
17:15:41 <AutomatedTester> jgraham: I started thinking about the generic case rather than the specific case
17:15:49 <sadym> q
17:15:52 <sadym> q+
17:16:22 <AutomatedTester> ... <not sure if worth minuting this :) >
17:16:26 <AutomatedTester> ack next
17:17:25 <AutomatedTester> sadym: for what I have understood is that would have single command per feature area or one command that takes all the features?
17:19:36 <AutomatedTester> jgraham: I think the consensus is per feature but we can discuss the minutae in github
17:20:03 <AutomatedTester> topic: Supporting await in Execute Script
17:20:16 <AutomatedTester> github: https://github.com/w3c/webdriver/issues/1436
17:21:34 <AutomatedTester> jugglinmike: this is an old issue that I wanted to bring it up
17:21:34 <jgraham> s/consensus is per feature/consensus is not there yet/
17:22:13 <AutomatedTester> ... and I appreciate this isn't high priority work for this group
17:22:44 <gsnedders> The PR being https://github.com/w3c/webdriver/pull/1431 I presume?
17:23:00 <AutomatedTester> ... and I have a non-trivial patch that I would like the group to actually solve this rather than firing it into github and hoping it it is eventually reviewed
17:23:41 <AutomatedTester> ... and think whimboo has been responsive and he has been reviewing that
17:23:43 <jgraham> q+
17:24:00 <AutomatedTester> ... and I think that when whimboo returns he could help me close the loop on this
17:24:18 <gsnedders> q+
17:24:21 <AutomatedTester> ... and I hope to get a PR in by the end of the week on this
17:24:27 <AutomatedTester> ack next
17:24:42 <AutomatedTester> jgraham: I think if you have a PR please send it in
17:25:12 <AutomatedTester> ... it's not a surprise that classic has holes and it's because it predates what was on the platform
17:25:26 <AutomatedTester> ... and it's not clear from wpt what should be done here
17:25:41 <AutomatedTester> ... but in principle we should definltey fix the spec there
17:26:02 <AutomatedTester> ... but implementations may not go fix it as it might not be a priorty
17:26:03 <AutomatedTester> ack next
17:26:13 <AutomatedTester> gsnedders: there is a PR that I linked to in irc
17:27:01 <AutomatedTester> ... it is from 2019. it was trying to move the terminology of when to execute things and not sure what is different in this spec
17:27:23 <AutomatedTester> ... and I remember back then there was a lot of issue with how promises should work in this context
17:28:13 <AutomatedTester> jugglinmike:
17:28:16 <jgraham> +1 to making the smaller change :)
17:28:52 <AutomatedTester> jugglinmike: I think I want to probably close the original patch and get things better improved and I am more pragmatic about how it runs
17:29:08 <AutomatedTester> gsnedders: bidi seems to handle this much better
17:29:30 <AutomatedTester> jugglinmike: I think that's to jgraham point that the platform has improved a lot here and we're taking advantage of it
17:30:00 <AutomatedTester> gsnedders: let's make bidi do the correct thing and then make classic do the right thing that is similar to bidi now
17:30:07 <AutomatedTester> RRSAgent: make minutes
17:30:09 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/14-webdriver-minutes.html AutomatedTester
17:30:15 <gsnedders> s/make bidi do/make sure bidi does/
17:30:15 <jgraham> q+
17:30:25 <AutomatedTester> ack next
17:31:37 <AutomatedTester> jgraham: one tangentially related point, we have strongly avoided references between classic and bidi. If we have a CR of bidi then it could make things look different
17:31:51 <AutomatedTester> q?
17:32:11 <AutomatedTester> topic: Timeout for browsingContext.locateNodes
17:32:24 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/1055
17:33:15 <AutomatedTester> jimevans: it has become clear to me as a client author is one thing users want is they want to call a command and not have it it return until thing they want is done
17:33:45 <AutomatedTester> ... for things like locating an element/node or waiting for an element to interactable before returning the command
17:34:48 <AutomatedTester> ... to that end that locating node on a page that we can create a way in the protocol to optionally wait for something to be true
17:35:37 <AutomatedTester> ... I can see why the protocol might not want to do it and they have to put it into the client which adds complexity to how things go back and forth
17:36:08 <AutomatedTester> ... and I have said earlier that fewer trips acorss the wire is better
17:36:39 <AutomatedTester> ... and if we move it to the protocol that would make things better for users
17:36:51 <jgraham> q+
17:37:01 <AutomatedTester> ... I am not concerned with how we should structure the data sent across the wire
17:37:11 <sadym> q+
17:37:17 <jdescottes> q+
17:37:31 <AutomatedTester> ... my concern is that, as a client author, is that I want to mkae 1 call across the protocol rather than many
17:38:11 <AutomatedTester> .... I understand that it complicates the remote end of the protocol
17:38:19 <AutomatedTester> ack next
17:38:55 <AutomatedTester> jgraham: I agree there is clearly a pattern in libraries that want to to wait for a page to reach a certain point
17:39:15 <jimevans> q+
17:39:30 <AutomatedTester> ... I believe that in puppeteer/playwright do this via polling which isnt problematic
17:40:23 <AutomatedTester> ... which makes it a low priority for now and we have avoided timeouts in the current spec
17:41:01 <jdescottes> q-
17:41:04 <AutomatedTester> ... I do take your point that if the only tool the client has about polling
17:41:10 <orkon> q+
17:41:21 <AutomatedTester> ... <dicsusses items in the github issues>
17:41:57 <AutomatedTester> ... as we things that can be done via javascript commands
17:42:31 <orkon> q-
17:42:49 <AutomatedTester> ... if we aren't having timeouts elsewhere in the code, is locatenodes a special case?
17:42:58 <AutomatedTester> ack next
17:43:31 <AutomatedTester> sadym: from the user perspective that 95% of failures are down to not waiting properly
17:44:14 <AutomatedTester> ... and there are times where locate nodes is the way to do it in a SPA. As for client or browser I lean towards client
17:44:44 <orkon> q+
17:44:59 <AutomatedTester> ... all the solutions have tradeoffs but I think it should live in the client side
17:45:01 <AutomatedTester> ack next
17:46:41 <AutomatedTester> jimevans: we have touched on some of my concerns. We do allow searching for nodes via hard ways that cant be done via JS. As a client library if you wanted to search shadow roots for a given child instead of the light dom, it becomes hard to deal with in JS if the shadow roots are closed
17:47:01 <AutomatedTester> ... however we allow piercing the shadow roots
17:47:22 <AutomatedTester> ... it is something that many users are confused on how to handle
17:48:16 <AutomatedTester> ... and they see it as a feature of non-selenium client about piercing closed shadow root. Playwright does element location is done via JS injection and can only do open shadow roots
17:49:00 <AutomatedTester> ... and I do believe locating nodes is unique since not all our strategies can be done with JS
17:49:38 <AutomatedTester> ... and in the interest of trying to reduce the traffic
17:50:21 <AutomatedTester> q?
17:50:24 <AutomatedTester> ack next
17:51:13 <AutomatedTester> orkon: We do polling via different mechanism. We also have mutation observers but they don't support shadow roots
17:52:28 <AutomatedTester> ... my opinion is that we should have it but I dont think that its a magical way to solve. We need to have a way to handle this properly
17:52:30 <jgraham> q+
17:52:45 <AutomatedTester> ack next
17:53:02 <jimevans> q+
17:53:38 <AutomatedTester> jgraham: if I am paging things in better, we dont have a way to handle shadow roots that are closed
17:53:56 <AutomatedTester> ... i think if we make locatenodes more powerful that we should have a timeout
17:54:16 <AutomatedTester> ... I can't rememober the discussions that got use to the tradeoffs that we currently have
17:54:44 <AutomatedTester> ... i think we will either do something basic which wasn't as perfomant as puppeteer
17:55:32 <AutomatedTester> ... so one of the questions is do we have someone that is happy to descrives the work around doing things like that
17:55:49 <jdescottes> q+
17:55:58 <AutomatedTester> ... I think the biggest value areas or locators that don't map to JS APIs
17:56:00 <AutomatedTester> ack next
17:57:09 <AutomatedTester> jimevans: I do remember of how we got to current implemention. The original proposal was more complicated and we simplified around not batching
17:57:41 <AutomatedTester> ... if we decided to apply this to things that can't easily replicated with cases that can't be handled by JS
17:58:13 <AutomatedTester> ... my worry is that I can't spec it but I know others in this group can
17:58:55 <AutomatedTester> ... I am hoping that others see the merit in what I am proposing and help spec it
17:59:04 <sadym> q+
17:59:12 <AutomatedTester> ... if the group wants to ignore it that's fine too
17:59:14 <AutomatedTester> ack next
17:59:53 <AutomatedTester> jdescottes: potentially a bad idea is that specing polling could be hard but if we had a generic polling should be simple to do
18:00:02 <jgraham> q+
18:00:02 <AutomatedTester> ack next
18:00:50 <jdescottes> s/specing polling/specing polling strategies/
18:01:16 <AutomatedTester> sadym: jimevans do you have an estimate of time to move to from polling to server, what is the percentage of time that time
18:02:01 <AutomatedTester> jimevans: I don't have metrics but want to point out that localhost isn't the only use case here. Remote end could be somewhere in the cloud
18:02:36 <AutomatedTester> ... that could mean a significant relative performance gains if in the cloud case
18:03:09 <AutomatedTester> sadym: my gut is saying the delay shouldn't be no more than latency of the connection
18:03:54 <AutomatedTester> jimevans: that's what I said in absolute perfomance I am not sure of the gains but in relative performance there would be gains by my gut feel
18:03:58 <AutomatedTester> q?
18:04:02 <AutomatedTester> ack next
18:04:44 <AutomatedTester> jgraham: regarding jdescottes about a generic retry command. There is an appeal to having this
18:05:50 <AutomatedTester> ... it's harder to handle the generic case. I think we need to look through the spec  to see how we can benefit things here
18:06:38 <spectranaut_> spectranaut_ has joined #webdriver
18:06:52 <orkon> q+
18:06:52 <AutomatedTester> ... we can see a complicated client, like puppeteer could have their own retries while a simple client could rely on these retries
18:06:57 <AutomatedTester> ack next
18:07:41 <AutomatedTester> orkon: I wanted to mention that if a person has a latency issue
18:08:31 <AutomatedTester> ... if people are awaiting 100ms. If we don't do the complicated polling, then the simple polling can be done on the client
18:08:52 <AutomatedTester> ... it might solve chattiness of the protocol but not improve the performance
18:09:09 <sadym> * my gut says if the client polls and there is a need in retry, it means there is a delay of the node to appear. And if so, it should not be that different from if the client was very close to the server.
18:09:59 <jdescottes> q+
18:10:45 <jimevans> q+
18:10:52 <AutomatedTester> jdescottes: I will file an issue around creating a generic polling. Is this for performance or easier to use?
18:10:55 <AutomatedTester> ack next
18:11:00 <AutomatedTester> ack next
18:11:50 <AutomatedTester> jimevans: this is around using a different client to selenium and it made my client code harder to create as a generic new client that finds it hard to create
18:12:33 <jgraham> q+
18:12:36 <AutomatedTester> ack next
18:13:20 <AutomatedTester> jgraham: there is some appetite to look at this in the future and do a little more review for the future. Let's keep the issue open for now
18:14:13 <tidoust> scribe+
18:31:50 <tidoust> scribe+
18:36:34 <jgraham> Topic: Multiple click events (e.g. double/triple click)
18:36:47 <jgraham> github: https://github.com/w3c/webdriver/issues/1772
18:36:54 <jgraham> RRSAgent, make minutes
18:36:56 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/14-webdriver-minutes.html jgraham
18:38:44 <tidoust> Topic: Multiple click events (e.g. double/triple click)
18:38:55 <jgraham> github: https://github.com/w3c/webdriver/issues/1772
18:39:30 <tidoust> Sacha: The point which wasn't addressed yet is that some clients will still want to genere double cllicks or triple clicks with different action chains, maybe because they need to run some script in between.
18:39:38 <jgraham> q+
18:39:47 <jgraham> ack next
18:40:17 <tidoust> jgraham: The way it works at the moment is that it's left at the implementation to define what double-click or triple-click means.
18:40:43 <tidoust> ... Gecko more or less uses a timer and if the events happen within that timer, they get counted as double clicks and so on.
18:41:13 <tidoust> ... Relying on internal timers is a bit difficult because it makes things undeterministic.
18:41:26 <tidoust> ... If you split across action chains, latency comes into play as well.
18:41:47 <tidoust> ... It has also seemed logical to me that things needed to be within the same action chain to be counted together.
18:42:16 <tidoust> ... However, some use cases involve starting a click, running an event handler, and then continuing with the rest of the click.
18:42:16 <orkon> q+
18:43:01 <tidoust> ... One option is to have a specific clickCount property.
18:43:20 <tidoust> ... We could have some sort of sequence identifier to relate actions together.
18:43:42 <tidoust> ... to increment clickCount when actions are part of the same sequence.
18:43:58 <shs> q+
18:44:00 <tidoust> ... But then the question is whether the timer still runs in that case. E.g., if the same sequence is used 30s apart?
18:44:19 <jgraham> ack next
18:45:00 <shs> q-
18:45:12 <tidoust> orkon: I think if we're doing double click based on the action chain, that's fine. After an action chain is dispatched, you released all the actions, says the proposal.
18:45:44 <jgraham> q+
18:45:49 <gsnedders> gsnedders has joined #webdriver
18:45:49 <tidoust> ... If the event chain causes things to be released, would scenarios that involve checking on mouseup following mousedown still work?
18:45:55 <jgraham> ack next
18:46:23 <tidoust> jgraham: I don't think it makes sense to release all the events at the end of the action chain.
18:46:28 <gsnedders> q+ to ask about devices without mouse input
18:46:34 <orkon> q+
18:46:51 <tidoust> ... I think they should just not be able to merge as part of a single click if they're not part of the same action chain.
18:47:03 <sasha> q+
18:47:19 <tidoust> ... Something may come from how Playwright handles it.
18:47:20 <jamesn> jamesn has joined #webdriver
18:47:22 <jgraham> ack next
18:47:23 <Zakim> gsnedders, you wanted to ask about devices without mouse input
18:47:25 <orkon> q-
18:47:31 <tidoust> s/Sacha/Sasha/
18:48:32 <tidoust> gsnedders: Wondering about what it means for devices without mouse input types
18:48:39 <jgraham> ack next
18:48:40 <orkon> q+
18:48:43 <tidoust> ... Maybe the answer is simple.
18:49:41 <tidoust> sasha: I just wanted to address Alex comment about resetting the chain. What Hendrik meant was for the double-click only. Related to our implementation. By the end of the action, we would not expect a double-click coming. That would not be for all events.
18:50:38 <tidoust> ... For Playwright, for them they want to generate a double click with two clicks using two different actions. They use clickCount in CDP for that. They don't necessarily do anything in between these two chains.
18:50:41 <jgraham> q+
18:51:16 <tidoust> ... Sequences are more flexible. They open the question on how to validate that they still make sense.
18:51:24 <jgraham> ack next
18:52:43 <tidoust> orkon: Making it possible to double click with two clicks is probably not a good idea, we used to have it in Puppeteer. Splitting things across chains is also not super consistent.
18:53:09 <tidoust> ... You can one mousedown in one chain with script evaluation. And then mouseup and click in another action chain.
18:53:24 <tidoust> ... It's not timer based in that case.
18:53:27 <jgraham> ack next
18:53:28 <sasha> q+
18:53:37 <tidoust> ... There's some inconsistency although we can perhaps live with it.
18:54:37 <tidoust> jgraham: For devices without mouse input, unsupported operation seems a good answer. Double tap is still doable there.
18:55:10 <tidoust> ... Sequence ids are more flexible, but there is still the question of the timer.
18:55:42 <shs> q+
18:55:44 <tidoust> ... Timer seems not ideal but it wouldn't be ideal to drop it as well. If there's no timer, should there be something to cancel the sequence?
18:56:10 <tidoust> ... Should a set of pointer actions cancel the sequence?
18:56:12 <jgraham> ack next
18:56:34 <tidoust> sasha: I wanted to comment on what Alex was saying on consistency
18:56:35 <shs> q-
18:56:51 <tidoust> ... The whole issue started with trying to understand how it works for different browsers and specify something.
18:56:59 <tidoust> ... Nothing specifies it in the current spec.
18:57:36 <tidoust> ... The main point is to specify something that is consistent across browsers that would allow clients to simulate double or triple clicks consistently.
18:57:59 <shs> q+
18:58:12 <tidoust> ... If implementations are different but the specification still allows that, that seems fine.
18:58:18 <jgraham> ack next
18:59:21 <tidoust> shs: It seems like the only way to do that reliably is to have all actions in the same action chain. Otherwise, not only will you hit timer issues, but also you may end up with timing issues with the underlying system.
18:59:33 <tidoust> ... These cannot be spec-ced out cleanly.
18:59:56 <tidoust> ... It may be that we want to be able to add as part of a single action chain. We mentioned scroll into view.
19:00:09 <jgraham> q+
19:00:10 <tidoust> ... Related to operations that we may want to do as part of an action chain.
19:00:30 <jgraham> ack next
19:01:34 <tidoust> jgraham: The simplest approach is to say that by default mulitple click events that happen as part of the same actions chain increase the click count unless something causes delay as part of the actions.
19:02:04 <tidoust> ... That's the least that I know how to specify. It covers the simple cases, and then we can work increasingly from there.
19:02:14 <tidoust> ... My concern is incompatible changes.
19:02:37 <tidoust> ... For the time being, people may rely on timers to trigger double or triple clicks, and that would break.
19:02:56 <tidoust> ... But then the alternative would be to say that the timer is implementation-defined, which does not seem a good thing either.
19:03:12 <sasha> q+
19:03:19 <jgraham> ack next
19:03:50 <jgraham> q+
19:03:54 <tidoust> sasha: If we would find some kind of different solutions to simulate double clicks consistently, implementations could converge to them over time and we would have a transition path.
19:04:04 <jgraham> ack next
19:04:05 <orkon> q+
19:04:25 <tidoust> jgraham: It would be possible to opt-in in a couple of ways.
19:04:51 <tidoust> ... You could add a property on specific events. But I guess that we would things to work like this in general.
19:05:20 <tidoust> ... Opting in for deterministic behavior seems doable in any case.
19:05:35 <jgraham> You could also opt in on a performActions call
19:05:39 <jgraham> ack next
19:06:19 <tidoust> orkon: Just to confirm that we still want mousedown and mouseup as part of different action chains to trigger a single click.
19:06:31 <jgraham> q+
19:06:44 <tidoust> ... I imagine scenarios where you have mousedown in an actions chain, then mouseup, mousedown, mouseup in the next one.
19:06:46 <jgraham> ack next
19:06:50 <tidoust> ... Should that trigger a double click or not?
19:07:17 <tidoust> jgraham: I guess click isn't on a timer at the momen. At least, I don't think Gecko has a timer.
19:07:26 <tidoust> s/momen/moment
19:07:44 <tidoust> ... If there is no timer, it seems easier to say that it can persist across action chains.
19:08:03 <tidoust> ... But I actually do not know.
19:08:20 <AutomatedTester> q?
19:08:29 <sasha> q+
19:08:35 <AutomatedTester> ack next
19:09:22 <tidoust> sasha: To summarize, that's how I imagined it, that we would keep the current behavior but would add a more deterministic way to also do double and triple clicks.
19:11:02 <tidoust> jgraham: I'm not immediately seeing what part of the DOM API to attach timestamps to.
19:11:44 <tidoust> ... Is long press reflected in the DOM API somehow? Do you have to implement it by hand?
19:12:10 <tidoust> orkon: I think it's a timer you can measure by yourself.
19:12:30 <tidoust> jgraham: That seems ok. We don't have to care if we don't have to measure time by ourselves.
19:13:15 <tidoust> ... If you try and do mousedown, mouseup, mousedown, mouseup split in different action chains, it probably doesn't trigger a double click.
19:13:30 <tidoust> gsnedders: There were some tests on Pointer Events along those lines.
19:13:41 <tidoust> jgraham: We should look at that.
19:13:59 <gsnedders> s/on Pointer Events/in the Interop Pointer Events focus area/
19:14:15 <tidoust> ... Sometimes, I've been wondering whether they were doing silly things or whether we were misusing the TestDriver API.
19:14:38 <AutomatedTester> topic: Screencasting
19:15:08 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/636
19:15:37 <tidoust> sasha: We wanted to start discussing screencasting following a few requests received on that.
19:15:50 <tidoust> ... Similar API in CDP. It would make sense to add that to BiDi as well.
19:16:22 <tidoust> ... Obvious way to work with it would be with Streams, but since we don't have Streams in BiDi, our suggestion was to start with file on the disk.
19:16:38 <tidoust> ... CDP works with streams so perhaps not interested in an intermediary solution though.
19:16:43 <AutomatedTester> q+
19:16:52 <tidoust> ack next
19:17:23 <tidoust> AutomatedTester: Are we straight away saying that we wouldn't support certain mobile devices where it might be harder to access the filesystem?
19:18:25 <tidoust> jgraham: I think the answer is yes to some extent. An implementation could do something more complicated. Something like Gecko driver to control a mobile device, the host could imagine storing the file itself.
19:18:54 <tidoust> ... The implementation complexity is probably the same as having the streaming API and having the client do the streaming to the local disk.
19:19:18 <AutomatedTester> q?
19:19:22 <orkon> q+
19:19:35 <tidoust> ... It seems important for users to save to local disk. That's the API that Playwright is offering. That's a user need.
19:19:48 <tidoust> ... The streaming API will then allow us to improve on this over time.
19:19:54 <AutomatedTester> ack next
19:20:03 <tidoust> AutomatedTester: A fair counter argument.
19:20:27 <AutomatedTester> q+
19:20:37 <tidoust> orkon: Saving to disk is fine in Playwright cases. Other cases where you want to look into realtime, like dev tools.
19:20:46 <tidoust> ... It would be nice to support both, with a streaming API.
19:21:05 <tidoust> ... But it's not easy to have streaming. Streaming a video is different for example.
19:21:29 <jgraham> q+
19:21:31 <tidoust> ... It would be preferable to start with a streaming API in some way unless we think it's not feasible.
19:21:33 <AutomatedTester> ack next
19:21:45 <gsnedders> q+
19:21:56 <tidoust> AutomatedTester: The argument for streaming real time is one that will be used quite heavily by cloud providers.
19:22:14 <tidoust> ... The way we do it right now is by capturing the screen in real time.
19:22:25 <tidoust> ... There's a bit of latency there, but that's fine.
19:22:36 <tidoust> ... We're talking about millions of tests run this way.
19:22:40 <sadym> q+
19:22:46 <jgraham> q-
19:22:54 <tidoust> ... If we can go to the streaming API directly, that would be better.
19:23:05 <tidoust> ... I appreciate it means different things depending on context.
19:23:13 <AutomatedTester> ack next
19:24:21 <tidoust> gsnedders: There's both the use case that David was just talking about. Also iOS is very limited in terms of file system access. I wouldn't be opposed to having a capability that allow you with the file system directly, but obviously not all servers can support that.
19:24:40 <jgraham> q+
19:24:49 <tidoust> ... When it comes to the streaming side, it gets to video streaming protocols with all sorts of complication, and that kind of scares me.
19:24:58 <AutomatedTester> ack next
19:25:49 <tidoust> sadym: Streaming and saving to file are not that different. Would it be easier for browsers to implement saving to file rather than screencast? What is the motivation for saving to file?
19:25:58 <AutomatedTester> ack next
19:26:29 <tidoust> jgraham: The motivation is that we currently don't have a streaming API. The DOM has media capture primitives and writing to the disk is relatively easy.
19:26:49 <tidoust> ... And that makes adding the feature easier in one go. That already covers a good range of cases that we know about.
19:27:00 <tidoust> ... Not the end of it, but useful for a number of users.
19:27:14 <tidoust> ... If we don't want to do that, we should prioritize getting the streaming bits running.
19:28:13 <tidoust> ... I'm hoping that it can build on top of [missed]. From a client perspective, if you want to have a video in the end, having to do that from bits seems hard to do.
19:28:24 <gsnedders> Stream is high overhead, esp. with base64 encoding, and potentially could easily eat up a lot of the available bandwidth.
19:28:29 <tidoust> ... Working with files is much simpler for everyone, it appears.
19:28:31 <orkon> q+
19:28:38 <AutomatedTester> ack next
19:28:55 <jgraham> s/[missed]/a simple byte stream polling interface/
19:29:11 <tidoust> orkon: Should we explore streaming over HTTP? Or do you think it adds more complexity?
19:29:46 <tidoust> jgraham: I think it adds more complexity, but I haven't thought about it enough to have a more informed opinion.
19:30:33 <tidoust> ... To fit things in JSON objects, we have a bunch of things to do with that add complexity. Moving away from JSON might be needed.
19:31:11 <tidoust> ... I'm very keen to not having support based on screencasting because that still seems years away. High browser complexity for browsers and clients.
19:32:51 <tidoust> orkon: We have a stream of screeshots with a low FPS in CDP.
19:32:59 <AutomatedTester> q?
19:33:12 <tidoust> s/screeshots/screenshots
19:33:25 <sadym> q+
19:33:34 <tidoust> AutomatedTester: Where is the consensus here?
19:33:52 <jgraham> q+
19:33:55 <AutomatedTester> ack next
19:33:59 <AutomatedTester> ack next
19:34:00 <tidoust> sadym: No access to the file system is not a blocker, so we can proceed with that.
19:34:36 <tidoust> jgraham: If we do this, being able to say UnsupportedOperation for browsers who cannot support this seems a legitimate thing to do.
19:35:02 <AutomatedTester> topic: Stream IO (e.g. for network bodies)
19:35:10 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/959
19:35:30 <tidoust> jgraham: Natural progression from the previous topic!
19:36:05 <tidoust> ... Use cases include screencast, network response bodies.
19:36:30 <tidoust> ... From this one, we may want to read and write to streams to do real-time replacement of the body for the latter use case.
19:37:09 <tidoust> ... Polling access to the read streams. Base64 encoding because it's text.
19:37:21 <tidoust> ... Writing streams is kind of the opposite.
19:37:44 <tidoust> ... My hope here is that we can just generically connect this to the Stream API in the web platform.
19:38:04 <tidoust> ... Fetch has these objects internally but does not expose them, but that should still work.
19:38:25 <tidoust> ... You would end up with an IO handle, and read or write from that stream.
19:38:35 <sadym> q+
19:38:37 <tidoust> ... Do we have concerns that it tries to be too ambitious?
19:38:48 <AutomatedTester> ack next
19:39:12 <tidoust> sadym: What is the delta between the proposed branch and a proper DOM Streams?
19:39:39 <tidoust> jgraham: The branch is basically that it would map to DOM Streams. Just work in progress.
19:40:11 <tidoust> sadym: Do we have other ways to transfer a bunch of data through a WebSocket?
19:41:09 <tidoust> orkon: I think the answer is yes for the whole message, but not for parts of the message.
19:41:40 <tidoust> ... There's a binaryType but I think it just gives you a way to have Blob interface or a Buffer interface, not sure.
19:42:07 <AutomatedTester> q?
19:42:47 <sadym> q+
19:42:56 <AutomatedTester> ack next
19:43:07 <orkon> q+
19:43:12 <AutomatedTester> ack next
19:43:13 <tidoust> sadym: In general, I believe it makes sense to provide that API. It would be great to have.
19:43:46 <jgraham> jgraham has joined #webdriver
19:43:47 <tidoust> orkon: Just want to mention that in CDP we only have readable streams. Not writable streams. They're nice, probably lower priority.
19:44:05 <tidoust> ... Another use case is PDF generation that can be large and exceed WebSocket limits.
19:44:26 <AutomatedTester> q?
19:44:41 <jgraham> RRSAgent: make minutes
19:44:43 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/14-webdriver-minutes.html jgraham
19:46:16 <tidoust> jgraham: About WebSocket, binaryType does not help because of the use of JSON, which needs to be UTF8 encoded.
19:46:51 <tidoust> ... Or you need to spin up a specific WebSocket as part of your response.
19:47:08 <tidoust> AutomatedTester: It would be quite useful for cloud providers to do it that way.
19:47:16 <orkon> q+
19:47:20 <AutomatedTester> q?
19:47:22 <AutomatedTester> ack next
19:48:04 <tidoust> orkon: I was wondering about the cloud provider use case. In containers, there's usually a way to look into a container. I wonder if that could be a way to do quality streaming directly from the browser.
19:48:19 <tidoust> AutomatedTester: It can be, it becomes cumbersome depending on the OS.
19:48:44 <tidoust> ... Desktop and then mobile where things can be almost impossible.
19:49:13 <tidoust> ... 99.9% of our users are doing simple things. We wouldn't be automating someone streaming a video game for example.
19:49:38 <tidoust> ... If people want to check that a video plays, they really just need a few frames to check that playback runs properly.
19:50:19 <tidoust> AutomatedTester: I think the consensus is that we want this. Writable streams are lower priority.
19:52:06 <tidoust> AutomatedTester: Tomorrow, we'll be kicking things off again at 16:00 UTC. Note we have a few topics scheduled for after 18:00 UTC.
19:52:12 <tidoust> RRSAgent, draft minutes.
19:52:12 <RRSAgent> I'm logging. I don't understand 'draft minutes.', tidoust.  Try /msg RRSAgent help
19:52:15 <tidoust> RRSAgent, draft minutes
19:52:16 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/14-webdriver-minutes.html tidoust
19:57:03 <shs> shs has left #webdriver
22:26:27 <karlcow__> karlcow__ has joined #webdriver