Meeting minutes
<jgraham> RRSAgent: make minutes
Support overriding screen dimensions
github: w3c/
sasha: We support overriding the viewport but it does not affect the screen size, which would be useful for clients and end users.
… You cannot do it with BiDi yet.
… Should we add this? Automatically applied when we set the viewport? Another argument? Completely separate command?
sadym: The Window Management API spec provides not only the screen dimensions but also additional information that would be useful to use.
… It would be nice to collaborate with them on the emulation and specification. That would be useful for WPT as they currently have manual tests.
jgraham: It makes sense for me to have a completely different command here. Or for it to be different arguments to the command rather than repurposing the argument of the command.
sasha: If there's potential to have more arguments, it makes sense to have a different command.
… To cover different screen settings
sadym: It sounds like it falls perfectly under emulation.
orkon: I looked at the spec. I think that's cool. Screens have their own pixel ratio, additionally. It may make sense to revise devicePixelRatio for the screen specifically.
jgraham: To what extent it makes sense to do that across browsing contexts or user contexts. Different values may not make sense.
… I'm not sure. Maybe you can argue that you can have browsing contexts on different physical screens.
Allow for specifying schema in "proxy"
github: w3c/
sadym: We don't support a core feature supported in Chrome. You can proxy http over http, ssl over ssl, or socks over specific versions. But in Chrome, we can proxy http over https for example. That makes me propose a change in the API for the schema which allows schema to be provided for the proxy value.
… I wanted to get feedback.
jgraham: If it's supported in Gecko, it seems reasonable to be in WebDriver. It may be reasonable to have it in WebDriver even if it's not, provided that we can return something like "not supported".
sadym: It's kind of a breaking change due to where you specify the schema, but we can sort that out offline.
emulation.setScriptingEnabled (HTML part)
Pull request in WHATWG: whatwg/
sadym: The BiDi part has landed, but the HTML part has some friction. We need to get consensus on what we expect to happen. Do we expect attributes on elements to be available when scripting is disabled?
… Also microtasks in Promises. In HTML, these are things that currently don't work.
<sadym> Thisngs don't work in current version of the HTML spec: element.on..., finilizers, microtasks (.then)
<shs> Excellent channelling!
jgraham: At a really high level, what we want is how your browser would do when you disable scripting, first because that's easier to implement, but also because that's what we want users to be able to test.
… I don't know the detailed answers to these questions.
… Maybe we'll unearth implementation differences along the way.
orkon: It's also about what happens to WebDriver injected scripts, right?
… I think this has implications, as returning Promises might then hang.
… Maybe we should also look into what should also happen from a WebDriver Bidi spec perspective.
jgraham: In Firefox, the script you run in extensions and in the UI would keep running even if you disable JavaScript. I would assume the same thing ought to happen.
orkon: Content script, that's sandboxed realm. Is that the boundary?
jgraham: I would sort of expect these things to keep working. If you disable scripts and inject an extension that does scripting, I don't know.
jgraham: Conclusion seems we need to continue with investigation.
sadym: Will do the work on our side, would be nice to look into Firefox on your side!
browser.setDownloadBehavior
github: w3c/
sadym: [missed first issue]. In the spec, we don't emit the download event for links with a download attribute. This PR addresses both issues.
jdescottes: For setting the preferred download folder, is it fine to have a command for that? Is there prior art in automation protocols on ways to do this?
<sadym> first issue: we cannot specify the behavior (download to the specific path / to default path / cancel)
jgraham: I guess that's a question for CDP folks.
orkon: We do have this in CDP and in Puppeteer. I think there was a recently discussed issue in the implementation of BiDi.
… We have different defaults. That is configurable.
<orkon> https://
orkon: In CDP, it's a separate command.
jdescottes: Nothing in classic which relates to configuring downloads?
[No]
jgraham: At this point, we've ported pretty much all features from Classic.
jdescottes: I'll take another look at the PR.
… I didn't know the PR also addressed the issue about the download attribute, I'll look into it as well.
emulation.setNetworkConditions:offline
github: w3c/
sadym: Current version of spec is that no network emulation is pretty much airplane mode.
jgraham: I was definitely imagining something like "what if the network goes down at this point", rather than a clean network disconnection.
… What happens if you engage offline mode. What does the prior art look like? Closing connections gracefully? Or shutting them down?
orkon: We discussed this. If you go offline, usually it's not instant, you have timeouts on HTTP, TCP, etc. navigator.online does not report the status right away.
… What we discussed is that switching would only apply to new requests.
… This is a simpler model, and I don't see a strong use case for airplane mode where you emulate offline mode.
… You want to check that, e.g., your service worker picks up things correctly.
… It would be difficult to emulate the real circumstances for when you're going offline given the many ongoing connections that may be happening.
sadym: Emulate tunnel in the train vs. airplane is what we need to get consensus on, then.
jdescottes: The situation in Firefox is that there are two ways to get offline.
… Two inconsistent features, including one in dev tools.
… I still think that we should do more than preventing next request. Just failing requests on beforeRequestSent is not enough.
… Some applications may be relying on other signals to switch to offline mode.
… Also, this PR depends on two other PRs, do we want to wait until these two PRs are reviewed?
jgraham: In most testing scenarios, I agree that simplifying things is probably enough.
… I believe the current PR covers the needs.
… In the context of the scripting API, we've sometimes landed updates even when the background is broken when there are inter-dependencies. Sometimes, we need to go back and clean up the other PRs.
Blaze: Webkit uses this online/offline marker to switch mode.
… That should align well with this.
… I don't see any blocker.
Emit navigationStarted for links with a download attribute
github: w3c/
jdescottes: Lots of differences in the HTML spec regarding download. A link with a download attribute does not trigger a navigation event. It does not emit an event in Firefox and Chrome for now. Should we add a navigation id? Should we also emit navigationStarted event for all the links with a download attribute?
<jgraham> RRSAgent make minutes
orkon: We discussed with sadym. I think we should not emit a navigationStarted event. Instead, the navigation ID should be optional.
sadym: This is how I specified it in the second PR we discussed previously. Navigation download should end up with the same hook but in case of the attribute, it does not provide you with a navigation, so it's optional.
jdescottes: That sounds good to me. There is an issue on the HTML spec to align the download attribute with a regular navigation download. It's an old issue, 5 years old. Just keep in mind that this could change later on.
… Also a question of what users might expect. In Firefox, even if you go back, you cannot tell where the resource was coming from.
… Fine with the decision.
should browsingContext.close resolve early when promptUnload is true
github: w3c/
jdescottes: Coming from a discussion with Playwright. The browsercontext.close command with promptUnload set to true and you add a beforeUnload prompt, the command may never return before the prompt is handled, which may block your script.
sadym: We already do the suggested solution.
jgraham: I think it makes sense not to have commands that can block indefinitely, but it should be obvious to the client that it returned for some other reason than the browsing context was closed. If we can return the ID of the dialog, that would be fantastic and would allow clients to send additional commands.
Autofill trigger
github: w3c/
Yoav: Adding an autofill trigger, discussed at last TPAC. Help website trigger autofill and check it does the work for both addresses and cards.
… This is useful today for web sites to test autofill. Similarly useful for future proposals.
… Would love to get opinion from folks on the overall feature as well as on the specifics of the PR itself.
sadym: The PR looks generally good. My only concern is about what happens when the browser autofills. Not sure the spec is detailed enough. Otherwise, generally positive about this!
jgraham: I haven't looked at the updated PR. Being able to test autofill in general makes sense. I don't know if it's a top priority for us as we haven't heard feedback from lots of users, but no objection!
Yoav: On the spec front, I can see a specification that outlines how a browser should match the provided inputs. One potential thing that makes me hesitant about this is that this may not match how autofill is currently implemented in browsers. This should trigger autofill as browsers implement it, which is somewhat heuristics based.
… Specifying a step-by-step algorithm may not work, unless there are provisions for the heuristics.
orkon: We do have this functionality in Puppeteer, and it's similar to what is being proposed.
… Users report that it's useful to test if their website works with autofill.
… I also agree it's only useful if it tests the actual implementation of autofill.
… There are edge cases, such as when iframes are considered, and goal is for users to test under real conditions.
jgraham: It's useful to hear that there's demand for it.
… The way you would fill out the data, then load the page again, and ask the browser whether it has autofill data for this page. And then you would inspect which fields were filled out.
… That would be something you could standardize without trying to standardize specific heuristics.
bburg: Two parts in Safari. What type of form? And do we have data to fill it?
… It's rather opaque when we offer autofill or not. Some performance related considerations.
… There are all kinds of heuristics. Web sites do all sorts of things, including multiple form elements. We cannot rely on semantics only, there's a lot of logic and heuristics involved.
… We don't want to expose that complexity. We just want to expose the classification.
… We kind of need to define what we are testing specifically. What are we hoping to get out of it? The actual data we put in? A field type?
… Lots of questions on how you would be going up about that.
… Having some tests that would use this thing would be useful.
Yoav: We're not talking about login forms, only addresses and credid cards, which is potentially simpler or more complex.
… One thing we could do in terms of form classification is an error code [missed details].
bburg: It's still slippery.
Yoav: I would expect the browser to apply its heuristics on the address, and then the user would check whether the field was filled out as expected.
sadym: Apparently, autofill is split into 3 tasks: detecting the form (very implementation specific), checking the data, filling the form. This PR is about the third one. I would propose to split these 3 tasks separately.
jgraham: More discussion in the PR, then.