15:29:38 <RRSAgent> RRSAgent has joined #webdriver
15:29:42 <RRSAgent> logging to https://www.w3.org/2024/09/27-webdriver-irc
15:29:43 <Zakim> Zakim has joined #webdriver
15:30:42 <AutomatedTester> Chair: David Burns
15:30:42 <AutomatedTester> Agenda: https://www.w3.org/wiki/WebDriver/2024-09-TPAC
15:30:57 <AutomatedTester> Meeting: TPAC Browser Testing and Tools WG - Day 2
15:32:18 <AutomatedTester> rrsagent,  set  logs world-visible
15:32:22 <AutomatedTester> present+
15:32:46 <AutomatedTester> scribe: AutomatedTester
15:32:58 <AutomatedTester> scribe: David Burns
15:33:05 <AutomatedTester> scribenick: AutomatedTester
15:47:15 <whimboo> whimboo has joined #webdriver
15:49:42 <jimevans> jimevans has joined #webdriver
15:55:39 <sadym> present+
15:56:18 <gsnedders> gsnedders has joined #webdriver
16:02:10 <orkon> orkon has joined #webdriver
16:02:14 <jimevans> present+
16:02:28 <dmurph> dmurph has joined #webdriver
16:02:29 <orkon> present+
16:02:30 <simonstewart> simonstewart has joined #webdriver
16:02:30 <Westin> Westin has joined #webdriver
16:02:34 <whimboo> present+
16:02:38 <Westin> present+
16:02:43 <simonstewart> present+
16:02:47 <Christian> Christian has joined #webdriver
16:02:52 <sasha> sasha has joined #webdriver
16:03:01 <Yoav> Yoav has joined #webdriver
16:03:04 <jdescottes> jdescottes has joined #webdriver
16:03:08 <Christian> present+
16:03:09 <jdescottes> present+
16:03:10 <sasha> present+
16:03:25 <jgraham> jgraham has joined #webdriver
16:03:27 <Yoav> present+
16:05:24 <AutomatedTester> Topic: Autofill testing
16:05:42 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/pull/706
16:08:19 <AutomatedTester> martin: [Introduces himself, Yoav, and Christian]
16:09:41 <AutomatedTester> ... why is autofill important? 30% of guest checkouts use autofill and we see that there is a 41% increase of completion rate
16:11:06 <AutomatedTester> ...(describes use case on slide 4 of the slides)
16:11:53 <jgraham> present+
16:11:59 <jgraham> scribe+
16:12:38 <jgraham> martin: complex case is where we change fields e.g for different countries with different address formats
16:14:00 <jgraham> martin: Different browsers handle this case differently at the moment. In some cases we get prefilled fields that's different to what users would expect
16:14:27 <jgraham> martin: this is a huge problem for our buyers. We need to implement workarounds to avoid autofill doing something unexpected.
16:14:56 <jgraham> martin: In the spec a form can define scopes e.g. shipping address vs billing address.
16:16:06 <jgraham> martin: we expect to only prefill one scope at a time, e.g. not auto-fill the shipping address when only trying to auto-fill the billing address
16:16:36 <jgraham> martin: We'd like to be able to write wpt to get interop here
16:17:04 <jgraham> martin: Simple tests where we can define a form, call a testdriver function, then fill a form given some autofill data.
16:17:14 <jgraham> martin: This is the proposal
16:18:16 <jgraham> martin: We have a webdriver bidi PR open. It's been approved by Chrome. We have requests for positions from Mozilla and WebKit.
16:18:29 <davehunt> davehunt has joined #webdriver
16:18:37 <jgraham> martin: We also have proposed draft tests. We've changed the proposal recently, and the tests haven't been updated yet.
16:19:21 <jgraham> martin [shows the filesystem layout of the proposed tests and what they cover]
16:19:31 <jgraham> s/martin/martin:/
16:19:56 <jgraham> martin: [shows the proposed specification from the PR]
16:20:20 <jgraham> martin: Pass in a form element, and the data that's assumed to be stored in autofill.
16:20:27 <jgraham> RRSAgent, make minutes
16:20:28 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html jgraham
16:20:38 <gsnedders> gsnedders has joined #webdriver
16:20:57 <AutomatedTester> q?
16:21:12 <gsnedders> present+
16:21:38 <jgraham> martin: Autofill may not be fully specified, how to deal with that? We think this would help to make it more specified. In terms of browser vendor flexibility e.g. passwords, there's definitely some possibility to add flexibility e.g. making tests optional. We should at least get the majority of the cases tested somehow.
16:21:42 <AutomatedTester> q+
16:21:49 <jgraham> ack AutomatedTester
16:22:08 <jgraham> AutomatedTester: Can we get a link to the presentation?
16:22:39 <jgraham> [this will be forthcoming]
16:23:04 <sadym> q+
16:23:33 <jgraham> AutomatedTester: Is this proposal to simplify things rather than people using send keys to fill the form? I don't quite understand the testing use case.
16:24:25 <jgraham> simonstewart: WebDriver has a series of mechanisms for interacting. For a user you start typing and it pops up an autocomplete will the fill options. Why is this different?
16:24:42 <jgraham> martin: How would you define what the state of autofill is?
16:24:55 <Yoav> https://drive.google.com/file/d/18HpZ8uNWV4AwzzODkoSERKAL5kUp6AJE/view?usp=sharing
16:25:40 <jgraham> gsnedders: You can't interact with the actual autofill UI with sendKeys. You need a way to interact with the prompt.
16:25:57 <jgraham> AutomatedTester: I was imagining it to be like file upload.
16:25:58 <Yoav> q+
16:26:00 <simonstewart> q?
16:26:03 <jgraham> ack sadym
16:26:48 <jgraham> sadym: The proposed API covers not just address, but any kind of field. You can provide any set of fields including ones not in the form. What's expected?
16:27:45 <jgraham> martin: The idea is that you're actually passing in a form where the autofill elements are specified, and then you're setting the state of the autofill memory. The trigger should cause the browser to activate the provided autofill.
16:27:45 <davehunt> davehunt has joined #webdriver
16:27:56 <jgraham> sadym: So it's performing two different actions?
16:28:17 <orkon> q+
16:28:28 <jgraham> martin: Yes We thought about having a set autofill state command, but this requires state and that could leak between tests.
16:28:36 <jgraham> ack next
16:28:36 <AutomatedTester> ack Yoav
16:29:28 <gsnedders> q+
16:29:47 <AutomatedTester> ack orkon
16:29:47 <jgraham> Yoav: Yes, the PR does two actions; filling the autofill store with data and then triggering. We could pivot to using sendkeys for the trigger part, but speccing the actually filled values requires jumping through some hoops. Figuring out if the autofill was triggered at all is hard. We need to inspect the data in a way that isn't UI related.
16:29:58 <mmocny> mmocny has joined #webdriver
16:30:03 <mmocny> +q
16:30:28 <karlcow> karlcow has joined #webdriver
16:30:31 <simonstewart> q+
16:31:14 <jgraham> orkon: I read the proposal. I think it looks good and similar to something we have in CDP. This command doesn't actually modify the autofill state. It acts as a data provider for autofill. It avoids the problem of whether the user can actually access the autofill data; you don't need to worry about how the data gets into the autofill provider.
16:31:21 <mmocny> q-
16:31:28 <sadym> q+
16:31:43 <jgraham> orkon: You can test that given the data is available to the browser that it's applied correctly to the form. I think I'm in favour.
16:32:06 <AutomatedTester> ack gsnedders
16:32:13 <jgraham> martin: We don't want to test where we get the data from but what happens when we have it.
16:32:53 <mmocny> q+
16:33:36 <Yoav> q+
16:34:16 <jgraham> gsnedders: Feedback from WebKit. One concern is that there are a reasonable number of websites who view autofill adversarial. Adding testing API might make it easy for them to block autofill, which doesn't follow priority of constituencies. That gives us reason to be hesitant in case authors try to default autofill. Browsers are already applying
16:34:16 <jgraham> additional heuristics to help users.
16:35:19 <jgraham> gsnedders: When I looked at the earlier PRs, the trigger was on an input element rather than a form. If you're tying you get the prompt on a specific input element, but other fields will be filled. I'm not confident that autofill is form-scoped. We may fill into other forms.
16:35:32 <jgraham> gsnedders: That's needed for some websites.
16:35:47 <orkon> q+
16:35:59 <jgraham> gsnedders: There's the HTML notion of form associated elements distinct from the DOM tree.
16:36:53 <jgraham> gsnedders: Given the conflict between users and authors here, we don't want to over-specify this, especially in cases where there aren't auto-complete attributes.
16:37:25 <jgraham> martin: Can you elaborate on blocking autofill?
16:38:00 <jgraham> gsnedders: e.g. banks might try to avoid users being able to save or autofill passwords because they consider that a security feature.
16:38:13 <simonstewart> q-
16:38:15 <jgraham> martin: Could the just not specify the autocomplete attribute?
16:38:31 <jgraham> gsnedders: Browsers may still offer autocomplete
16:38:36 <gsnedders> gsnedders has joined #webdriver
16:38:47 <jgraham> martin: What about just addresses rather than also considering passwords?
16:39:17 <jgraham> gsnedders: It's less of a problem, but where there are limited autocomplete attributes we can end up doing things where it's not completely apparent. But passwords are the worst case.
16:39:50 <jgraham> mmocny: You could write a wpt that tries to craft a form that tries to break the autocomplete field.
16:40:11 <jgraham> mmocny: Do we need a form target or should it be at the page level? Is that necessary?
16:40:21 <AutomatedTester> q?
16:40:27 <jgraham> martin: It makes the test easy to read. Y
16:40:50 <jgraham> mmocny: It seems like the user might want to test a page with multiple forms
16:41:09 <gsnedders> RRSAgent, make minutes
16:41:10 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html gsnedders
16:41:25 <jgraham> simonstewart: You should pass in a specific input element you want it to trigger on
16:41:52 <jgraham> martin: Yes, and assume that the user has focused that field.
16:42:21 <jgraham> simonstewart: You locate the node and don't use focus.
16:42:49 <AutomatedTester> ack sadym
16:42:49 <jgraham> ack next
16:42:59 <davehunt> davehunt has joined #webdriver
16:43:04 <jgraham> qq+ mmocny
16:43:05 <AutomatedTester> qq+ mmocny
16:43:46 <AutomatedTester> ack mmocny
16:43:46 <Zakim> mmocny, you wanted to react to mmocny
16:43:53 <simonstewart> q+
16:44:16 <jgraham> sadym: I think it misses an important part of saving the state. There's no guarantee that the field would have been saved in the state. Would it be enough to just have the part where you trigger the autofill assuming the data is already saved?
16:44:35 <jgraham> martin: How would you make the browser aware that the autofill memory has specific data?
16:45:03 <jgraham> sadym: With a specific save method. That was the original proposal, why did it change?
16:45:12 <simonstewart> qq+
16:45:37 <jgraham> Yoav: We want to test that if we have a given state. Another test could be to save a fake state e.g. put data in a form and check that the data saved is the correct data
16:46:20 <jgraham> Christian: One reason we changed it is that this should be transient information. Prefilling the autofill storage makes it more complicated if you have to navigate between many possible entries.
16:46:43 <jimevans> q?
16:46:43 <AutomatedTester> ack simonstewart
16:46:47 <Zakim> simonstewart, you wanted to react to mmocny
16:47:06 <jdescottes> jdescottes has joined #webdriver
16:47:31 <jgraham> simonstewart: You save autofill data, then get a handle back to that data. You then use that handle to clear the state later, and also select the set of autofill data you want to use for this specific form element.
16:48:04 <jgraham> simonstewart: That would give you the ability to clean up, but also allow checking that the right data is saved
16:48:39 <jgraham> martin: Would we have to test both storage and autofill together, or could we still separate out those tests? We'd like to separate those things
16:48:56 <jgraham> simonstewart: We could also have an event when things are saved to the autofill database.
16:49:13 <AutomatedTester> ack mmocny
16:49:13 <Zakim> mmocny, you wanted to react to mmocny
16:50:53 <jimevans> q+
16:51:02 <simonstewart> q-
16:51:06 <AutomatedTester> ack Yoav
16:51:24 <orkon> q-
16:51:24 <jgraham> mmocny: The use case in the video where the form fields changed seemed to require two autocompletes to be triggered. Does the proposal allow that? Presumably the expectation is that the browser triggers autofill itself again, but I'm not sure that a single trigger command is enough to achieve what you want. Setting up state and sending keys like a
16:51:25 <jgraham> user would be a better pattern. The current proposal bypasses some of the actual user flow and so might pass more often than a real browser would.
16:52:36 <AutomatedTester> ack jimevans
16:52:37 <jgraham> Yoav: To the point about the adverserial nature of some autofill fields, I think we could carve out something to allow browsers to do whatever they need to do to protect their users. Maybe one way to achieve that is to make this just address related. Would that address the concerns?
16:52:43 <jgraham> gsnedders: I'd need to ask others.
16:53:58 <sadym> q+
16:54:07 <jgraham> jimevans: It sounds like you want to validate that data was autofilled in a specific way when triggered by a user's action. In the bidi case you might want to consider an event that the browser sends back that says that autofill happened or is about to happen.
16:54:29 <jgraham> mmocny: For testing or as a web api?
16:54:42 <orkon> q+
16:54:51 <jgraham> jimevans: For testing. You want the test to react to what the browser has done. otherwise there could be a race condition.
16:54:58 <spectranaut_> spectranaut_ has joined #webdriver
16:55:11 <jgraham> martin: We react to the event that says it's happened.
16:55:45 <jgraham> jimevans: You could maybe have the event tell you which fields were filled in, but that may not be possible. Just a notification would give the tests the ability to validate the autofill operation.
16:55:51 <simonstewart> q+
16:56:03 <jgraham> Yoav: Right now people can poll the CSS, but an event would be better.
16:56:18 <gsnedders> q+ to ask about latency with events
16:57:54 <AutomatedTester> ack sadym
16:58:08 <jgraham> Zakim, close the queue
16:58:08 <Zakim> ok, jgraham, the speaker queue is closed
16:58:32 <simonstewart> q-
17:00:01 <jgraham> sadym: First question is how well the browser behaviour is specified for autofill? Otherwise it's just do what you want and hope they match. I'm not sure we need an event if there's a command that can return once the autofill is completed. I don't see a scenario where the autofill is initiated by anything other than the command. Also, do you
17:00:01 <jgraham> consider scenarios where we want to prevent someone from breaking the user experience, for example the examples that gsnedders gave earlier?
17:00:36 <jgraham> martin: Not sure if it's sufficiently well standardised, there's room for interpretation. Tests would make it clearer.
17:01:02 <jgraham> Yoav: For the testdriver part I don't think we need to tighten the spec. But for wpt we would.
17:01:19 <alice> alice has joined #webdriver
17:01:26 <jgraham> sadym: In the proposal it currently says "do any other UA specific autofill steps"
17:01:35 <ZoeBijl> ZoeBijl has joined #webdriver
17:01:41 <jgraham> Yoav: If we need to define what it means to trigger autofill.
17:01:43 <AutomatedTester> q?
17:01:48 <jgraham> sadym: I think it's a good first step.
17:01:50 <AutomatedTester> ack orkon
17:02:05 <ZoeBijl> present+
17:02:24 <alice> present+
17:03:13 <spectranaut_> present+ valerie_young
17:03:50 <jgraham> orkon: I also think an event is not necessary for this API. The command should wait for the operation to complete. The event might be useful if we need to detect autofill done by the user manually. If we want to go back to the save operation, we need to think about the browser state and that would need to be defined. I think you could argue that
17:03:50 <jgraham> other BiDI features could also be used in a user-hostile way. I think autofill is generally a positive thing. Would be good to know how many websites are trying to disable it. I think it's maybe not so many, especially for addresses.
17:04:00 <AutomatedTester> ack gsnedders
17:04:00 <Zakim> gsnedders, you wanted to ask about latency with events
17:06:33 <jamesn> jamesn has joined #webdriver
17:06:39 <jgraham> gsnedders: On a desktop OS you're typically typing something, and in the middle of those actions the event will happen. I think we're assuming that there's a single value store for each possible key. You can imagine typing something and you get an event indicating that something could be autofilled, but you've typed something that means that the
17:06:39 <jgraham> autofill options have changed, so the data is stale. I think events are closer to how this actually works in the browser, but it's not ideal. On mobile you might have a separate autofill prompt. I don't know which option is actually better here.
17:06:42 <simonstewart> q?
17:07:49 <jgraham> mmocny: The proposal on the screen was hoping to be a nice clean wrapper. Breaking all those pieces up to give more control would be a different proposal. You wouldn't have a single state per input.
17:08:09 <jgraham> Yoav: If you want more finegrained control you'd need a low level and high level commands
17:08:23 <jgraham> mmocny: The browser itself would still need to clear the state.
17:09:09 <jgraham> Yoav: This was useful. It would be useful to get responses to the open standards positions
17:09:12 <nathan> nathan has joined #webdriver
17:09:17 <jgraham> Zakim. open the queue
17:09:21 <spectranaut_> slides: https://notes.igalia.com/p/UCAZ3KYIo#/
17:09:22 <jgraham> Zakim, open the queue
17:09:22 <Zakim> ok, jgraham, the speaker queue is open
17:09:29 <Jamie> Jamie has joined #webdriver
17:09:39 <simonstewart> scribe+
17:09:48 <jgraham> RRSAgent, make minutes
17:09:50 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html jgraham
17:10:20 <Adam_Page> Adam_Page has joined #webdriver
17:10:42 <simonstewart> Topic: Accessibility Platform API testing in WPT
17:10:47 <Jem> Jem has joined #webdriver
17:10:53 <spectranaut_> slides: https://notes.igalia.com/p/UCAZ3KYIo#/
17:11:14 <simonstewart> spectranaut_: <talks through presentation>
17:11:42 <simonstewart> spectranaut_: I hope that everyone has seen the RFC, and we wanted to outline the "few" "small" technical puzzles we need to solve to run the tests in WPT
17:11:51 <alice> RFC: https://github.com/web-platform-tests/rfcs/pull/204
17:12:06 <simonstewart> spectranaut_: we've been calling the project "acacia" but the name doesn't appear in the code at the moment
17:12:39 <ChrisCuellar> ChrisCuellar has joined #webdriver
17:12:44 <simonstewart> alice: In the ARIA group we define mappings for assistive APIs to query.
17:13:04 <simonstewart> alice: Each OS has different ways of communicating with the assisstive technologies
17:13:05 <Jem> present+ JaeunJemmaKu
17:13:31 <simonstewart> alice: in webdriver there's already ways to query the computed accessibility tree
17:13:56 <simonstewart> alice: we then transform the computed accessibility tree, which is done differently per platform
17:14:20 <simonstewart> alice: we want to be able to query the transformed tree like the assistive technologies do
17:14:51 <simonstewart> alice: that transformation is subject to a standard maintained by the ARIA WG. One for attributes, one for html, one for svg, mathml, and maybe css
17:14:56 <jcraig> Data viz graphic slide direct link: https://notes.igalia.com/p/UCAZ3KYIo#/2
17:15:04 <simonstewart> alice: we want to test those standards the way we test other standards
17:15:19 <simonstewart> alice: <shows slide with different platform APIs>
17:15:50 <simonstewart> spectranaut_: it's a little complicated because there isn't a 1:1 mapping between platforms and platform APIs
17:16:44 <simonstewart> alice: the demo of this tests the computed role of element with aria role of "blockquote". Ultimately tests the platform API
17:17:00 <hdv> hdv has joined #webdriver
17:17:17 <simonstewart> spectranaut_: basically, all the functionality is there to query more accessibility APIs on each platform, but it's not all been implemented
17:17:18 <hdv> present+
17:17:23 <simonstewart> alice: each of the APIs has Python bindings available
17:17:25 <simonstewart> alive
17:17:28 <AutomatedTester> q?
17:17:44 <simonstewart> alice: we can use those bindings directly in the WPT code
17:18:14 <simonstewart> alice: we would like help taking from a proof of concept to something everyone is happy with running in the WPT
17:18:35 <simonstewart> alice: I've linked to the RFC, but there's a lot of things in there
17:18:40 <Jamie> s/computed/Linux API/
17:18:46 <simonstewart> spectranaut_: we have specific questions
17:18:52 <AutomatedTester> q?
17:19:16 <Jamie> present+
17:19:40 <simonstewart> spectranaut_: we need to get the browser process ID in order to find the browser through the accessibility APIs.
17:19:48 <simonstewart> spectranaut_: most drivers don't expose the PID
17:20:11 <AutomatedTester> q+
17:20:41 <simonstewart> spectranaut_: there are two ways to get the PID from webdriver. 1: update the webdriver spec to say that the PID should be returned by New Session, or 2: go to each browser and ask for the PID to come back in each extension.
17:20:45 <jgraham> q+
17:20:52 <simonstewart> ack next
17:21:04 <Jem> q?
17:21:16 <simonstewart> AutomatedTester: when you say "browser process", do you mean the parent process?
17:21:24 <simonstewart> spectranaut_: yes, just the parent process
17:21:30 <simonstewart> ack next
17:21:49 <TylerWilcock> TylerWilcock has joined #webdriver
17:21:55 <simonstewart> jgraham: I think for this use case a capability is fine because the PID should be stable.
17:22:16 <simonstewart> jgraham: there are lots of cases where the PID is meaningless (eg. browser on a different machine)
17:22:47 <simonstewart> jgraham: it's tricky to come up with a general solution, since when we start the session, we don't know where the browser is
17:23:51 <simonstewart> simonstewart: <gives examples of how we don't know where sessions are>
17:24:15 <AutomatedTester> q+
17:24:21 <simonstewart> spectranaut_: not sure what firefox does, but in the chrome code I'm only returning the PID of the desktop browser
17:24:24 <simonstewart> q+
17:24:39 <simonstewart> spectranaut_: is accidentally returning the PID a problem
17:24:57 <jgraham> qq+
17:25:01 <simonstewart> alice: we would need to restrict running those tests to being certain we're on the same machine
17:25:19 <simonstewart> spectranaut_: we can only test the accessibility API if it's on the same machine
17:25:42 <simonstewart> spectranaut_: we can check the name of the browser against the PID to see if it's what we expect
17:25:45 <simonstewart> ack next
17:25:46 <Zakim> jgraham, you wanted to react to jgraham
17:25:47 <gsnedders> q?
17:26:10 <simonstewart> jgraham: I can't remember what geckodriver does. But if you launch the browser, you likely know you're on the same machine
17:26:32 <simonstewart> jgraham: you could just ask the browser what the PID is, and in that case you may not know where the browser is
17:26:47 <Jamie> q+ to ask whether we could return an opaque accessibility specific connection address or something like that
17:26:58 <simonstewart> jgraham: because your use case depends on everything being on the same machine, then worrying about the location of the browser seems like an unnecessary rathole
17:27:12 <simonstewart> ack next
17:28:10 <simonstewart> AutomatedTester: adding to what jgraham is saying, generally how most people hit these situations with remote endpoints (eg. through BrowserStack or Docker), even when the PID is returned is one on a different machine, then if you're always on the same machine, I'd just carry on
17:28:22 <simonstewart> q-
17:28:26 <simonstewart> ack next
17:28:27 <Zakim> Jamie, you wanted to ask whether we could return an opaque accessibility specific connection address or something like that
17:28:59 <simonstewart> Jamie: I was just wondering if there's any use in having an "accessibility connection address", which would be opaque, but not necessarily be a PID
17:29:22 <simonstewart> Jamie: I don't have specific thoughts about how this would work, but Acacia is the only thing that's interested in it
17:29:39 <simonstewart> Jamie: would allow for different use-cases we can't currently support
17:29:40 <jgraham> (I note that the Firefox implementation just uses the PID on whatever machine it's running on)
17:29:43 <simonstewart> alice: I like that idea
17:29:56 <simonstewart> Jamie: I was thinking it might be something returned by webdriver.
17:30:16 <AutomatedTester> q?
17:30:18 <simonstewart> alice: you'd just poke that ID through to the accessibility API?
17:30:32 <simonstewart> spectranaut_: the next question is about python dependencies
17:30:38 <jgraham> q+
17:31:07 <simonstewart> spectranaut_: I don't know how to include those for WPT users. One way would be to add them to the top-level requirements. Maybe that's fine, even if it's just for a couple of tests
17:31:12 <AutomatedTester> slides: https://notes.igalia.com/p/UCAZ3KYIo#/
17:31:35 <simonstewart> spectranaut_: I did notice the concept of conditional requirements, and you can run wpt with a flag, but that flag likely won't be used anywhere else in the code
17:31:44 <gsnedders> q?
17:31:48 <simonstewart> spectranaut_: I'd like to know who manages the data collection for wpt.fyi
17:32:03 <simonstewart> jgraham: <itches to give answers>
17:32:04 <AutomatedTester> ack jgraham
17:32:06 <simonstewart> jgraham: yes
17:32:17 <simonstewart> jgraham: are these binary or pure python deps?
17:32:19 <gsnedders> q+
17:32:20 <simonstewart> spectranaut_: I'm not sure
17:32:34 <simonstewart> alice: at least the macOS ones are wrapping C
17:32:51 <simonstewart> jgraham: it's likely that they're binary deps because then that makes things complicated
17:33:08 <Jamie> On Windows, comtypes only needs ctypes, which is part of Python stdlib
17:33:19 <simonstewart> jgraham: what we normally do with WPT is we vendor the dependencies into the tree since that makes it easier to integrate with vendor CI systems
17:33:54 <simonstewart> jgraham: because dealing with C in vendor things is complicated, we have a flag to ensure that the deps are available
17:34:01 <AutomatedTester> q?
17:34:09 <simonstewart> jgraham: it's not a great solution, but that's likely the right path to follow here
17:34:22 <simonstewart> jgraham: you'll end up with a specific requirements file to support that
17:34:28 <simonstewart> alice: what's the best place to follow up?
17:34:38 <simonstewart> jgraham: <scribe misses the answer>
17:34:47 <simonstewart> jgraham: wpt.fyi is updated by CI
17:35:20 <Jem> so which option we are leaning to among three?
17:35:20 <simonstewart> jgraham: in the repo we have the configuration of tests runs we execute, and we can enable those.
17:35:30 <simonstewart> jgraham: just want to avoid landing a patch that suddenly causes binary deps to be required
17:35:34 <gsnedders> s/<scribe misses the answer>/the Matrix channel, #wpt:matrix.org/
17:35:58 <simonstewart> jgraham: <discusses how to optionally run tests>
17:36:12 <simonstewart> q?
17:36:13 <AutomatedTester> q?
17:36:21 <AutomatedTester> ack gsnedders
17:36:29 <simonstewart> gsnedders: Everyone loves to hear me talk
17:36:57 <simonstewart> gsnedders: one of the problems has historically been that some of the dependencies required to build a C extension was not always the right version of the right dep for things to compile
17:37:15 <simonstewart> gsnedders: in cases where building the extension becomes complicated things become more fraught.
17:37:41 <simonstewart> gsnedders: it may be okay, since this is likely on the platform already, but there are vendors in the room who may want to run the tests on pre-release versions of OSs
17:38:30 <simonstewart8> simonstewart8 has joined #webdriver
17:38:34 <simonstewart8> present+
17:38:35 <jgraham> (/me notes that python now has the ability to build wheels with a stable ABI)
17:38:36 <simonstewart8> scribe+
17:38:50 <simonstewart8> gsnedders: we'd need different deps per OS
17:39:02 <simonstewart8> gsnedders: that can be described in the requirements files. It can be done
17:39:44 <simonstewart8> spectranaut_: I guess I would say that the complexity can be kicked down the road if we don't expect vendors to run these yet
17:39:45 <gsnedders> (/me notes that nobody uses the stable ABI)
17:39:55 <simonstewart8> jgraham: maybe take this to a different venue later
17:40:33 <simonstewart8> 20 minute break
17:59:01 <simonstewart> simonstewart has joined #webdriver
17:59:24 <jimevans> jimevans has joined #webdriver
17:59:45 <jgraham> jgraham has joined #webdriver
17:59:59 <davehunt> davehunt has joined #webdriver
18:00:03 <jgraham> RRSAgent, make minutes
18:00:04 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html jgraham
18:02:09 <davehunt> davehunt has joined #webdriver
18:02:55 <Adam_Page> Adam_Page has joined #webdriver
18:03:05 <ChrisCuellar> ChrisCuellar has joined #webdriver
18:03:55 <davehunt> scribe+
18:04:21 <ZoeBijl> RRSAgent, make minutes
18:04:22 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html ZoeBijl
18:05:27 <nathan> nathan has joined #webdriver
18:06:17 <jgraham> q+
18:06:52 <davehunt> Ideally in the long term we'll be able to see by looking at the test results you'll see the correct number of assertions per platform / column
18:07:14 <ZoeBijl> s/Ideally/spectranaut_: Ideally/
18:07:53 <davehunt> spectranaut_: We would like some kind of "non applicable" concept
18:08:09 <AutomatedTester> q?
18:08:17 <davehunt> spectranaut_: Non-applicable or skipped concept in the test harness
18:08:48 <davehunt> Maybe there's a way we can mark this in wpt-metadata per subtest?
18:08:50 <AutomatedTester> ack jgraham
18:09:06 <ZoeBijl> s/Maybe/jcraig: Maybe/
18:09:08 <davehunt> jgraham: This is all possible. We can just make it run the subtests that are relevant to the configuration.
18:09:48 <davehunt> jgraham: This feels very solvable.
18:10:27 <davehunt> spectranaut_: We send the test assertions back for each accessibility API. If there's no results then we know the test is not relevant.
18:10:58 <davehunt> jgraham: When you start the run you should have some way of knowing what you want/expect to run.
18:11:52 <jgraham> q+
18:12:15 <davehunt> We talked about needing to test accessibilty code that's typically not run. It needs to be turned on, and it can be tricky to turn it back off. We would like tests in a directory to have their own browser instance.
18:12:28 <AutomatedTester> ack jgraham
18:12:45 <davehunt> jgraham: This is a solved problem. We can help.
18:12:54 <ZoeBijl> s/We talked/alice: We talked/
18:13:31 <davehunt> Is someone willing to be a contact person to help with WPT accessibility tests?
18:13:59 <davehunt> jgraham: Yes. Asking questions in the Matrix channel is good for async questions.
18:15:03 <davehunt> jgraham: There are a couple of people in Panos' team, also maxim(sp?) that could help
18:15:31 <AutomatedTester> q?
18:16:11 <davehunt> spectranaut_: The PR is a proof of concept, but appreciate someone to look over it. Right now it's on the Igalia fork
18:16:12 <alice> POC PR: https://github.com/Igalia/wpt/pull/2
18:16:30 <davehunt> jgraham: Suggest moving PR to wpt repo as a non-draft
18:17:23 <davehunt> spectranaut_: that's all of our questions, thank you
18:18:26 <davehunt> jcraig: would it be helpful to have kyle and/or sam sneddon to review?
18:19:27 <Matt_King> Matt_King has joined #webdriver
18:19:53 <davehunt> topic: Accessibility module for WebDriver BiDi
18:20:05 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/443
18:20:11 <jgraham> q?
18:20:50 <davehunt> orkon: Since last year we have the ability to locate DOM elements by accessibility attributes
18:21:14 <davehunt> orkon: Still not supported is getting snapshots of the accessibility tree
18:21:45 <davehunt> whimboo: I added this as it was a request from Playwright
18:22:57 <orkon> q+
18:23:04 <simonstewart> q?
18:23:07 <jcraig> q+
18:23:07 <jgraham> q+
18:23:19 <Jamie> q+
18:23:37 <davehunt> jimevans: We've already done the location of nodes. Being able to get the snapshot would be useful to me
18:23:47 <simonstewart> q+
18:23:47 <AutomatedTester> ack orkon
18:24:09 <jcraig> q+ to ask the need for the tree, since the implmentations will be different across WPT tests.
18:24:24 <jgraham> q-
18:24:27 <davehunt> orkon: We can't implement because there's no agreement yet on what the accessibility tree looks like
18:24:39 <jcraig> ack jcraig
18:24:40 <Zakim> jcraig, you wanted to ask the need for the tree, since the implmentations will be different across WPT tests.
18:24:47 <simonstewart> q-
18:25:21 <whimboo> orkon: you were right. the interop 2024 initiative was the reason
18:25:49 <davehunt> jcraig: Lot of accessibility automation stacks being worked on. WPT tests currently exists entirely in the browser.
18:26:04 <jgraham> q+
18:26:19 <AutomatedTester> q?
18:27:21 <davehunt> jcraig: We have an investigation to implement a tree dump. There's going to be different trees. I'd like to understand more about the needs are for getting the tree.
18:27:50 <davehunt> jimevans: Cross browser tree comparisons is something that we would be interested in.
18:28:34 <gsnedders> gsnedders has joined #webdriver
18:28:48 <davehunt> jcraig: It's achievable in the near future to do comparisons by walking the tree if we have limited known test cases
18:28:55 <AutomatedTester> ack jamie
18:29:16 <jcraig> s/had an investigation/have an investigation/
18:29:32 <gsnedders> RRSAgent, make minutes
18:29:34 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html gsnedders
18:30:16 <davehunt> Jamie: The thinking is that if we get accessible node working well then it's possible to write a tree dump as a layer on top of that. Important to get accessible node right first. I think we're heading in a direction that allows this.
18:30:18 <AutomatedTester> ack jgraham
18:31:21 <Jamie> https://github.com/web-platform-tests/interop-accessibility/issues/51#issuecomment-2099462510
18:31:35 <simonstewart> q?
18:32:01 <AutomatedTester> q?
18:32:07 <jcraig> TreeDump Investiigation (abandoned) https://github.com/web-platform-tests/interop-accessibility/issues/51
18:32:08 <davehunt> jgraham: Puppeteer exposes an API for accessibility trees, Playwright API redirects to alternate tools. Agree that don't expect the accessibility tree to be comparable between browsers in the near future.
18:32:58 <jcraig> Some explanation of the reasoning for moving https://github.com/web-platform-tests/interop-accessibility/issues/90
18:33:09 <whimboo> whimboo has joined #webdriver
18:33:20 <jcraig> s/moving/moving to a treewalker plan/
18:34:59 <AutomatedTester> Topic: Judging priorities for new requested features
18:36:22 <davehunt> whimboo: last time at TPAC we created a sheet for prioritising our roadmap, I have added new entries based on recent feedback on client priorities
18:37:00 <AutomatedTester> q?
18:37:22 <davehunt> AutomatedTester: you met with cypress folks, is there a column for this?
18:37:31 <davehunt> whimboo: not yet, but plan to add it
18:38:24 <davehunt> AutomatedTester: there are only three items for Playwright, are more going to be added later?
18:38:49 <davehunt> whimboo: Playwright have a lot more P1s, but want to update based on usage
18:39:14 <davehunt> whimboo: the current P1s are the "must have" items from Playwright
18:40:23 <davehunt> AutomatedTester: do we have a priority list for cells without a priority?
18:40:28 <Adam_Page> Adam_Page has joined #webdriver
18:40:42 <davehunt> whimboo: not yet, it will be filled in
18:41:26 <AutomatedTester> ACTION: David to reach out to Christian Bromann for priorities for wdio
18:41:45 <AutomatedTester> ACTION: David to look at Selenium items and work with them on Priorities
18:42:29 <AutomatedTester> ACTION: whimboo to add priorities for Playwright and Cypress.io to spreadsheet
18:42:49 <davehunt> AutomatedTester: this is a good list, and very useful to have
18:42:50 <AutomatedTester> q?
18:43:55 <AutomatedTester> ACTION: orkon to work with puppeteer team to get their priorities added to the spreadsheet
18:47:20 <AutomatedTester> https://github.com/w3c/webdriver-bidi/issues/787
18:47:35 <orkon> orkon has joined #webdriver
18:48:25 <sasha> sasha has joined #webdriver
18:52:27 <AutomatedTester> topic: Support retrieval of content quads for elements with CSS transitions
18:52:36 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/787
18:53:43 <karlcow> karlcow has joined #webdriver
18:54:46 <simonstewart> https://test.csswg.org/harness/test/geometry-1_dev/
18:55:47 <whimboo> https://github.com/web-platform-tests/wpt/tree/fd25aeb946a8df94314cf6fb4fe63b46eee2cd8c/css/geometry
18:56:09 <gsnedders> https://wpt.fyi/results/css/geometry?run_id=5201124441456640&run_id=5179680340836352&run_id=5184785144348672 would be a better link for tests, rather than the old CSS WG Test Harness (which is the same tests)
18:56:23 <gsnedders> s/link for tests/link for test results/
18:57:15 <gsnedders> https://drafts.csswg.org/cssom-view/#dom-geometryutils-getboxquads seems like it should give a DOMQuad with what we want… if it were specified. Or implemented.
18:58:07 <gsnedders> c.f. https://wpt.fyi/results/css/cssom-view/idlharness.html?run_id=5201124441456640&run_id=5179680340836352&run_id=5184785144348672 for evidence of lack of implementation of getBoxQuads
18:59:14 <jgraham> jgraham: So the understanding I have is that getBoundingCLientRect returns a DOMRect, which is the bounds of a rectangle containing the element. For transformed elements that's different to the actual bounds of the element if those are non-rectangular. DOMQuads in https://drafts.fxtf.org/geometry/#DOMQuad represents the latter. This is what CDP
18:59:14 <jgraham> exposes via its API. There is a draft API for getting these values from content in CSSOM-view https://drafts.csswg.org/cssom-view/#dom-geometryutils-getboxquads however this is basically all TODO.
18:59:14 <jgraham> This is actually implemented in Firefox.
18:59:14 <jgraham> So the problem we have here is that in terms of a standard we don't have anything to point at to explain the behaviour of the requested API. We could implement it in Gecko and Chromium, but it would be nonstandard or implementation-defined. If we actually wrote a standard here we might as well finish CSSOM-view and then expose it to content
18:59:16 <jgraham> (assuming there's no compat issue), and then clients could use that via script. Having a BiDi only API here seems rather odd.
19:00:23 <simonstewart> simonstewart has joined #webdriver
19:01:18 <davehunt> jgraham: we need someone from layout or from the CSS WG to help us out here. We should talk to Emilio
19:01:59 <ChrisCuellar> ChrisCuellar has joined #webdriver
19:02:17 <AutomatedTester> ACTION: jgraham to speak to Emilio and get advice on what we can do here
19:02:47 <AutomatedTester> topic: Emitting Events During "browsingContext.create" when "about:blank" is loaded
19:03:05 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/766
19:03:08 <AutomatedTester> scribe+
19:03:51 <AutomatedTester> whimboo: this issue was origianly raised by sadym
19:04:16 <AutomatedTester> ... this is about getting an event when the context being created and then when can we navigate
19:04:29 <orkon> q+
19:04:37 <AutomatedTester> ... so the question is what do we want to do with the creation of new tabs/documents?
19:04:54 <AutomatedTester> ... do we want to handle navigationStarted for about:black?
19:05:07 <AutomatedTester> ack orkon
19:05:36 <AutomatedTester> orkon: I checked the html spec and I couldn't see if there is a navigationStarted with about:blank
19:05:54 <AutomatedTester> ... perhaps we need to reverse the test so it doesn't have the event on about:blank
19:06:06 <AutomatedTester> q?
19:06:20 <whimboo> q+
19:06:24 <AutomatedTester> ack whimboo
19:06:40 <AutomatedTester> whimboo: we are happy to change this
19:07:06 <AutomatedTester> ... and this way we can improve the clients so they have a better idea when to work with the tab
19:07:08 <jdescottes> q+
19:07:27 <AutomatedTester> ... and I am not sure about the implementation status of these things in chrome and if/when it will be ready
19:07:31 <AutomatedTester> ack jdescottes
19:08:10 <AutomatedTester> jdescottes: when I was testing this in Firefox we weren't running events for navigation on about:blank
19:08:23 <orkon> q+
19:08:38 <AutomatedTester> ... if there are any scenario where we have any extra events in the browser?
19:08:42 <AutomatedTester> ack orkon
19:08:48 <orkon> https://github.com/web-platform-tests/wpt/pull/47958/files#diff-c773a239b93f48290e8f834f6fd9c337720fb92b206b65e03ce1c64633789032
19:09:09 <jdescottes> q+
19:09:14 <AutomatedTester> whimboo: we fire the created event early... this is a combined question of should we send anything out before the creation of the tab
19:09:51 <AutomatedTester> orkon: there are wpt tests that I have linked
19:10:10 <AutomatedTester> ... [describes test]. This test wasnt passing in chrome but in Firefox
19:10:16 <AutomatedTester> q?
19:10:20 <AutomatedTester> ack jdescottes
19:10:54 <AutomatedTester> jdescottes: thanks to the link. THe item about the creation event coming out too early... I think we should talk about this.
19:11:25 <gsnedders> q?
19:11:34 <sadym> This is the mentioned test: https://github.com/web-platform-tests/wpt/pull/47958
19:12:23 <AutomatedTester> ... in firefox we have changed the way that we emit events so that we do it after the creation of the context
19:12:29 <AutomatedTester> ack gsnedders
19:13:19 <orkon> q+
19:13:21 <AutomatedTester> gsnedders: Are you saying the load is async in firefox? I thought you could always access the document in the iframe in a sync way
19:13:38 <AutomatedTester> whimboo: this is for the new top level browser context
19:13:47 <AutomatedTester> gsnedders: ok, that wasn't clear in the issue
19:14:02 <AutomatedTester> ack orkon
19:14:38 <AutomatedTester> orkon: looks like we're talking about 2 different issues. This is about the browserContext creation with about:blank
19:15:16 <sadym> https://github.com/web-platform-tests/wpt/pull/47958/files#diff-c773a239b93f48290e8f834f6fd9c337720fb92b206b65e03ce1c64633789032R14-R29
19:15:21 <AutomatedTester> ... in firefox there are navigationStarted events being fired in about;blank
19:15:37 <AutomatedTester> sadym: I've linked to the the test
19:15:56 <AutomatedTester> q?
19:16:20 <AutomatedTester> jgraham: for the case of initial about:blank we should treat it like it is sync
19:16:45 <AutomatedTester> ... e.g. create a new tab with about:blank you can start interacting with it straight away
19:16:58 <jgraham> jgraham: and not emit a navigation started event
19:17:07 <AutomatedTester> gsnedders: is there a use case where that is not about:blank?
19:18:44 <simons> simons has joined #webdriver
19:19:07 <AutomatedTester> [discussion about checking we are all started from about:blank and navigationStarted events]
19:19:40 <AutomatedTester> whimboo: firefox has 2 events emited for about:blank. a sync and an async event
19:19:45 <orkon> q+
19:19:54 <simonstewart> q?
19:19:57 <AutomatedTester> ... and we should treat new window creation special if there is a URL in there
19:20:32 <AutomatedTester> whimboo: how would window creation handle this?
19:20:46 <AutomatedTester> ack orkon
19:21:18 <AutomatedTester> orkon: the html spec says there are some special treatment for about blank. e.g. if it has params we need to update the history
19:21:39 <AutomatedTester> whimboo: this should be possible for us to do this and not emit the event
19:21:42 <AutomatedTester> q?
19:23:09 <AutomatedTester> ACTION: sadym to update test to hsow that events are not emited on about:blank
19:24:15 <AutomatedTester> topic: Implement input.FileDialogOpened
19:24:26 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/pull/568
19:26:31 <AutomatedTester> sadym: I need to go review this and get back to the WG
19:26:51 <AutomatedTester> topic: Browsing Context Replacements and Resilient Command Execution
19:27:08 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/540
19:27:22 <AutomatedTester> whimboo: this was raise d awhile ago
19:27:39 <AutomatedTester> .... when we have browsing context and we have changed it to navigables
19:28:06 <AutomatedTester> ... when we architected this we worked with browsing contexts
19:28:33 <AutomatedTester> ... which was fine when there was creation since we just sent an about event
19:29:29 <AutomatedTester> ... we can do some basic things like get the event
19:29:43 <sadym> q+
19:29:58 <AutomatedTester> ... but we don't know what to do with actions when the page has been replaced partway through the execution
19:30:14 <davehunt> davehunt has joined #webdriver
19:30:28 <AutomatedTester> ... we can repeat the command if the context gets replaced and error if things are missing that we are expecting.
19:31:25 <AutomatedTester> ... if we agree that we want to rerun the commands which is what is in firefox we can close this issue and raise another
19:31:43 <AutomatedTester> ... we noticed this with the latest change to navigables
19:31:45 <AutomatedTester> q?
19:32:18 <AutomatedTester> jgraham: I don't think it's obvious what we should do if executing the script and to context goes away. e.g. waiting for a promise
19:32:36 <AutomatedTester> ... I don't think it's defined. It could be "wait for ever"...
19:32:42 <AutomatedTester> ack sadym
19:33:46 <AutomatedTester> sadym: it highlights another issue where we we have navigables and contexts
19:34:18 <AutomatedTester> ... previously we said we didn't want to redo that work as it was a major breaking change
19:35:59 <AutomatedTester> jgraham: I don't think we have a resolution... we want to perhaps have a look at doing this for all commands. I think we need to relook at it
19:36:15 <AutomatedTester> RRSAgent: make minutes
19:36:16 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html AutomatedTester
19:57:59 <davehunt> davehunt has joined #webdriver
20:14:19 <davehunt> davehunt has joined #webdriver
20:17:03 <kzms2> kzms2 has joined #webdriver
20:24:24 <davehunt> davehunt has joined #webdriver
20:32:42 <karlcow> karlcow has joined #webdriver
20:35:55 <davehunt> davehunt has joined #webdriver
20:42:40 <gsnedders> gsnedders has joined #webdriver
20:42:52 <jimevans> jimevans has joined #webdriver
20:43:56 <simons> simons has joined #webdriver
20:44:33 <simons> q?
20:47:30 <AutomatedTester> topic: Streaming request/response bodies
20:48:23 <jgraham> jgraham has joined #webdriver
20:50:32 <jgraham> RRSAgent, make minutes
20:50:33 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html jgraham
20:50:58 <simons> scribe+
20:51:13 <simonstewart> scribe+
20:51:58 <simonstewart> jimevans: not sure I have a specific design in mind, but I know that I want the feature
20:52:17 <simonstewart> jgraham: I think this is a high priority feature for various use cases. Everybody wants it
20:53:00 <simonstewart> jgraham: if we have a large response, sending that is probably a bad idea
20:53:16 <simonstewart> jgraham: similarly for writes. We want to be able to do that in pieces, rather than all at once
20:53:25 <simonstewart> jgraham: The question is, what does this look like?
20:54:04 <simonstewart> jgraham: I was looking at this in the Fetch spec, and it's all expressed in the Streams API, so a possible design approach would be to have a representation of a stream that you could read or write bytes to.
20:54:26 <simonstewart> jgraham: Potentially that would let us use a JS Stream object, so maybe we'd get a feature for free, and we'd have less to spec.
20:54:52 <simonstewart> jgraham: You can imagine that there could be a way to create a stream object in JS and return that over the protocol.
20:55:14 <simonstewart> jgraham: I don't have a use case for that, but if we did things that way, that functionality would be easy to implement
20:55:27 <simonstewart> jgraham: I don't know if that would actually work, but I'd like it to....
20:55:43 <simonstewart> q?
20:55:46 <simonstewart> q+
20:55:57 <AutomatedTester> ack simonstewart
20:56:43 <simonstewart> simonstewart: we currently only use text messages over websockets, but we _could_ use a binary message
20:57:11 <simonstewart> jgraham: I know that there's been talk of non-websocket backends, but I don't know if we need to couple that to this
20:57:35 <simonstewart> simonstewart: does that mean you have a preference for just sending text messages?
20:57:52 <simonstewart> jgraham: yes, because otherwise we'd need to figure out another way of structuring the data
20:58:09 <AutomatedTester> q+
20:58:52 <simonstewart> AutomatedTester: If someone wanted to change the response of audio and video coming through in a stream, what kind of format would we need for that?
20:59:05 <AutomatedTester> ack me
20:59:07 <simonstewart> jgraham: it's just bytes from our point of view (base64 encoded)
20:59:53 <simonstewart> AutomatedTester: the use case I'm thinking of is if someone wants to inject frames into their testing to find out how quickly things are coming through
21:01:02 <simonstewart> jgraham: There's lots of things we could do, but I think the API we want is something that allows us to read or write chunks of data until we're done
21:01:27 <simonstewart> sadym: I'm looking how CDP implements it. It just says "get me the next chunk" and it sends a base64 chunk
21:01:29 <simonstewart> q+
21:01:42 <simonstewart> jimevans: it takes a chunked response
21:02:10 <simonstewart> jgraham: I'm thinking of the platform stream, which gives you a read method, which gives you bytes in a "view" (not sure what a "view" is)
21:02:25 <simonstewart> jgraham: it reads bytes into an array buffer
21:02:59 <simonstewart> jgraham: I think the key thing is that if you had a stream object, it would give you a handle you can use in this kind of API for reading or writing data
21:03:04 <AutomatedTester> ack simonstewart
21:04:05 <simonstewart> simonstewart: it's easy enough to make a chunked approach look like a stream on the local end, so having a handle and reading and writing bytes in a chunked way seems like a sensible approach
21:04:26 <simonstewart> jgraham: I think someone needs to find out whether this works in detail, since we're not sure if anyone knows for sure
21:04:45 <simonstewart> jgraham: maybe there's some conflict between the ecmascript definition and what we need
21:05:04 <simonstewart> jgraham: We want something that gives you a handle you can read from and a handle to something you can write to
21:05:26 <simonstewart> jgraham: maybe the conclusion is "go and do the work"
21:05:48 <simonstewart> jimevans: I think we'd come to that conclusion in the GitHub issue already. I agree we need to just go and do the work
21:06:04 <simonstewart> sadym: is the network module the best place to put this?
21:06:23 <simonstewart> jgraham: that makes the most
21:06:41 <simonstewart> jgraham: sense
21:07:23 <simonstewart> simonstewart: we'll need to hook that into `provideResponse`
21:07:44 <simonstewart> Action: someone to do the work
21:08:09 <simonstewart> s/do the work/do the work of implementing the read and writes streams/
21:09:36 <AutomatedTester> topic: Interception of created navigables
21:09:47 <AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/756
21:11:04 <simonstewart> sadym: there are some use cases when users want to prepare subscriptions for events after the browsing context is created, but before anything has happened
21:11:18 <simonstewart> sadym: analogous connecting to a debugger
21:11:45 <simonstewart> sadym: we can implement this with global subscriptions, but that seems suboptimal. I'm not sure if there are scenarios that can't be implemented this way
21:12:10 <simonstewart> jgraham: I agree that this is a use case we need to address.
21:12:38 <simonstewart> jgraham: particularly for something like `window.open`, you'd want the same subscriptions to be taken to the new window, but in general you'd want this if a new context is created.
21:12:43 <AutomatedTester> q+
21:12:50 <simonstewart> jgraham: I'm not sure if there's a way to pause that creation
21:12:52 <simonstewart> q-
21:13:10 <simonstewart> jgraham: I don't know if the debugger in Firefox has to deal with this, since it only deals with one window at a time.
21:13:18 <sadym> q+
21:13:28 <simonstewart> jgraham: One can imagine other ways of handling this, but it's hard to know if you can pause things
21:14:02 <simonstewart> jgraham: such as an event before a navigable is created, and then respond with a list of subscriptions to add
21:14:06 <simonstewart> ack next
21:14:06 <AutomatedTester> ack AutomatedTester
21:14:47 <simonstewart> AutomatedTester: we know that some people want to be able to have sessions per tab because of the way that they run their tests. If we do this inheritance model, how would that work for that use case?
21:16:30 <simonstewart> jgraham: there is a little bit of overlap with subscribing to stuff for specific user contexts. That is, if a tab is opened in this specific user context, then <scribe gets lost attempting to listen and type at the same time>
21:16:49 <simonstewart> jgraham: if you could configure events at the user context level, that might solve a bunch of issues
21:17:00 <AutomatedTester> ack sadym
21:17:14 <simonstewart> sadym: another use case is setting the viewport when the browsing context is opened
21:17:24 <simonstewart> sadym: it's not event related and it's not solvable currently
21:17:59 <simonstewart> jgraham: yesterday, we discussed that we can't set some of the emulations at the top-level anyway because we think it might be process-level state.
21:18:12 <simonstewart> jgraham: a possibility is that we'd only allow setting those things for user contexts
21:18:45 <simonstewart> jgraham: and if you could also do "set viewport", but it applied to a user context and not a global, maybe that would be a declarative solution to a large subset of these issues
21:19:39 <simonstewart> jgraham: we'd have global, user, browser contexts in that order
21:20:08 <simonstewart> sadym: does that cover all use cases?
21:20:23 <simonstewart> jgraham: it's definitely less flexible than being able to pause creation
21:20:42 <simonstewart> Action: Julian to see if gecko can pause creation of new navigables
21:21:26 <gsnedders> gsnedders has joined #webdriver
21:21:48 <simonstewart> RRSAgent, create minutes
21:21:49 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html simonstewart
21:23:01 <simonstewart> sadym: but we'd not be able to do what we can with CDP
21:23:22 <simonstewart> sadym: but you're saying we can set things at the browser context or user context?
21:23:24 <simonstewart> jgraham: yes
21:24:17 <AutomatedTester> q?
21:24:40 <simonstewart> jgraham: I suspect that most test clients will want to be able to say something like "I'm running some tests, and I'd like to have all windows emulate the same conditions" This would allow this to happen
21:25:02 <simonstewart> gsnedders: I don't know if webkit can pause the creation of new navigables
21:25:40 <simonstewart> sadym: I wonder how firefox with cdp worked?
21:25:54 <simonstewart> jgraham: I'm not sure it worked, but if it did, then this suggests it's possible
21:26:07 <simonstewart> jgraham: it does sound complicated, and we should investigate properly
21:26:26 <AutomatedTester> q?
21:28:48 <simonstewart> Topic: Request for a navigationCommited event to inform immediately about the navigation status
21:28:57 <simonstewart> github: https://github.com/w3c/webdriver-bidi/issues/788
21:29:31 <simonstewart> Action: someone in chrome to find out what a `navigationCommited` actually is, and what it corresponds to in a spec
21:30:13 <simonstewart> Topic: Support setting page content
21:30:22 <simonstewart> github: https://github.com/w3c/webdriver-bidi/issues/759
21:31:01 <simonstewart> simonstewart: why couldn't you just do this by executing JS?
21:31:30 <simonstewart> AutomatedTester: this is something that puppeteer has, but it depends on `document.write` which is deprecated.
21:31:57 <simonstewart> AutomatedTester: the only major use case is maybe for WPT, but I can't see ordinary testers wanting to do this.
21:32:22 <simonstewart> AutomatedTester: for component testing, people load the components into the page rather than just injecting it in because they need styling and additional content
21:32:32 <gsnedders> +1 for simonstewart's comment ("why couldn't you just do this by executing JS"); seems like it should be the same as navigating to about:blank and just calling document.open/write?
21:32:39 <simonstewart> jgraham: does puppeteer use this a lot?
21:32:52 <simonstewart> sadym: I'm not sure
21:34:02 <simonstewart> <debate about whether regular users would do this>
21:34:27 <simonstewart> simonstewart: what is replacing `document.write`?
21:34:41 <simonstewart> gsnedders: nothing. You don't want to modify the parser state while parsing
21:36:01 <simonstewart> AutomatedTester: what about navigating to a data URL?
21:36:07 <simonstewart> gsnedders: it may well have a different origin
21:36:40 <simonstewart> gsnedders: what are the semantics of this in CDP?
21:36:48 <simonstewart> gsnedders: do those semantics matter?
21:37:16 <simonstewart> simonstewart: could you use `document.outerHTML`?
21:37:27 <simonstewart> <general agreement that it's not the right thing to do>
21:38:37 <simonstewart> jgraham: does someone in the puppeteer team need this now, rather than just calling "executeScript"?
21:39:47 <simonstewart> sadym: how far is `document.write` from being removed?
21:39:53 <simonstewart> gsnedders: impossibly far away
21:40:26 <simonstewart> jgraham: it might be hooked up to some logging saying "this is deprecated, please stop", but implementations could handle that by treating it differently if it came from a sandbox
21:40:40 <simonstewart> jgraham: if we had a special command in gecko, it'd just be calling the JS
21:40:47 <simonstewart> sadym: I don't have a firm answer yet
21:41:14 <simonstewart> simonstewart: so there's general agreement this isn't something that needs to be done just yet?
21:41:29 <AutomatedTester> q?
21:41:34 <simonstewart> jgraham: yes, but if puppeteer come back and say it's a priority, no-one is against adding it
21:42:13 <AutomatedTester> RRSAgent: make minutes
21:42:14 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html AutomatedTester
21:44:15 <simonstewart> Topic: BrowsingContext.captureScreenshot: restrict to top-level contexts only
21:44:24 <simonstewart> github: https://github.com/w3c/webdriver-bidi/issues/441
21:44:54 <simonstewart> sadym: in bidi you can capture a screenshot, and you can capture a screenshot of an iframe beyond its viewport. It's not feasible to implement in chrome
21:45:06 <simonstewart> sadym: our proposal is to keep the standard implementable.
21:45:23 <jgraham> q+
21:45:33 <simonstewart> sadym: we suggest restricting screenshots beyond viewports to the top-level browsing context
21:45:51 <gsnedders> q? to ask if we know of any use-cases for entire viewport screenshots within a frame
21:46:03 <simonstewart> jgraham: gecko can implement this. You're allowed to return an unsupported operation if an implementation can't do it
21:46:31 <simonstewart> jgraham: this doesn't seem like an important enough point of difference to say "if one browser can't do it, no-one can do it"
21:46:34 <gsnedders> q+ to ask if we know of any use-cases for entire viewport screenshots within a frame
21:46:40 <gsnedders> ack jgraham
21:46:50 <simonstewart> jgraham: people usually take screenshots for informative purposes
21:47:09 <simonstewart> q+
21:47:43 <simonstewart> jimevans: do we need a spec change to allow people to not return a result?
21:47:47 <simonstewart> jgraham: yes
21:47:54 <AutomatedTester> ack gsnedders
21:47:54 <Zakim> gsnedders, you wanted to ask if we know of any use-cases for entire viewport screenshots within a frame
21:48:00 <simonstewart> jgraham: no it doesnt need a spec change
21:48:02 <simonstewart> ack next
21:48:22 <simonstewart> gsnedders: do we know of any use case of people wanting to take a screenshot of the viewport of a frame
21:48:48 <jgraham> simonstewart: We used to get bug reports in selenium
21:49:07 <jgraham> simonstewart: People don't generally know the distinction between the top level viewport and an iframe
21:49:21 <jgraham> simonstewart: Can Chrome implement print for an iframe?
21:49:33 <jimevans> q+
21:49:34 <jgraham> sadym: I don't think so.
21:49:45 <AutomatedTester> ack jimevans
21:50:08 <simonstewart> jimevans: with respect to screenshots, the most common requested case for full-page screenshots is at the top level
21:50:24 <simonstewart> jimevans: and if that page contains an iframe, typically speaking, the iframe has a size associated with it.
21:50:45 <jgraham> q+
21:50:50 <simonstewart> jimevans: what you get in the screenshot is whatever is currently displayed in the iframe, bounded by the size of the iframe's viewport
21:51:20 <simonstewart> jimevans: someone asking for a screenshot of the entire content of an iframe is an unusual occurrence, even from the selenium context
21:51:58 <simonstewart> jimevans: I think it's okay that if the browsing context of an iframe is given to the snapshot command, it's okay to return an unsupported operation exception (because I think it's a rare edge case)
21:55:19 <AutomatedTester> ack jgraham
21:57:54 <simonstewart> jgraham: if some implementations can support it and some can't, this doesn't seem like a major interop issue
21:58:30 <simonstewart> sadym: OK. Sounds fine
21:58:49 <simonstewart> AutomatedTester: so long as we have the viewport in all cases, that's fine. Just thinking of the visual testing cases
22:00:43 <simonstewart> Topic: Allow browser configuration by user context and not only globally
22:00:50 <simonstewart> github: https://github.com/w3c/webdriver-bidi/issues/789
22:01:54 <simonstewart> jgraham: some people would like to treat different user contexts as completely separate sessions so that they can have a single browser process
22:02:12 <simonstewart> jgraham: from a gecko point of view, I don't think we can implement this in general
22:02:34 <simonstewart> jgraham: we use containers, which are extra attributes on storage. I don't think we have proxies per user context, etc
22:05:06 <simonstewart> gsnedders: we already create a separate NSURLSession for ephemeral browsing contexts, so I think we should be able to configure the NSURLSessions we're using for each top-level navigable separately. However, I'm not totally sure
22:05:33 <gsnedders> s/for ephemeral browsing context/for each ephemeral browsing contexts/
22:05:37 <simonstewart> simonstewart: presumably this is for "speed"?
22:05:44 <simonstewart> <general agreement>
22:06:02 <simonstewart> sadym: for use, proxies are per process.
22:06:17 <simonstewart> sadym: accepting insecure certs, we can per user context
22:07:50 <simonstewart> sadym: ah! You can set proxy
22:08:20 <simonstewart> jgraham: the thing we can do here is to add some configuration options to create user context, which are roughly equivalent to ones from capabilities that we can set.
22:08:37 <simonstewart> jgraham: per thing we try and set, we need to check whether or not it's possible for people to do
22:09:55 <simonstewart> sadym: do we want to use capabilities when creating user contexts?
22:10:00 <simonstewart> jgraham: very much no
22:10:26 <simonstewart> jgraham: you can always return "unsupported operation" if someone asks for something you can't implement
22:10:50 <simonstewart> simonstewart: we may just want to limit the capabilities we can pass through
22:11:12 <simonstewart> jgraham: yes, to the things in capabilities that are configuration values
22:13:18 <simonstewart> simonstewart: limiting to useInsecureCerts and proxy seems like something people can implement
22:13:41 <simonstewart> sadym: unhandledPromptHandling too
22:15:29 <AutomatedTester> RRSAgent: make minutes
22:15:31 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html AutomatedTester
22:16:16 <gsnedders> github-bot, end topic
22:16:27 <jgraham> RRSAgent, end meeting
22:16:27 <RRSAgent> I'm logging. I don't understand 'end meeting', jgraham.  Try /msg RRSAgent help
22:16:38 <jgraham> RRSAgent, leave
22:16:38 <RRSAgent> I see 9 open action items saved in https://www.w3.org/2024/09/27-webdriver-actions.rdf :
22:16:38 <RRSAgent> ACTION: David to reach out to Christian Bromann for priorities for wdio [1]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T18-41-26
22:16:38 <RRSAgent> ACTION: David to look at Selenium items and work with them on Priorities [2]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T18-41-45
22:16:38 <RRSAgent> ACTION: whimboo to add priorities for Playwright and Cypress.io to spreadsheet [3]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T18-42-29
22:16:38 <RRSAgent> ACTION: orkon to work with puppeteer team to get their priorities added to the spreadsheet [4]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T18-43-55
22:16:38 <RRSAgent> ACTION: jgraham to speak to Emilio and get advice on what we can do here [5]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T19-02-17
22:16:38 <RRSAgent> ACTION: sadym to update test to hsow that events are not emited on about:blank [6]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T19-23-09
22:16:38 <RRSAgent> ACTION: someone to do the work [7]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T21-07-44
22:16:38 <RRSAgent> ACTION: Julian to see if gecko can pause creation of new navigables [8]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T21-20-42
22:16:38 <RRSAgent> ACTION: someone in chrome to find out what a `navigationCommited` actually is, and what it corresponds to in a spec [9]
22:16:38 <RRSAgent>   recorded in https://www.w3.org/2024/09/27-webdriver-irc#T21-29-31
22:16:38 <AutomatedTester> RRSAgent: make minutes
22:16:40 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/27-webdriver-minutes.html AutomatedTester
22:16:46 <davehunt> davehunt has joined #webdriver
22:16:46 <jgraham> Zakim, bye
22:16:46 <Zakim> leaving.  As of this point the attendees have been AutomatedTester, sadym, jimevans, orkon, whimboo, Westin, simonstewart, Christian, jdescottes, sasha, Yoav, jgraham, gsnedders,
22:16:46 <Zakim> Zakim has left #webdriver
22:16:48 <Zakim> ... ZoeBijl, alice, valerie_young, JaeunJemmaKu, hdv, Jamie