IRC log of webdriver on 2024-09-27
Timestamps are in UTC.
- 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