16:55:57 RRSAgent has joined #webdriver 16:55:57 logging to https://www.w3.org/2022/01/12-webdriver-irc 16:56:03 Zakim has joined #webdriver 16:56:35 Meeting: WebDriver-BiDi 16:56:50 Agenda: https://www.w3.org/wiki/WebDriver/2022-01-BiDi#Agenda 16:56:55 jdescottes has joined #webdriver 16:57:10 RRSAgent: make logs public 16:57:21 RRSAgent: create minutes 16:57:21 I have made the request to generate https://www.w3.org/2022/01/12-webdriver-minutes.html jgraham 16:57:54 AutomatedTester is going to be late I think, so we need a volunteer to scribe 17:00:08 simonstewart has joined #webdriver 17:01:11 jimevans has joined #webdriver 17:01:47 G'day folks. I've a meeting at work that's bumping into the editorial meeting today. I will be late, but I'll dial in when I can 17:02:19 Well, that meeting :) 17:03:45 present+ 17:05:23 present+ 17:05:24 present+ 17:05:29 present+ 17:05:35 present+ 17:05:47 present+ 17:05:51 present+ 17:07:11 Topic: Sandboxed Script Execution 17:07:28 ScribeNick: foolip 17:07:46 jgraham: turn real talk into text 17:08:00 RRSAgent: create minutes 17:08:00 I have made the request to generate https://www.w3.org/2022/01/12-webdriver-minutes.html jgraham 17:08:19 github-bot: https://github.com/w3c/webdriver-bidi/issues/144 17:08:19 foolip, Sorry, I don't understand that command. Try 'help'. 17:08:30 github: https://github.com/w3c/webdriver-bidi/issues/144 17:09:46 jgraham: We've talked about sandboxed script execution before. If you haven't paged it in, we want some way to run scripts in a way that you can access the page DOM, but the JS properties you set aren't visible to content scripts, and you're not affected by what the content script has done. 17:10:24 jgraham: This is relevant for the ability to implement "find element" with JS without worrying about querySelector being overridden. 17:11:07 jgraham: Browsers already have a capability like this. The existing primitives aren't the same cross-browser, but getting convergence will be tricky, so we'll probably want some non-normative description on what authors can rely on. 17:11:21 jgraham: I've put up a draft PR at https://github.com/w3c/webdriver-bidi/pull/158 17:12:29 jgraham: the model is we have a target (realm or context ID) and in the case of a browsing context you get to specify a sandbox name. If it exists, use it, otherwise create a new one. 17:12:40 jgraham: or you can specify the realm ID if you already know it. 17:13:19 jgraham: This is different to CDP in that there's no explicit "create sandbox" command, although you can recreate it by running an empty sandbox script. It's a superset of CDP. 17:13:59 foolip: what about this is especially complicated or worth considering tradeoffs carefully? 17:14:32 jgraham: first, do people think this is an acceptable API surface? or should we have explicit creation like in CDP? the tradeoff here is you can make mistakes by making typos and create a new sandbox. 17:14:53 jgraham: the actual API surface feels fairly straightforward though. 17:15:08 jgraham: in the PR, there's just issues where you'd expect to understand how the sandbox stuff works. 17:15:48 jgraham: I've put up https://github.com/w3c/webdriver-bidi/pull/169 with some of the support we might need for this. 17:17:21 foolip: does one PR depend on another? 17:18:05 jgraham: https://github.com/w3c/webdriver-bidi/pull/169 is the one to review, as the actual thing to land. #158 isn't ready for review. 17:18:22 q? 17:18:25 q+ 17:18:27 ack 17:18:33 ack foolip 17:19:30 foolip: I guess the upside of the API surface is you save a roundtrip and it's easier to use? 17:20:00 jgraham: Yes. What Puppeteer does is create a sandbox upfront and use that for everything. Given that, why not just have that hardcoded as a sandbox name? 17:20:40 foolip: is there any notion of creating or garbage collecting a sandbox? 17:20:47 jgraham: the lifetime is tied to the window. 17:21:27 foolip: sounds good 17:21:30 q? 17:22:29 foolip: I'd suggest requesting review from folks on the PR (Brandon isn't here, for example) 17:25:05 topic: Communication channel from the browser to the client 17:25:33 github: https://github.com/w3c/webdriver-bidi/issues/157 17:27:20 sadym: there are a few approaches here 17:27:52 sadym: we could make it bi-directional, or just one direction with a binding 17:28:09 sadym: bindings would trigger an event on the BiDi client side. 17:28:29 q? 17:28:30 q+ 17:29:51 foolip: this question was previously tied up with sandbox scripts and communicating with them. with the bindings approach, will we talk to sandbox scripts and content scripts in the same way? 17:30:21 sadym: yes, and if the client wants to talk to multiple sandboxes they have to implement that. 17:30:57 ack jgraham 17:31:10 foolip: I agree that this is a good starting point, with just a way to emit an event. 17:31:29 foolip: there are questions about how exactly bindings should work still 17:32:09 jgraham: an earlier suggestion was that sandboxes get a postMessage. the new suggestion is bindings which is a method you can invoke. that works in both sandbox and content scripts. 17:32:55 jgraham: an issue we discussed last time is that once we have bootstrap scripts, we won't have the chance to pass in that binding. then maybe we need to pass it in when we configure the page load script. or an interface that exists only for page load scripts. 17:33:18 jgraham: but Brandon's proposal in the GitHub issue was to make the protocol level bits look the same regardless of the API 17:33:55 jgraham: at the protocol layer we seem to have broad agree, possible apart from bikeshedding the name, 17:34:09 jgraham: there's a question about what it should look like in the API 17:34:34 foolip: what is API and protocol in this discussion? 17:34:43 jgraham: the API is what an injected script sees 17:35:10 sadym: scripts initiated by a sandbox are seen by the client too? (scribe didn't get it all) 17:36:14 jgraham: for bootstrap scripts, we could pass in a function to support arguments (which is how bindings are passed) 17:37:17 foolip: ok, so you'd pass in a function to establish the binding, similar to how you now do it post-load for regular scripts? 17:37:19 jgraham: yes 17:37:27 q? 17:38:24 foolip: there was previously discussion about what a binding looks like. Is a binding a function which if invoked does the magic to emit the event? 17:38:28 jgraham: yes 17:38:57 Agenda is here: https://www.w3.org/wiki/WebDriver/2022-01-BiDi 17:39:25 topic: WECG Coordination 17:40:13 RRSAgent: make minutes 17:40:13 I have made the request to generate https://www.w3.org/2022/01/12-webdriver-minutes.html jgraham 17:41:00 Simeon: I'm a co-chair of the web extensions CG 17:41:12 Simeon: It started as core set of APIs common to all browsers 17:42:09 q+ 17:42:24 Simeon: As part of that, some CG member has requested capabilities for testing web extensions. I'm relatively new to standardization effort/process. We're not pursuing a standard, but trying to find the commonalities first. 17:43:21 foolip: do you have some details on testing web extensions? (I haven't looked at the email thread, sorry) 17:44:28 Simeon: what we've heard is (1) browser UI interactions, like clicking the extension icon in the toolbar, there are action buttons in that menu. This can't be emulated currently. Currently it's tested by opening a new tab, but that requires additional work for the sizing. 17:45:20 Simeon: (2) permissions are granted to extensions, and that capability can't be emulated. I've reached out to the DevTools team, but it's not clearly in scope of WebDriver / BiDi. 17:45:47 q+ 17:46:18 foolip: have you seen https://w3c.github.io/permissions-automation/? 17:47:14 jgraham: Having thought about this for only a minute, at a high level we've previously said that WebDriver is mostly focused on web content. But if others want to add extensions to the BiDi spec the right place to do that is probably in their own standards. 17:47:38 jgraham: So the web extensions spec could define the WebDriver APIs it needs. 17:47:58 jgraham: But we're happy to be involved and give review. But it seems unlikely those of us here are the right people to produce the right design. 17:48:05 ack jgraham 17:48:19 q- I was going to mention the mechanisms for extending the webdriver spec. 17:48:22 q- 17:48:55 jgraham: clicking UI buttons sounds a bit scary. maybe you don't want to emulate finding the button and clicking it, but maybe you want an API that behaves as if the button was clicked. 17:49:39 jgraham: for other parts of the problem, maybe you want events for the extension lifecycle. and maybe extension scripts could be a target for places to inject WebDriver code. 17:50:15 jgraham: it would be useful to have a "this is what we need" for the WECG, and I'd be happy to review drafts/proposals. 17:50:16 q? 17:51:27 permissions spec: https://w3c.github.io/permissions-automation/ 17:51:49 q+ 17:51:56 foolip: is BiDi support what you're looking for, or current WebDriver spec? 17:52:06 q+ 17:52:20 Simeon: we've talked about current WebDriver, because that's what the current testing stack is 17:52:28 ack simonstewart 17:53:05 simonstewart: back in the day geckodriver had the ability to switch between contexts. there's probably some prior art there. but the best way to do is probably to do a WebDriver extension 17:53:15 Simeon: is there a good example for how to extend WebDriver? 17:53:30 simonstewart: there's a section in the WebDriver spec 17:54:17 q? 17:54:20 ack jgraham 17:54:29 The section on extending the original webdriver spec is here: https://w3c.github.io/webdriver/#extensions-0 17:55:10 jgraham: WebDriver classic is command/response so it probably works for clicking a button. but it won't allow you to get events for the extension lifecycle 17:56:16 Simeon: that's useful. It sounds like the best course for us it to review how WebDriver extensions work, gather objectives into a document and then reach out to this group for this group 17:56:37 jgraham: that sounds reasonable 17:57:43 Simeon: with manifest v3 chrome is changing background pages to service workers. someone asked for the ability to stop a service worker to test that it will respond as expected to certain events. 17:59:20 foolip: https://github.com/web-platform-tests/wpt/issues/6866 from back in 2017 is a request for an API to terminate service workers 18:01:43 Alright, if there was something just now that needs to be scribed, can someone do that? 18:01:50 I can hear now, but not be heard I think. 18:02:22 jgraham: a lot of things like network intercept don't have any standards now. we'd definitely welcome collaboration on that sort of thing. 18:02:31 Simeon: I suspect we'll overlap 18:02:56 jgraham: we'll save the final agenda item for next time 18:03:11 jgraham: we have an editorial meeting in 2 weeks, next WG meeting in ~1 month 18:03:27 RRSAgent: make minutes 18:03:28 I have made the request to generate https://www.w3.org/2022/01/12-webdriver-minutes.html jgraham 18:03:49 Zakim, bye 18:03:49 leaving. As of this point the attendees have been sadym, jdescottes, jimevans, patrickangle, jgraham, foolip, simonstewart 18:03:49 Zakim has left #webdriver 18:05:37 Ah, apologies, twho missing items from the agenda, hopefully the new session one wasn't critical and can wait until next time 18:05:58 Otherwise ofc happy to discuss on IRC/GitHub/etc. 18:08:20 RRSAgent: bye 18:08:20 I see no action items