16:01:20 <RRSAgent> RRSAgent has joined #webdriver
16:01:24 <RRSAgent> logging to https://www.w3.org/2025/07/09-webdriver-irc
16:01:28 <Zakim> Zakim has joined #webdriver
16:02:04 <jgraham> Meeting: WebDriver-BiDi
16:02:20 <jgraham> Agenda: https://www.w3.org/wiki/WebDriver/2025-07-BiDi#Agenda
16:02:35 <jgraham> RRSAgent, make logs public
16:02:43 <jgraham> RRSAgent: make minutes
16:02:44 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/09-webdriver-minutes.html jgraham
16:03:00 <jgraham> present+
16:03:51 <jdescottes> present+
16:03:55 <tidoust> scribe+
16:04:00 <sasha> present+
16:04:02 <whimboo> present_
16:04:03 <sadym> present+
16:04:04 <whimboo> present+
16:04:09 <lauromoura> present+
16:04:29 <jgraham> Scribe: tidoust
16:04:33 <jgraham> Chair: jgraham
16:04:52 <Aish> Aish has joined #webdriver
16:04:54 <tidoust> Topic: Support UrlPattern for network interception
16:04:57 <jgraham> Topic: Support UrlPattern for network interception
16:05:09 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/919
16:05:57 <spectranaut_> spectranaut_ has joined #webdriver
16:06:04 <tidoust> Henrik: Polyfill in Chrome, custom implementation in Firefox. Idea is to rather change our spec and make use of UrlPattern.
16:06:07 <jgraham> q+
16:06:08 <tidoust> ... Any concern?
16:06:15 <jgraham> ack next
16:06:18 <tidoust> ack jgraham
16:06:37 <tidoust> jgraham: This was the intent right from the start but UrlPattern wasn't stable yet.
16:07:09 <tidoust> ... I know there are compatibility concerns though. How breaking would the change be?
16:07:39 <tidoust> ... Maybe asking Alex in the issue would be a good way to tell!
16:08:01 <tidoust> Topic: Extend "setLocaleOverride" command
16:08:02 <jgraham> Topic: Extend "setLocaleOverride" command
16:08:12 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/774
16:09:14 <sadym> q+
16:09:18 <tidoust> Alexandra: It would better to have a single command. There may be parameters to set.
16:09:19 <jimevans> jimevans has joined #webdriver
16:09:24 <jimevans> present+
16:09:29 <jgraham> ack next
16:10:09 <jgraham> q+
16:10:19 <tidoust> sadym: I don't mind. I started drafting a related command recently. My proposal is we land override and see how to extend locale with the user agent.
16:10:25 <jgraham> ack next
16:11:11 <tidoust> jgraham: In CDP, it bundles up setting the accept-language headers and various other bits. I was wondering about dependency with user-agent that I was missing.
16:11:25 <tidoust> sadym: It's more about getting the proper hints.
16:12:23 <tidoust> jgraham: We discussed a more generic mechanism. Setting extra HTTP headers would be a more generic approach in particular.
16:12:42 <tidoust> Maksim: Do we need we don't need anything specific for language?
16:13:11 <tidoust> jgraham: It depends on how we specify things. For Accept-language, it should override.
16:13:30 <tidoust> ... In some cases, it may make sense that we duplicate the headers. In some cases, it does not.
16:13:47 <tidoust> ... I'm broadly in favor of having a point in the spec that deals with locales.
16:13:55 <tidoust> s/locales/locale
16:14:24 <tidoust> Blaze: What if I ask a language that is nonsense?
16:14:48 <jgraham> q+
16:14:53 <tidoust> ... I want to specify at what level we're dealing with this. This may dictate how we go about this.
16:14:56 <jgraham> ack next
16:15:51 <tidoust> jgraham: My understanding is the use case is having a straightforward way to pretend to be a browser with a specific locale without having the entire OS configured to that locale and timezone.
16:16:16 <tidoust> ... I think it's just about having a relatively easy to override most of the web exposed information linked to a locale at the browser level.
16:16:29 <tidoust> s/easy/easy way/
16:16:54 <sasha> q+
16:16:56 <tidoust> Blaze: I guess my question is about delegation.
16:17:00 <sadym> q+
16:17:05 <jgraham> s/delegation/validation/
16:17:15 <jgraham> ack next
16:17:44 <tidoust> sasha: On the validation, we do have on the spec level the validation that the provided string is supposed to be match a valid language tag.
16:18:09 <jgraham> I think validation is a good reason for having a more specific endpoint for this vs just setExtraHeaders
16:18:16 <tidoust> ... Browser will only provide supported locales, and try to match the closest one to the requested one.
16:18:33 <tidoust> Blaze: Thanks for clarifying.
16:18:35 <jgraham> ack next
16:19:11 <tidoust> sadym: We can extend the validation with specifically supported locales by the browser if it would help somehow.
16:19:35 <tidoust> jgraham: That makes sense. I think that's a great argument for having a more specific endpoint for this.
16:19:50 <jgraham> Topic: Do we want to wontfix the "click and wait for navigation" entry from the BiDi roadmap planning doc?
16:21:21 <tidoust> Henrik: I compare our implementation in Firefox with the one in Chrome for "Click and wait for navigation". Is this still a requirement? Should BiDi not implement this but rather wait for the client to look at it?
16:21:31 <jimevans> q+
16:21:38 <tidoust> ... Otherwise, a 250ms delay gets introduced and that's quite a lot.
16:21:54 <jgraham> ack next
16:22:02 <tidoust> ... We need more feedback from David and Simon. I'm happy to wait until next meeting and continue the discussion in the GitHub issue.
16:22:28 <tidoust> jimevans: Personally, I can see ways that we can change the code of Selenium once we move to BiDi to sort of mimic the current classic behavior.
16:22:46 <jgraham> q+
16:22:54 <tidoust> ... I do know that waiting for a navigation following a click is something that many Selenium users expect.
16:23:13 <tidoust> ... They expect that the next statement does not run before navigation is "complete", whatever that means.
16:23:39 <tidoust> ... I know a fair number of Selenium users do rely on that behavior in any case.
16:24:05 <tidoust> ... I can take it back to Selenium steering committee and figure out whether that's something we may want to change.
16:24:07 <jgraham> ack next
16:24:39 <tidoust> jgraham: This behavior definitely makes sense in Classic. You need the browser to figure things out for you.
16:25:20 <tidoust> ... In the BiDi case, the browser does not really have more information. The user probably knows better whether a click is going to trigger a navigation or do something else.
16:25:31 <jimevans> q+
16:25:33 <tidoust> ... Having the client more in control in BiDi makes sense.
16:25:37 <jgraham> ack next
16:26:24 <whimboo> q+
16:26:48 <tidoust> jimevans: I agree that the client code would be the right place to take that decision. I just cannot decide from a Selenium perspective. From a technical perspective, I agree we should not have that in the spec. I need feedback from other Selenium project leads though.
16:26:54 <jgraham> ack next
16:27:54 <tidoust> henrik: If you do some random cases, you don't necessarily know what is going to cause a navigation. If you have an event listener attached to an element, there may be a delay before navigation takes place. It's unpredictable.
16:27:58 <jgraham> Agreed that you don't always know, just that sometimes you know, especially in test scenarios
16:27:59 <jimevans> q+
16:28:04 <jgraham> ack next
16:28:42 <tidoust> jimevans: If you wouldn't mind creating an issue, that would create a space to crystallize that discussion.
16:29:13 <jgraham> Topic:  Initial draft of `emulation.setDisableScriptingOverride`
16:29:21 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/746
16:30:05 <tidoust> sadym: I started to specify to disable scripting override. Do we want to enable JavaScript execution if the user explicity denied it. In CDP, that's not possible.
16:30:37 <tidoust> ... The question is for Selenium folks if they're aware of scenarios where user disabled scripting but we still want to enable it via the protocol.
16:30:40 <jgraham> q+
16:30:45 <jgraham> ack next
16:31:41 <jimevans> q+
16:31:59 <tidoust> jgraham: As a security barrier, it seems pretty thin. The fact that the code can already run whatever script it wants means that disabling it in some contexts does not give much protection.
16:32:25 <jgraham> ack next
16:32:30 <tidoust> ... Testing could benefit from the ability to enabling execution.
16:33:06 <tidoust> jimevans: From the Selenium side of things, the only data point that I really have are past requests for being able to execute a test with JavaScript disabled.
16:33:43 <tidoust> .... Using Classic, that was a non starter because some things depended on JS running in the browser, e.g., isDisplayed.
16:33:59 <sadym> q+
16:33:59 <tidoust> ... We've always told people they couldn't run things with JS disabled.
16:34:10 <jamesn> jamesn has joined #webdriver
16:34:35 <tidoust> ... If there's a way we could do that with BiDi, I think that some users will find that useful.
16:34:49 <jgraham> ack next
16:35:29 <tidoust> ... Personally, I'm a little agnostic about this particular feature. I don't know how much benefit it would be. If it's easy to do, maybe we should do it. I don't know the cost/benefit.
16:36:09 <tidoust> sadym: If we have a very strong signal from e.g., Selenium users, we could implement that, otherwise we're unlikely to do it.
16:36:56 <tidoust> ... The way I specified things, I added a hook in HTML which allows to bypass the check on JS being disabled.
16:37:06 <jgraham> q+
16:37:11 <jgraham> ack next
16:37:16 <sadym> q+
16:38:07 <tidoust> jgraham: On our side, I don't think not doing it is going to be a blocker. It just seems "silly" not to do it.
16:38:11 <jgraham> ack next
16:38:25 <tidoust> sadym: Another question was: top level navigables only or nested levels as well?
16:38:28 <jgraham> q+
16:38:32 <jgraham> ack next
16:39:37 <tidoust> jgraham: I don't know of use cases. Unlike with setViewport where it applies to top level, here there's no technical restriction.
16:39:58 <tidoust> ... Maybe we should do it in a way where we can extend the command later to work with non top level traversables.
16:40:26 <tidoust> ... Maybe by returning an error for the case we don't want to support today, and then later on return something if we want to extend.
16:40:42 <jgraham> Topic: Initial draft of `emulation.setUserAgentOverride`
16:40:49 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/448
16:41:33 <tidoust> sadym: It looks straightforward except one thing. The value is not scoped to something, so I attempted to tie it to a navigable or a browsing context.
16:41:40 <jgraham> q+
16:41:45 <jgraham> ack next
16:41:52 <tidoust> s/browsing context/user context
16:42:42 <tidoust> jgraham: Each request that originates from a window has a way to get to the navigable. We do that for requestNetworkInterception.
16:43:18 <tidoust> ... There are things where you can't quite figure out what the window is, e.g., Service Workers.
16:44:19 <jdescottes> https://www.w3.org/TR/webdriver-bidi/#get-navigable-for-request
16:44:45 <jdescottes> q+
16:45:08 <tidoust> ... We put a hook in Fetch that hooks into WebDriver BiDi to return the user agent. Instead of returning a constant, the hook should ask BiDi to return the appropriate user agent value for this request.
16:45:31 <jgraham> ack next
16:46:09 <tidoust> jdescottes: I just looked at the algorithm. We do hook from the Fetch spec as James mentioned. I think you should be able to build on that.
16:46:39 <tidoust> ... This algorithm might not be able to catch things from a worker, but I guess you can extend it. It was meant for things originating from a window. Feel free to update!
16:47:01 <jgraham> Topic: Add support for "default" value for "sameSite" cookie attribute in WebDriver Classic
16:47:10 <jgraham> github: Add support for "default" value for "sameSite" cookie attribute in WebDriver Classic
16:47:20 <jgraham> github: https://github.com/w3c/webdriver/issues/1908
16:48:18 <tidoust> sasha: We add the "default" value for "sameSite" cookie in BiDi because we had a situation where you could read cookies through document.cookie but not set them with the cookie API.
16:49:15 <tidoust> ... The question is whether we should do the same for Classic as well. The main question for me here is Classic is even more vague about cookies. Lax and Strict. But it also says that sameSite should be no.
16:49:38 <tidoust> ... I think Chrome for Classic works in this case. Maybe it would be acceptable to let browsers return values that work for them.
16:49:49 <jimevans> q+
16:49:58 <tidoust> ... Is it OK to introduce a change? Would it break something, for example for Selenium?
16:50:00 <jgraham> ack next
16:50:24 <tidoust> jimevans: That's not going to cause anything breaking from a Selenium perspective.
16:50:46 <jgraham> q+
16:50:46 <tidoust> ... We're still working on how to translate our cookie handling code in Selenium to use BiDi. Any change we make here, we can adapt to.
16:50:51 <jgraham> ack next
16:51:53 <tidoust> jgraham: In general, cookies have changed a lot recently and the Classic spec has not... It was written when cookies were slightly simpler. We didn't have the complexity that BiDi deals with now.
16:52:11 <jimevans> q+
16:52:17 <tidoust> ... How much time do we want to spend fixing that vs. getting people to move to BiDi is a good question.
16:52:19 <jgraham> ack jimevans
16:53:11 <tidoust> jimevans: I don't think that it's going to adversly affect Selenium even if we update the Classic spec. If spec and browser implementations change, then Selenium code will change to it.
16:53:36 <jgraham> RRSAgent: make minutes
16:53:37 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/09-webdriver-minutes.html jgraham
16:53:43 <tidoust> ... So no objection to changing Classic here.
16:53:45 <sasha> q+
16:54:03 <jgraham> ack next
16:54:10 <tidoust> ... Same question about how much time to spend on Classic vs. BiDi.
16:55:03 <tidoust> sasha: Maybe the way it works now is acceptable. You cannot set anymore the cookies with sameSite ... There will be no error, but the cookie cannot be set.
16:55:15 <tidoust> ... If it's an acceptable behavior for clients, that's fine.
16:55:51 <tidoust> jgraham: It the current situation leads to data loss, that may be a good motivation to fix things.
16:55:57 <jgraham> Topic: `emulation.setTimezoneOverride`
16:56:06 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/749
16:56:15 <tidoust> sadym: It's a call for action. Please take a look!
16:56:43 <jgraham> Topic: Allow errorText for `network.fetchError` to be implementation defined
16:56:51 <jgraham> topic: https://github.com/w3c/webdriver-bidi/issues/631
16:56:57 <jgraham> Topic: Allow errorText for `network.fetchError` to be implementation defined
16:57:03 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/631
16:57:56 <tidoust> jdescottes: Heads-up. We have a TODO in the spec for the network fetcher event. I looked about error texts. I couldn't find anything. I'm suggesting to lead this as implementation defined.
16:57:58 <tidoust> q+
16:58:08 <jgraham> ack next
16:58:26 <jgraham> Scribe: jgraham
16:58:55 <jdescottes> q+
16:59:02 <jgraham> tidoust: I18n review will ask about error text we're going to show to users, but it doesn't say anything about what language the text is in, whether it's ltr or rtl etc.
16:59:13 <jgraham> ack next
16:59:26 <jgraham> q+
16:59:44 <tidoust> jdescottes: In practice, all Firefox error messages should be in English, but that's indeed not a guarantee for all implementations.
17:00:26 <tidoust> jgraham: In practice, we assumed that these implementation defined texts are essentially static in code and in one language only.
17:00:54 <jgraham> ack next
17:00:57 <tidoust> ... However, if there's a request from i18n group to provide additional info in the responses, we can probably amend the responses to add the information.
17:01:16 <jgraham> RRSAgent: make minutes
17:01:17 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/09-webdriver-minutes.html jgraham
17:01:23 <jgraham> zakim, bye
17:01:23 <Zakim> leaving.  As of this point the attendees have been jgraham, jdescottes, sasha, sadym, whimboo, lauromoura, jimevans
17:01:23 <Zakim> Zakim has left #webdriver
17:01:37 <tidoust> present+
17:01:48 <tidoust> RRSAgent, make minutes
17:01:50 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/09-webdriver-minutes.html tidoust
17:02:12 <jgraham> RRSAgent, bye
17:02:12 <RRSAgent> I see no action items