Meeting minutes
<jgraham> RRSAgent: make minutes
<whimboo> present_
Support UrlPattern for network interception
Support UrlPattern for network interception
<jgraham> github: w3c/
Henrik: Polyfill in Chrome, custom implementation in Firefox. Idea is to rather change our spec and make use of UrlPattern.
… Any concern?
jgraham: This was the intent right from the start but UrlPattern wasn't stable yet.
… I know there are compatibility concerns though. How breaking would the change be?
… Maybe asking Alex in the issue would be a good way to tell!
Extend "setLocaleOverride" command
Extend "setLocaleOverride" command
<jgraham> github: w3c/
Alexandra: It would better to have a single command. There may be parameters to set.
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.
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.
sadym: It's more about getting the proper hints.
jgraham: We discussed a more generic mechanism. Setting extra HTTP headers would be a more generic approach in particular.
Maksim: Do we need we don't need anything specific for language?
jgraham: It depends on how we specify things. For Accept-language, it should override.
… In some cases, it may make sense that we duplicate the headers. In some cases, it does not.
… I'm broadly in favor of having a point in the spec that deals with locale.
Blaze: What if I ask a language that is nonsense?
… I want to specify at what level we're dealing with this. This may dictate how we go about this.
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.
… I think it's just about having a relatively easy way to override most of the web exposed information linked to a locale at the browser level.
Blaze: I guess my question is about validation.
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.
<jgraham> I think validation is a good reason for having a more specific endpoint for this vs just setExtraHeaders
sasha: Browser will only provide supported locales, and try to match the closest one to the requested one.
Blaze: Thanks for clarifying.
sadym: We can extend the validation with specifically supported locales by the browser if it would help somehow.
jgraham: That makes sense. I think that's a great argument for having a more specific endpoint for this.
Do we want to wontfix the "click and wait for navigation" entry from the BiDi roadmap planning doc?
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?
… Otherwise, a 250ms delay gets introduced and that's quite a lot.
… We need more feedback from David and Simon. I'm happy to wait until next meeting and continue the discussion in the GitHub issue.
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.
… I do know that waiting for a navigation following a click is something that many Selenium users expect.
… They expect that the next statement does not run before navigation is "complete", whatever that means.
… I know a fair number of Selenium users do rely on that behavior in any case.
… I can take it back to Selenium steering committee and figure out whether that's something we may want to change.
jgraham: This behavior definitely makes sense in Classic. You need the browser to figure things out for you.
… 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.
… Having the client more in control in BiDi makes sense.
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.
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.
<jgraham> Agreed that you don't always know, just that sometimes you know, especially in test scenarios
jimevans: If you wouldn't mind creating an issue, that would create a space to crystallize that discussion.
Initial draft of `emulation.setDisableScriptingOverride`
<jgraham> github: w3c/
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.
… 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.
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.
… Testing could benefit from the ability to enabling execution.
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.
… Using Classic, that was a non starter because some things depended on JS running in the browser, e.g., isDisplayed.
… We've always told people they couldn't run things with JS disabled.
… If there's a way we could do that with BiDi, I think that some users will find that useful.
… 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.
sadym: If we have a very strong signal from e.g., Selenium users, we could implement that, otherwise we're unlikely to do it.
… The way I specified things, I added a hook in HTML which allows to bypass the check on JS being disabled.
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.
sadym: Another question was: top level navigables only or nested levels as well?
jgraham: I don't know of use cases. Unlike with setViewport where it applies to top level, here there's no technical restriction.
… Maybe we should do it in a way where we can extend the command later to work with non top level traversables.
… 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.
Initial draft of `emulation.setUserAgentOverride`
<jgraham> github: w3c/
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 user context.
jgraham: Each request that originates from a window has a way to get to the navigable. We do that for requestNetworkInterception.
… There are things where you can't quite figure out what the window is, e.g., Service Workers.
<jdescottes> https://
jgraham: 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.
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.
… 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!
Add support for "default" value for "sameSite" cookie attribute in WebDriver Classic
<jgraham> github: Add support for "default" value for "sameSite" cookie attribute in WebDriver Classic
<jgraham> github: w3c/
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.
… 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.
… I think Chrome for Classic works in this case. Maybe it would be acceptable to let browsers return values that work for them.
… Is it OK to introduce a change? Would it break something, for example for Selenium?
jimevans: That's not going to cause anything breaking from a Selenium perspective.
… 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.
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.
… How much time do we want to spend fixing that vs. getting people to move to BiDi is a good question.
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.
<jgraham> RRSAgent: make minutes
jimevans: So no objection to changing Classic here.
… Same question about how much time to spend on Classic vs. BiDi.
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.
… If it's an acceptable behavior for clients, that's fine.
jgraham: It the current situation leads to data loss, that may be a good motivation to fix things.
`emulation.setTimezoneOverride`
<jgraham> github: w3c/
sadym: It's a call for action. Please take a look!
Allow errorText for `network.fetchError` to be implementation defined
w3c/webdriver-bidi#631
Allow errorText for `network.fetchError` to be implementation defined
<jgraham> github: w3c/
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.
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.
<tidoust> jdescottes: In practice, all Firefox error messages should be in English, but that's indeed not a guarantee for all implementations.
<tidoust> jgraham: In practice, we assumed that these implementation defined texts are essentially static in code and in one language only.
<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.
RRSAgent: make minutes