09:00:19 RRSAgent has joined #webdriver 09:00:19 logging to https://www.w3.org/2022/12/01-webdriver-irc 09:00:26 Zakim has joined #webdriver 09:00:52 patrickangle_ has joined #webdriver 09:01:23 Meeting: WebDriver-BiDi 09:01:42 Agenda: https://www.w3.org/wiki/WebDriver/2022-12-BiDi-Meeting-Berlin 09:02:04 RRSAgent: Make logs 09:02:04 I'm logging. I don't understand 'Make logs', jgraham. Try /msg RRSAgent help 09:02:08 RRSAgent: Make logs public 09:02:13 RRSAgent: make minutes 09:02:13 I have made the request to generate https://www.w3.org/2022/12/01-webdriver-minutes.html jgraham 09:02:54 present+ 09:03:27 present+ 09:03:39 present+ 09:03:44 present+ 09:03:47 present+ 09:03:48 present+ 09:03:51 present+ 09:04:44 hablich has joined #webdriver 09:06:42 present+ 09:11:35 present+ 09:11:38 Chair: jgraham 09:11:42 Scribe: jgraham 09:11:50 Topic: Roadmaps 09:12:33 https://docs.google.com/document/d/1fVe0U1DWUTYJkj2dj57_xVKzVU3FoDp_ASw4mZo89F4/edit# 09:14:17 whimboo: We're currently adding Network Event Logging, with the goal of being able to generate HAR files. The code is being shared with our devtools implementations. Spec PR is open, but isn't landed yet. We area also adding additional navigation events, and event subscription to a given browsing context. 09:14:52 whimboo: We're also adding (de)serialization of complex js objects, specifically nodes, which is also on the agenda later. 09:16:16 q+ 09:16:48 whimboo: Our next goals are based on the earlier discussions on priorities. First is bootstrap scripts, since that seemed to be highest priority for everyone. We will also add shadowroot support, also for WebDriver Classic. We will add support for input actions, and PDF, and screenshots. IsStale on Nodes to help with Classic on BiDi. 09:17:12 q+ 09:17:21 whimboo: BrowsingContext created event, so we can send out events for existing tabs, and the missing browsingContext.ContetDestroyed event 09:17:45 Q2 we're hoping to get to Network Request interception and HTTP Auth support. 09:18:24 Other features we're considering include user prompts, cookies, and some others (see linked document) 09:18:34 q? 09:18:44 ack sadym 09:19:00 sadym: The milestones seem like they're from different areas. 09:19:06 present+ 09:19:22 whimboo: We checked the roadmap that we talked about last time, considering the need to parallelise work. 09:19:41 whimboo: We can also rearrange some things 09:20:47 q+ 09:20:47 jgraham: The features are to enable full e2e test autoomation with screenshots and so on. Features that are close to classic are relatively wasy for us to add to BiDi. 09:20:53 ach AlexRudenko 09:20:56 ack AlexRudenko 09:22:08 AlexRudenko: Support for shadowroot is interesting. Nothing standard exists for interacting inside the shadow DOM in user space. We should discuss this on WebDriver level. 09:22:29 q? 09:22:32 ack foolip 09:23:12 foolip: Milestone 6 includes bootstrap scripts. That doesn't seem as useful for automated testing 09:24:06 q+ 09:24:24 whimboo: Client that supports most of the API for WebDriver BiDi would be helpful. Puppeteer for example is using bootstrap scripts. It's not in the spec yet, so it might take longer to fully implement it. 09:25:40 jgraham: Also useful to other clients. It allows installing functionality without worrying about conflicts with the page. 09:25:56 sadym: Selenium people mentioned using these for DOM mutation observation 09:26:01 q? 09:26:05 ack sadym 09:26:11 q- 09:27:23 https://github.com/GoogleChromeLabs/chromium-bidi/milestones?direction=asc&sort=title&state=open 09:28:56 sadym: We consider the minimal scenario which involves navigating to a page and running some scripts closed. We consider the bootstrap scenario very important for both Puppeteer and Selenium. We think it makes sense to also work on bindings, that's on the agenda for later. 09:29:42 sadym: We also consider console.log important; we're almost done with that. For each milestone we're creating an example script; we might want to share those. 09:30:21 sadym: Next is P2 items, haven't decided the order. Capturing screenshot and input emulation will probably be first. 09:30:37 sadym: Our milestones are based entirely on scenarios we want to support. 09:30:46 q? 09:31:00 q+ 09:31:05 q+ 09:31:06 q+ 09:31:10 ack whimboo 09:31:36 ack mathiasbynens 09:32:41 mathiasbynens: About the examples. These are standalone scripts that issue the raw BiDi commands to a specific websocket. We can test across multiple browsers. If we can agree on e2e scenarios we can upstream these examples, and have a shared roadmap at the spec level. 09:32:59 ack jgraham 09:34:19 whimboo: Do we know what's happening in clients? 09:34:23 q+ 09:34:38 q+ 09:34:54 simons: In Selenium people are implementing the spec as it happens, particuarly in Java and .Net. We're very keen to remove the dependency on CDP and move to BiDi. 09:35:00 ack AlexRudenko 09:35:24 simons: Patches from Jim Evans to the spec; he's owning .Net and raising issues as he implements 09:36:08 https://puppeteer.github.io/ispuppeteerwebdriverbidiready/ 09:37:15 AlexRudenko: On Puppeteer side we have some basic testcases that work with BiDi in Firefox e.g. starting the browser and doing some basic script execution (?). Next we're going to add Chromium support. We have a website to track test coverage support. We want to work out how to convert the CDDL types to typescript, and then work on fixing the tests. We have things in place, and then it should be 09:37:21 incremental. We'll bring up missing features. 09:37:42 AlexRudenko: Few tests passing right now from whole of Puppeteer testsuite 09:37:50 q? 09:38:26 sadym: Are there specific parts of CDP that Selenium wants to prioritise removing? 09:39:13 simons: Would like to go to a website and search. In this scenario CDP we use for capturing logs and for network interception. Those are the biggest use cases for us. 09:39:19 sadym: Bootstrap scripts? 09:39:53 simons: Would be nice for Selenium internally to use for the atoms to minimise the amount of data we're sending, but not a big user request. 09:40:13 simons: It's a QoL improvement, but not something we're using in CDP 09:40:24 q? 09:40:28 ack sadym 09:41:02 Topic: Roadmap / Milestone definitions 09:41:11 github: https://github.com/w3c/webdriver-bidi/pull/265 09:41:40 q+ 09:42:22 whimboo: Want to mention that this was discussed before. mathiasbynens did some work here to define user-centric milestones. The PR is stuck. Would be good to make some progress here. We could add the milestones to GitHub. Would make it easier for implementors to understand. 09:42:26 ack mathiasbynens 09:43:46 mathiasbynens: The point of the PR was to generate discussions, not to enforce a list of things. In the last meeting, we agreed on a list of features. Some of those are in the PR in an end user scenario. Would like all the features to be captured in that way. 09:44:35 mathiasbynens: The main idea is to bring the features into concrete scenarios that we can communicate to developers.
09:45:07 q+ 09:46:07 q+ 09:46:53 mathiasbynens: Recoding navigation performance is a compelling example of bootstrap scripts. 09:47:30 mathiasbynens: Does the format of the document make sense? Is the priority list work? Start with the format: does it work for outreach? 09:47:33 q- 09:47:55 simons: This looks good to me 09:47:56 ack hablich 09:48:42 hablich: This helps us communicate with tooling vendors and others we want to talk to about WebDriver BiDi 09:48:47 q+ 09:49:04 q- 09:49:04 q+ 09:49:06 hablich: It will also help us synchronise and work on the most effective things first 09:49:11 ack patrickangle_ 09:49:20 q+ 09:50:36 patrickangle_: Do we have a sense of which of these aren't possible today with classic? Request interception stands out. We want to communicate why BiDi over classic. 09:51:13 q+ 09:51:15 mathiasbynens: Good point. One specific thing that's not in the list is logging: that's a motivating feature for classic over BiDi so we should add that scenario. 09:51:20 ack whimboo 09:52:37 I like this format. We could make it more granular. For each subitem we could split into different browser implementations and show the status of each thing (tests, implementations). A question is where we want to put this. Do we want to use GitHub milestones? 09:52:50 whimboo: I'm happy to help with setting all this up 09:53:01 ack sadym 09:53:04 q+ 09:54:04 sadym: We have milestones which are similar, but this is somewhat higher level. We could link from the readme to milestones, but the readme is about showing what bidi's capable of, and how (e.g. via example scripts). This is more for external users than for us. 09:54:23 whimboo: We could reference wdspec tests to show how to implement this. 09:54:39 sadym: We had a discussion at TPAC about where to host example scripts. 09:54:45 ack hablich 09:55:55 hablich: I'm also happy to help set this up. Using GH tooling will be useful. We want this document to be consumable by users. There will be a lot of ways to evolve that. We should try to agree to land this and then make changes, rather than trying to make it perfect in the first instance. Land & iterate is better. 09:57:04 jgraham: We should land, but I think some of the existing comments should also be considered e.g. bootstrap scripts aren't a blocker for any use. 09:57:24 hablich: YEs, we should consider the feedback, and then make further changes via smaller PRs 09:58:12 whimboo: Regarding the explainer, you have everything on one page. It means you can search for things. We could link each section to the milestone page. Then users can dig into the details. 09:58:16 ack mathiasbynens 09:58:57 mathiasbynens: Can someone summarise discussion on where to host example scripts from TPAC? 09:59:50 mathiasbynens: Once we have a roadmap we can provide more resources to go with it. 10:00:06 https://www.w3.org/wiki/WebDriver/2022-10-BiDi 10:01:19 RRSAgent: make minutes 10:01:19 I have made the request to generate https://www.w3.org/2022/12/01-webdriver-minutes.html jgraham 10:02:09 https://www.w3.org/2022/10/12-webdriver-minutes.html#t05 10:02:34 https://github.com/w3c/webdriver-bidi/issues/309 10:03:56 mathiasbynens: If we agree on end to end usecases, we could consider adding these as a different kind of wdspec test instead of building new infrastructure 10:05:26 q+ 10:05:45 jgraham: It could work, but writing async python tests might be confusing for frontend webdevelopers 10:05:57 q+\ 10:06:00 q+ 10:06:45 mathiasbynens: We're using something like this in the chromium implementaion repo, where we just send raw commands rather than using the libraries 10:06:52 ack simons 10:06:59 q-\ 10:07:01 q-\ 10:07:42 simons: For developers there are going to be a lot of projects with good examples of the APIs e.g. Puppetter, Selenium. I don't know if we need wpt to contain things that developers might want to look at. 10:07:50 ack sadym 10:08:24 sadym: In our examples we don't even assert the result, we're just showing what to run to get the result. We don't have any CI. 10:10:40 q+ 10:11:26 jgraham: Examples that can't be run seems like a mistake; it can lead to people not being able to use the example code. We could consider using MDN for documentation of the protocol and we could in theory write example there that would connect to a local browser instance (but you'd have to teach people to opt in to allowing the connection from that origin, which could be hard) 10:11:32 ack hablich 10:12:37 hablich: We have two kinds of users. Tooling vendors might find example scripts useful. MDN might be more useful for web developers, but they're more likely to be using the tools. Maybe the conversation about example scripts for web developers is too early. 10:14:07 jgraham: Should work out which features on the roadmap we are in a good place for spec wise and which ones still require work. 10:15:50 q+ 10:16:15 Scribe: hablich 10:17:17 Is it https://github.com/w3c/webdriver/pull/1653? 10:17:26 jgraham: ... there is another PR open in webdriver classic about obscure handle serialization. The way we serialize elements in Classic is different than BiDi 10:17:55 foolip: Should we land https://github.com/w3c/webdriver/pull/1653? 10:18:09 jgraham: Yes, should have a serious conversation about this. 10:18:40 jgraham: There is a clear way forward here, we need to agree on the details though 10:18:53 q- 10:19:42 jgraham: Let's add this review to the end of the agenda. Next one is capturing screenshots. Nothing controversial there IMHO. Nothing spec-blocked there 10:20:20 jgraham: PDF, there is nothing in the spec. Should be a short conversation though. It should be like in classic. Let's resuse the classic definition exactly. 10:21:19 jgraham: Request interception is more interesting. There is a lot of spec work here. Logging (?) is a prerequisite. OMG this is going to be a lot of work. 10:22:27 jgraham: On measuring performance: We have cookies. Nothing in the spec though. We discussed a bit of cookies at TPAC. Similar to classic. Should cover cookies in different domains and partition cookies, 10:22:52 jgraham: Cache, nothing there yet. Same for bootstrap scripts, for that we have an agenda item for today. 10:23:23 mathias: I tried to link in the roadmap doc to the issues. We don't have proper issues for the unliked ones. 10:23:39 jgraham: do you also have a list of all the features we discussed last time? 10:24:15 mathias: Yes. *presents list* 10:24:45 jgraham: element interactability is missing. Video recording we have not talked about at all. 10:24:46 q+ 10:24:54 ack hablich 10:25:58 hablich: Natural next step would be to create issues for all the things that we don't already have an issue for. Logging is missing from the roadmap doc, we should create an entry for that. It should perhaps be first since it's the biggest feature request. 10:26:21 whimboo: Could make logging scenario A and split script execution into the next topic 10:27:04 jgraham: I can file issues on the things that don't already have them 10:27:13 q+ 10:27:55 mathiasbynens: For the PR I'd like to resolve the concerns first and then land. If people want to create patches to the PR that would help get this across the finish line. Making concrete suggestions would be a useful contribution. 10:27:59 ack sadym 10:28:35 sadym: Another option to proceed is to remove the specific milestones and then create a PR to add it to the roadmap. This would reduce the amount of noise in the conversations. 10:28:53 mathiasbynens: Which scenarios are controversial 10:31:22 q+ 10:31:48 jgraham: Not much controversial. Could split the first scenario to split out the things required to allow isolation (sandboxes, bootstrap scripts) and maybe add a scenario for network request logging / HAR generation. 10:32:08 mathiasbynens: I'd like to take another pass at this and maybe make it smaller so we can get it landed. 10:32:31 hablich: Are there open comments we should discuss right now? 10:32:46 mathiasbynens: I think it's fine. I'll try to do that today. 10:32:55 q? 10:33:00 ack hablich 10:49:15 Sam Sneddon [:gsnedders]: There is Sasha (Mozilla) and Maksim + Michael (Google) 10:49:26 Topic: Shared IDs 10:49:31 RRSAgent: make minutes 10:49:31 I have made the request to generate https://www.w3.org/2022/12/01-webdriver-minutes.html jgraham 10:50:27 github: https://github.com/w3c/webdriver-bidi/pull/180 10:56:34 sadym: I started a PR describing the shared reference [de]serailization. Several open questions. One is naming, but that's minor. Bigger topic is approach. Our approach is to keep the map on the Window. Another approach is to use the reference to the Element ID from WebDriver classic. That would mean specifying something different for elements, shadowroots, etc. How do others think this should work? 10:56:40 q+ 10:57:39 hablich_ has joined #webdriver 10:58:30 jgraham: We should provide them with an upgrade path from classic/cdp to bidi incrementally. Migration should be straight-forward for selenium users. This is user facing requirement 10:59:41 jgraham: functional requirement. What classic does not fulfill is the following example: You have a same origin frame and on the top level page you return window-frame-0.body. You should be able to take that reference and run it anywhere in the doc 11:00:43 jgraham: There are different options on how to make this happen. The webdriver spec is a bit broken on this topic. for Bidi we should do better. 11:01:41 jgraham: we put the element chache on the window. when you get an element you not only look at that window but you need to iterate on every window you have access to. not only the window that is in the same realm as the script is running in. 11:02:44 jgraham: the current browsing context group should have these references. We can store the cache per process, rather have a per window cache. 11:03:34 q? 11:03:38 ack jgraham 11:03:40 sadym: If the user have the rquirement to use the same element ids between classic and bidi this holds true. We are considering having a bridge method too, that can migrate an element id between classic and bidi 11:04:14 Scribe: hablich_ 11:04:19 sadym: Having access to the parent window: Change would need to be done in WD classic. This needs to be done in the implementation and can be tricky on our side 11:04:59 whimboo: We have a lot of classic tests in order to make sure we don't break classic stuff on the way. 11:05:55 sadym: How can we make sure that if this should work automatically, that it works? 11:06:26 jgraham: Node caches have this smarts build in. 11:06:56 jgraham: the idea is to update classic to have it understand and handle the concept of browsing context node cache 11:07:05 q+ 11:07:10 sadym: Sound reasonable, will implement it too like this. 11:07:16 ack whimboo 11:07:54 whimboo: we have two caches right now. one for elements, one for shadow roots. Can we combine them? mnight happen with window ids where this is relevant 11:08:30 sadym: current implementation says that its just a form object. 11:08:32 https://pr-preview.s3.amazonaws.com/sadym-chromium/webdriver-bidi/pull/180.html 11:08:57 sadym: current implementation says that its just a platform object. see https://pr-preview.s3.amazonaws.com/sadym-chromium/webdriver-bidi/pull/180.html 11:09:18 https://pr-preview.s3.amazonaws.com/sadym-chromium/webdriver-bidi/pull/180.html#platform-objects-map 11:09:50 sadym: This map will go to the classic specification. It will go to the top level window. 11:10:14 jgraham: IMHO it is theoretically unobservible if there are one or two caches. 11:10:44 jgraham: There should not be conflicts. So it should be fine. 11:11:12 q? 11:11:27 whimboo: In the link each window has a shared ID map ... is this a separate cache that you need for BiDi? 11:12:12 jgraham: I think we should hoist move the cache out of the PR and put it into the spec. Also, this is claiming this is a strong map, for dom nodes we always wanted to have a weak map because we dont want WD to keep nodes alive 11:12:25 sadym: Yeah, need to change, should be weak 11:13:42 jgraham: For us, it would be more challenging to make the IDs behave different between classic and BiDi. You always would need to make sure that all the methods work with both IDs, which is not great. 11:13:57 q+ 11:14:41 sadym: In WD we store a magical property in the global document to hold the reference to the node. We don't want the same approach in BiDi. We are thinking about using CDP node IDs instead. 11:15:03 sadym: It would tehcnically more easy to split them 11:15:36 ack simons 11:15:51 jgraham: If it is about easyness of implementation, we should have that conversation. I dont think people care about the format, but it should be an unique string. Add another item for later about this topic? 11:16:05 simon: We really don't want people doing conversions on our own 11:16:40 simon: The IDs are treated as IDs without any local meaning. Technically a breaking change in the spec, realistically it will not have any impact. 11:17:05 sadym: So you are saying it is fine to switch from UUID to string? 11:17:35 simon: More or less, yes. 11:18:34 sadym: We don't want to keep the UUID map in our backend. we only increase the counter there to generate a new ID 11:19:24 simon: We had a similoar mechanism in the past. We moved on because it was not stable enough. 11:20:38 q? 11:20:53 jgraham: Do we have more to discuss about element IDs? 11:21:26 Scribe: jgraham 11:21:27 sadym: no, thanks, I am fine. 11:22:28 sadym: A goal of BiDi is interop with WebDriver classic. In the spec we have it for browsing context. Classic window handle must be the same as browsing context id. We need to add some wpt tests for this. 11:22:49 sadym: For Window it should be quite easy to test, but we'll have to also add tests for Element and ShadowRoot. 11:22:55 q+ 11:22:58 ach whimboo 11:23:00 ack whimboo 11:23:44 whimboo: For browsing context / window handle we can write the tests today. We are already implementing the spec here, and can write the tests 11:23:53 sadym: I already have a test here 11:25:11 whimboo: For sharedId: we don't currently support shadow roots. For Elements we can write a BiDi test that uses both the HTTP protocol and BiDi. We can use child nodes to ensure that it's not only explicitly referenced nodes that work. I've written tests. 11:25:56 sadym: Do we have to split sharedId into ElementId / ShadowRootId? 11:26:09 sadym: This would make it easier to reuse in classic. 11:26:11 q+ 11:26:17 ack jgraham 11:28:25 jgraham: I don't think we need to divide stuff up more. The type annotations should be enough to dostinguish elements and shadow roots. 11:28:45 q+ 11:28:55 sadym: We have a distinction in terminology between classic, bidi and CDP, this might make things less confusing. 11:28:59 https://github.com/w3c/webdriver-bidi/issues/235 11:31:29 whimboo: Right now we serialize nodes independnetly of which node type they have. We could serialize Element differently 11:31:33 ack whimboo 11:32:23 sadym: From an implementation perspective it's very expensive for us to change the serialization. That happens internally in the browser, and we'd prefer to have as few iterations as possible. We'd prefer to have a single serialization for Node. 11:33:08 jgraham: I'm also happy to keep it as is. There are probably some cases where it will be worse, but it's not obviously a terrible tradeoff. 11:34:00 sadym: We are still working on checking if the current spec is implementable for us, but we are hopeful. 11:34:25 Topic: Refactoring of RemoteValue tests. 11:34:38 github: https://github.com/web-platform-tests/wpt/issues/37160 11:34:50 RRSAgent: make minutes 11:34:50 I have made the request to generate https://www.w3.org/2022/12/01-webdriver-minutes.html jgraham 11:35:44 q+ 11:37:07 [previous topic] 11:37:22 AlexRudenko: Do the element ids need to actually be the same, not just interchangeable? 11:38:02 simons: Yes, local ends will depend on the ids being the same; people will cache the ids in order to avoid network traffic where possible 11:38:25 VladimirNechaev 11:38:38 s/AlexRudenko/VladimirNechaev/ 11:38:58 [new topic] 11:39:16 q+ 11:39:40 VladimirNechaev has joined #webdriver 11:40:48 q- 11:41:05 whimboo: [de]serilization is quite heavy. In the tests it doesn't make sense to have exactly the same tests for all the different commands that can return js objects. We are currently returning objects in callFunction/evaluate/log.entryAdded/. A question is how to make the testing more efficient. We could have a top-level directory for all the serialization testing, and then for each command we would 11:41:11 only have basic testing 11:42:39 whimboo: sadym suggested having parameterised tests so we run each serialziation test for each command that can generate them. This works for now but might not work for all the commands in the future. session.[un]subscribe has some similar concerns; we could use this as a template for how to handle that 11:42:44 ack sadym 11:45:14 q+ 11:45:22 sadym: If we want to reduce the runtime costs, we could move all the serialization into a single test which would reduce the overhead of creating new tabs. Serialization shouldn't be the bottleneck. Checking serialization in all commands is important to us; we implement the serialization slightly differently per command, especially for complex objects. So I think we want to check all the combinations. 11:45:28 For maintaince costs, it doesn't seem that hard to add another line in parameterisation. Checking all the cases in one go might make debugging harder, but it would be acceptable I think. 11:46:53 jdescottes: I agree with what sadym said. Since our implementation handles seraization the same way we can assume all implementations work the same way, but shouldn't. It also avoids the discussion of what's a basic test vs an advanced case. Changing the code organisation sounds fine, but we should keep testing everything. 11:47:00 q? 11:47:03 ack jdescottes 11:47:49 patrickangle: I think this sounds reasonable. We want tests to just test a single command as far as possible. 11:48:36 whimboo: It sounds like we should have tests that are parameterised across commands so we can test all the cases with one test. For events more setup is needed to ensure we are in the right state to gnerate the event (e.g. if it requires a page load) 11:49:18 11:51:43 Lunch break until 13:35 Berlin local time 12:29:08 hablich has joined #webdriver 12:40:24 Topic: Demo 12:48:08 12:50:36 https://github.com/firefox-devtools/bidi-webconsole-prototype 12:53:15 Topic: Bootstrap scripts 12:53:24 github: https://github.com/w3c/webdriver-bidi/issues/65 12:53:29 q? 12:54:55 sadym: We want start implementing bindings to send custom events, because this is used by puppeteer. This is straightforward if it was an argument of callFunction. Bootstrap scripts could be a function that accepts an argument that would be called to emit custom events. 12:54:59 q+ 12:55:09 ack jgraham 12:58:19 q+ 12:58:56 jgraham: We discussed this at TPAC. We considered both the possibility of passing in a specal kind of remote value as a function argument and putting a WebDriver object with an emitEvent method in the scope of WebDriver scripts. The first option makes routing more flexible, but the general consensus at that meeting seemed to be that the second is simpler. 12:59:13 ack AlexRudenko 12:59:17 q+ 12:59:59 AlexRudenko: Do you intend to expose emitevent only for bootstrap scripts or for any kind of script evalutation? It seems useful in both cases. 13:00:25 jgraham: For any WebDriver-BiDi script including those run via callFunction and evaluate 13:00:30 ack sadym 13:01:24 sadym: A concern with this is that implicitly adding the script into every scope is some overhead for us. Do we want to add it always or just when the user wants the capability? 13:03:12 jgraham: From a user point of view this would just look like a normal WebIDL interface if it's on the scope, whereas a special kind of value you get as a function argument is more unusual. 13:03:37 sadym: I think the opposite; something that's just in scope for WebDriver seems confusing compared to something that's explicitly passed in. 13:03:43 q? 13:03:48 q+ 13:04:31 sadym: From the implementation perspective, if we provide this in the scope we'd have to wrap the script to provide that scope, which makes it harder to provide the stack trace. 13:05:22 jgraham: For our implementation it doesn't matter either way. I don't know what's easier to spec 13:06:03 foolip: For event handlers we had something like this, but it changed. We couldn't do this with WebIDL, it would have to be done in terms of ECMAScript. 13:06:19 foolip: I prefer the arguments version, since it means we don't have to pick a name. 13:07:52 jgraham: In the previous discussion, Apple were in favour of the implicit global, is that still the case? 13:07:59 q+ 13:09:14 patrickangle: The object that's just implictly in scope makes it easier to work with cases where we don't have an implied function wrapper e.g. script.evaluate. But if we don't care about that, just being able to use an argument does have advantages in that we don't have to pick a name, etc. 13:09:20 ack sadym 13:10:32 sadym: For now we have two ways to evaluate script. Bootstrap will be a third method. We don't expect to introduce new script execution mechanisms. So we might be able to limit this to just working with bootstap script and call function. 13:11:34 jgraham: So how would bootstrap scripts work in this model 13:11:48 sadym: It would take a functionDeclaration like in callFunction. 13:12:12 sadym: We could provide information about the page as arguments to bootstrap script 13:13:06 jgraham: I think you'd already have access to window.location &c. at this point so it's not clear what the extra information would be. 13:13:53 q+ 13:14:03 jgraham: Any input from client authors? 13:14:08 ack AlexRudenko 13:14:43 q+ 13:16:06 AlexRudenko: In puppeteer bootstrap scripts are more like evaluate(). From a Puppeteer perspective there's not a big difference, as long as you can send the message back and choose when the binding is available e.g. should be able to use setTimeout and still use the callback. For puppeteer we call the same bindings from multiple parts of the code, but that might be quite design specific. 13:16:15 ack sadym 13:16:31 sadym: I'm not sure if Puppeteer is using CDP bindings? 13:17:04 AlexRudenko: Yes. We don't inject bindings into the bootstrap script, but the bootstrap script removes the bindings from the actual context. But BiDi could be an improvement here. 13:17:08 q? 13:19:24 jgraham: Are we assuming that there's a different channel per RemoteValue in this model or something global? 13:19:35 sadym: One per instance, not global 13:19:51 q+ 13:20:22 simons: No strong opinion from Selenium side 13:20:27 JimEvans: Agreed, 13:20:32 ack AlexRudenko 13:21:26 AlexRudenko: Bootstrap scripts are usually upfront for a specific browsing context. How are we going to provide arguments that survive across multiple contexts? 13:22:14 q+ 13:22:15 AlexRudenko: If you install bindings in bootstrap script and then navigate what happens? In CDP the bootstrap script is run in the new page, and the binding also survives. 13:22:31 AlexRudenko: RemoteValue would be bound to a context? 13:22:39 ack sadym 13:23:40 sadym: The binding wouldn't stick to a realm. For each browsing context you call with the same bindings. 13:25:19 q+ 13:25:24 jgraham: I think the event channels would be owned by the session. Every evaluation would get the channelfrom the session, so you'd alays get the same one. 13:25:53 jgraham: this could also work with other argument types, although if you passed e.g. a node that was gc'd then you'd get an error trying to run the script. 13:25:58 ack jdescottes 13:26:29 jdescottes: What do you expect to do with the bindings that surive? Are you keeping state in it? How much do you expect to be persisted? 13:27:22 AlexRudenko: We don't expect anything to be persisted. I had a different model in mind, but that doesn't seem to be what's proposed. We map each binding name to a specific function on the client side and use that to handle state, nothing is shared in the context. 13:29:19 jgraham: Seems like we want to adopt the argument-based approach, which is a change from TPAC. The next step is to make a PR so that we can evaluate the technical details. 13:29:56 Topic: Make session.unsubscribe more flexible 13:30:08 github: https://github.com/w3c/webdriver-bidi/issues/326 13:31:37 q+ 13:32:19 whimboo: As mentioned during the roadmap presentation, the Firefox implementation can only globally [un]subscribe from events. When we subscribe to a specific context, and then unsubscribe everywhere we throw an error: it puts the burden on clients. We should make it possible to unsubscribe globally even if you only subscribed in certain contexts. Also for subscribe all and then unsubscribe from just 13:32:22 q- 13:32:25 some. 13:33:12 Sasha: Currently the spec only allows you to exactly undo what you originally did: if you subscribed globally you have to unsubscribe globally. If you subscribe to specific contexts then you have to unsubscribe from specific contexts. 13:33:16 q+ 13:33:26 ack jgraham 13:35:22 q+ 13:35:34 q+ 13:35:39 q+ 13:36:25 jgraham: For unsubscribe after subscribing globally there's a clear use case, currently for cleanup you need to know the intersection of existing browsing contexts and the ones you subscribed to. That's also easy to spec. For unsubscribe from specific contexts after subscribing globally I haven't yet heard a compelling use case, and it's quite hard to spec. 13:36:30 ack jdescottes 13:36:49 q+ 13:37:39 jdescottes: Trying to unsubscribe from a specific context after subscribing globally: at the moment we throw an error in that case. That might force consumers to always handle errors when trying to unsubscribe. It might be better to not throw an error. 13:37:45 ack sadym 13:37:57 ack hablich 13:38:15 hablich: When I subscribe to everything and then to one context, what happens? 13:38:18 q+ 13:38:22 Sasha: Currently that's a noop 13:38:53 hablich: If I subscribe to everything and want to downgrade, what do I need to do? Unsusbscribe from everything and then subscribe to some? 13:39:03 Sasha: Yes 13:39:10 hablich: Is it atomic? 13:39:14 Sasha: No. 13:39:21 hablich: that seems bad. 13:40:14 q+ 13:40:27 hablich: I was hoping that you could reduce subscriptions without dropping events, but I don't have a clear use case at the moment. 13:40:35 ack AlexRudenko 13:42:19 q+ 13:42:36 I can answer Alexes question 13:42:51 AlexRudenko: A related question is: when the client subscribes globally to some event, and then the client subscribes again to some events, you get one event. But clients might want to handle events differently in different parts of the code. Is there a way to get events multiple times? Every subscribe call could return a subscription id that would allow subscibing multiple times. 13:43:03 ack VladimirNechaev 13:43:32 VladimirNechaev: You can use different connections to provide isolation. 13:43:52 AlexRudenko: That adds overhead. 13:44:01 q- 13:44:37 VladimirNechaev: You can also have channels. If this becomes part of the standard it could also solve the problem. Then you get messages per channel. 13:44:47 ack sadym 13:45:07 nechaev: channels or multiple connections might be used for multiple subscriptions 13:45:45 sadym: We didn't figure out scenarios where we need channels. My proposal wasn't about subscription. We might to subscribe to just new contexts. 13:45:59 sadym: That could reduce traffic overhead. 13:46:07 q+ 13:47:36 jgraham: Do we agree that if you subscribe in certain contexts and then unsubscribe globally, that should remove all the per-context subscriptions? 13:47:40 (general agreement) 13:47:45 q+ 13:48:12 ack jgraham 13:48:43 whimboo: If you subscribe to a specific event and want to unsubscribe to all events in a module, should that work? 13:49:16 Sasha: The spec will currently get all the events and then error if you weren't already subscribed to all of them. 13:50:43 jgraham1: Should we also change things so that subscribing to some events in a module, and then unsubscribing from all events in that module unsubscribes to the events that you already subscribed to, even if it wasn't all of them? 13:51:07 Sasha: I think the previous change will automatically change this scenario too 13:51:14 q? 13:51:20 ack whimboo 13:51:53 q+ 13:52:25 q+ 13:53:23 jgraham: That's progress. For the issue of clients wanting to have multiple copies of events, please file an issue. My first thought is that it miht be better for those clients to implement it rather than making it part of the protocol. 13:53:28 ack jdescottes 13:53:59 jdescottes: What about subscribing globally and trying to unsubscribe from a specific context? Should we make this a noop? 13:54:20 ack sadym 13:55:01 sadym: Another question was if we subscribe to a browsing context and then it's deleted, and then unsubscribing will cause an error. 13:55:23 whimboo: Unsubscribe all might solve this. 13:58:08 jgraham: Could we solve this class of problems by having the command return something about the current subscription status or what the command achived? Then the client would be able to tell whether what it did had any effect or not. 13:58:23 sadym: For the case I described, having a specific error (no such frame) seems sufficient. 13:59:23 jgraham: For jdescottes' case it seems like we'd want to tell the client what happened. 14:00:05 jdescottes: The fact that it's currently asymmetric between what happens in subscribe and unsubscribe is what I'd like to change. 14:00:49 q? 14:15:48 hablich has joined #webdriver 14:20:26 choochoo 14:20:38 Topic: Clarify extensibility rules 14:20:49 github: https://github.com/w3c/webdriver-bidi/issues/274 14:21:21 sadym: We didn't reah consensus on this, we should clarify the open issues. 14:23:37 How extensible should BiDi be? Should it be possible to add random fields and still say it meatches the spec? For example when you execute some script you get an object with realm/context/sandbox. This makes the result compatible with two different ways of specifying a target for script execution. If this is accepted it could be confusing for users, but it's useful to be able to return the values we 14:23:43 got from script execution directly. 14:23:45 q? 14:27:41 q+ 14:29:23 jgraham: I see three options. 1 is to do what we do currently, which could be an interop hazard, particuarly if people are using deserialization libraries that make different choices around ambiguities. 2 is to say that for these type we aren't extensible and need to match the fields of one variant exactly. 3 is to require each variant to have a type field so that we always match on a specific type 14:29:29 name. We are already using approach 1 in tests, but it could be problematic in the future. 14:29:32 ack sadym 14:30:27 sadym: I have two concers about restrictions. I think it's very useful for people to be able to send back what they receive. I already mentioned "channels" in our implementation that allow splitting; we want to do that. 14:35:13 q+ 14:36:02 jgraham: Yes, top level commands/events need to be extensible. One problem with allowing extensions of data without a type tag is that names hav to be globally unique: if people are relying on the fact that the result of some command can be sent as the payload to some other command, we can't add conflicting fields at any point in the future. That might not be a big problem, but it is a worry. Type 14:36:08 tagging is much less convenient when writing in an untyped language, but it's at least very safe. 14:36:11 ack whimboo 14:37:02 whimboo: If we have a type here where the client can specify context or realm, how should the browser handle this? We might want to return one or the other? 14:37:21 present+ 14:37:54 q+ 14:40:24 jgraham: That doesn't work, it would be on the client to reform the data into the correct type. We could theoretically change the responses so that they always return types packaged in a way that we could firectly extract a field and return it to the server, but that would be a breaking change. 14:40:30 [general looks of concern] 14:40:34 ack JimEvans 14:42:08 JimEvans: As someone working on client bindings, and in strongly typed languages, having the spec be as unambigous as possible in terms of what's returned across the wire is a big plus. As is called out on the issue, having to make a guess between two different types of things if the response happens to contain valid properties for both of multiple return types, the client has to make a judgement call, 14:42:14 and removing that ambiguity would make life easier for us. 14:44:55 q+ 14:45:03 sadym: Is the issue mostly about browsers? 14:45:49 jgraham: Yes, but a browser could in theory use extensibility to return something to a client that's ambiguous and then the client has to guess because there's no spec to tell it how to resolve the ambiguity. 14:45:54 ack JimEvans 14:47:04 JimEvans: The realm-vs-context case is interesting, but more interesting is a script.evaluate response that contains both a result and an exceptionDetails property. How do you actually know what's the intended result. Browser vendors might say "we're never going to do that", but for clients it would be better if the spec made it impossible to do. 14:47:07 Agree on the response (server-client message) to be not extendable in non-root level 14:49:27 Agree on the response (server-client message) to be not extendable, including the root level 14:50:16 jgraham: exceptionDetails vs result is a top level response. We had a case where we were sending an evaluate response with no result field and so we assumed it was an exception but actually it was a missing field. That obviously shouldn't happen, but having an explicit field to tell us what the type was would have been helpful. 14:54:39 jgraham: Maybe we could look for all the cases where a client has to intorspect fields to determine types and change those, even if we don't do the same for the case where browsers have to introspect 14:59:20 jgraham: I think that's just ScriptEvaluateResult at the moment. Fixing that doesn't solve the problem for browsers, but it would make things unambiguous for clients. 15:00:04 also script.Target type? 15:01:26 Ah. Right. Sorry. I withdraw my comment. 15:02:11 Topic: Support for shadow roots/DOM - in WebDriver spec? 15:02:17 RRSAgent: make minutes 15:02:17 I have made the request to generate https://www.w3.org/2022/12/01-webdriver-minutes.html whimboo 15:02:50 AlexRudenko: I want to get more context about support for shadow roots. 15:04:01 whimboo: In the classic spec we have get shadow root, find element from shadow root, etc. In Firefox we only have get element from shadow root. For BiDi Firefox doesn't implement anything yet. But the spec parts are there in node serialization 15:05:31 AlexRudenko: We did some exploration. We see that users are implementing a selectors syntax that allows querying across selector boundaries. I was wondering if that could potentially be specified in WebDriver BiDi. Currently clients create their own implementation. Some clients are using arrays of selectors. Some are redefining descendent selectors. 15:05:36 q+ 15:05:44 ack jgraham 15:07:46 q+ 15:08:05 Classic CSS selector: https://www.w3.org/TR/webdriver/#css-selectors 15:09:34 jgraham: I think that the use cases make sense, but it's hard to see how the spec would work. We'd at least need to talk to the CSSWG to ensure that we don't define some syntax that clashes with their plans. I think we'd need a proposal with use cases and so on. 15:09:49 AlexRudenko: OK, we'll open an issue and start to investigate what's possible 15:09:57 ack AlexRudenko 15:10:36 AlexRudenko: There's also a Selector Extensions proposal in CSS to provide custom combinators and pseudoclasses, so maybe that would allow implementing this in some more standard way, but I"m not sure what the status of that proposal is. 15:10:49 http://tabatkins.github.io/specs/css-aliases/#issues-index 15:11:11 https://www.w3.org/TR/2014/WD-css-scoping-1-20140403/ (deep combinator, removed now) 15:11:12 AlexRudenko: There might be a newer revision of this spec 15:11:25 (the css-aliases one) 15:12:57 q+ 15:13:02 ack jdescottes 15:13:19 jdescottes: Could we implement this as a different find element strategy 15:13:53 AlexRudenko: It's currently possible to implement what we need via js evaluation. If we come up with a syntax we need to make sure it's compatible with CSS> 15:14:44 jdescottes: I was thinking of closed shadow roots; you can't pierce that with js, but you can with WebDriver. In Fx devtools we have an array of selectors and we run one in each level of shadow tree 15:15:00 q+ 15:15:04 ack AlexRudenko 15:16:23 AlexRudenko: Array of selectors is also something we're considering for Puppeteer, but there might be a better syntax that's easier to write by hand. Closed shadow roots are a problem since you can't traverse via js. Open shadow roots are more common, so that's the case we're targeting first. 15:17:12 Topic: Add the Element Origin concept 15:17:19 github: https://github.com/w3c/webdriver/pull/1653 15:23:42 jgraham: The idea is to reuse Actions in BiDi. But we can specify an origin relative to an element. In BiDi we don't want to reuse the classic form of the WebElement Reference type. So the proposal is that we allow a BiDi RemoteValue type instead. BiDi would _only_ accept that (the CDDL will reject the other form), classic would accept both (to avoid the algoritihm having to know if it was called by 15:23:48 classic or BiDi) 15:23:50 Scribe: AlexRudenko 15:24:39 +q 15:24:46 ack JimEvans 15:25:41 q+ 15:26:51 Jim Evans: from the local end perspective in classic, it's not a huge burden from the selenium side to have multiple things as the trigger that says this object is a web element reference. This is doable on the local end as long as the alternative data structure returned has unique enough properties to identify it as the web el reference. This applies to other places where return shadow roots, for example. I think there is the opaque key 15:26:51 for frames too. It's not a huge burden to be able to accomodate that in Selenium 15:27:00 ack jgraham 15:27:38 jgraham (IRC): nothing here that changes the requirements for clients. Client never has to interpret this and works as it works today. It only changes the requirement on remote ends 15:27:49 q+ 15:27:54 ack whimboo 15:28:47 whimboo: what properties do we need on the properties object to know it's an element? we need node at least? and the shared id? shared id can link to an element or shadow root 15:29:15 jgraham (IRC): you take the share id and look it up, if it is not the element, throw an error 15:29:33 jgraham (IRC): just matter at the lookup time 15:30:17 whimboo: when we serialize the element, we check the type node, we add the shared ID if it is the element. So it is what the client gets. Based on the sharedID, we can impl the lookup? ok 15:30:20 q+ 15:30:40 Scribe: jgraham 15:30:43 ack sadym 15:31:39 sadym: Why do we need to work on the concept of element origin, rather than deserializing and then noticing the result is an element. 15:32:44 https://w3c.github.io/webdriver/#dfn-dispatch-a-pointermove-action 15:36:30 jgraham: It's mostly easier from a spec point of view since we don't deserialize first and then use the deserilized object, we look at the object fields as we go on 15:36:44 sadym: This change would change the behaviour of ChromeDriver for classic? 15:36:49 jgraham: Yes 15:38:26 jgraham: If we want to make the classic behaviour unchanged we should pass in a flag to choose one behaviour or the other to the caller 15:38:35 sadym: Where do we use this? 15:39:01 whimboo: For pointerMove we can specify three different origins, either viewport, the current position, ore relative to an element 15:39:50 sadym: I will review. 15:40:20 https://github.com/w3c/webdriver-bidi/pulls 15:40:29 https://github.com/w3c/webdriver-bidi/pull/208 15:40:51 github: https://github.com/w3c/webdriver-bidi/pull/208 15:42:44 sadym: I wanted to find things in the spec, but found that line breaks interfered with that. I reformatted the spec, but there was pushback that it wasn't automatically enforced. jdescottes suggested a script to detect the issue, but I'm not sure how to set it up. 15:42:50 (for CI) 15:42:55 Scribe AlexRudenko1 15:42:59 q? 15:43:04 q+ 15:43:09 ack jdescottes 15:43:35 https://github.com/w3c/webdriver-bidi/blob/master/scripts/build.sh 15:43:56 q+ 15:43:58 jdescottes: I proposed the script but I don't know what is the preferred tooling. Happy to try smth like this if there is nothing to lint the spec. I can see how to set up github actions to lint 15:44:02 q+ 15:44:02 q+ 15:44:06 ack jgraham 15:44:22 q- 15:44:23 q+ 15:44:56 https://github.com/w3c/webdriver-bidi/blob/master/scripts/test.sh 15:45:18 q- 15:45:39 jgraham (IRC): in terms of CI, we already have a job set up that is installing node and running the validation stuff. Because CDDL extraction is still running in node. I think the script will be easy to add to this job. The only problem is that the lint does not automatically fix it and increases the feedback time. If it is irritating enough we can probably write a script to fix it automatically 15:45:51 ack sadym 15:46:18 sadym (IRC): I can take another look at that PR and try to implement one of the options. I can take it over. 15:46:36 https://github.com/w3c/webdriver-bidi/pull/337 15:47:09 whimboo: a PR about capabilities: difference between classic and bidi. Should make it consistent. 15:48:04 whimboo: anything to make CDDL naming more consistent? 15:48:05 https://github.com/w3c/webdriver-bidi/pull/109 15:48:07 jgraham (IRC): 15:48:10 q+ 15:48:13 * jgraham (IRC): need to fix conflicts 15:48:31 topic: https://github.com/w3c/webdriver-bidi/pull/109 15:48:37 github: https://github.com/w3c/webdriver-bidi/pull/109 15:48:47 ack JimEvans 15:49:04 Jim Evans: added 109 to the list. Was there any movement on this PR? 15:49:41 jgraham (IRC): the last status was that this PR was fine approx. But I wanted to land HTML changes. 15:50:01 jgraham (IRC): and the last person to look at this was foolip (IRC) but he left 15:50:19 I can react on chat, possibly 15:50:44 q+ 15:50:57 jgraham (IRC): have to rewrite the HTML part of this PR and land it 15:51:01 ack sadym 15:51:04 sadym (IRC): WPT tests are missing for the PR 15:51:24 jgraham (IRC): would also need to add tests 15:51:43 jgraham (IRC): is it something that is blocking? 15:51:57 Jim Evans: no just trying to clean up 15:52:42 https://github.com/w3c/webdriver-bidi/pull/340 15:52:52 whimboo: filed a PR to add the type field 15:52:53 github: https://github.com/w3c/webdriver-bidi/pull/340 15:53:08 whimboo: if it looks okay I can make the remaining changes 16:31:14 claudiosegovia has joined #webdriver 18:11:58 Zakim has left #webdriver