16:57:58 RRSAgent has joined #webdriver 16:58:03 logging to https://www.w3.org/2023/02/08-webdriver-irc 16:58:04 Zakim has joined #webdriver 16:58:28 patrickangle_ has joined #webdriver 16:59:23 Meeting: WebDriver 16:59:46 Agenda: https://www.w3.org/wiki/WebDriver/2023-02-BiDi#Agenda 17:00:02 RRSAgent: make logs public] 17:00:04 RRSAgent: make logs public 17:00:08 RRSAgent: make minutes 17:00:09 I have made the request to generate https://www.w3.org/2023/02/08-webdriver-minutes.html jgraham 17:01:10 present+ 17:01:10 brwalder has joined #webdriver 17:02:18 present+ 17:02:18 present+ 17:02:18 present+ 17:02:18 present+ 17:02:18 present+ 17:02:22 present+ 17:02:22 present+ 17:03:08 present+ 17:03:26 Scribe: alexrudenko 17:03:47 simons has joined #webdriver 17:03:56 Topic: Awaiting review 17:04:02 present+ 17:04:22 Network module: https://github.com/w3c/webdriver-bidi/pull/204 17:04:28 jgraham (IRC): first PR to review is the network module 17:04:35 q+ 17:04:35 Input module: https://github.com/w3c/webdriver-bidi/pull/175 17:04:39 the other one is the input module 17:04:44 ack whimboo 17:04:46 I removed the "sharedID" from the agenta, as it was merged 17:05:30 whimboo: regarding the network PR, in Firefox we now have complete support for this. Upcoming 110 release. And we have added a lot of tentative tests to WPT. Once it is agreed and merged, can make them official tests 17:06:06 Topic: Sandboxed script execution 17:06:13 GitHub: https://github.com/w3c/webdriver-bidi/issues/144 17:06:43 q+ 17:06:45 whimboo: I added this because I went over old issues that were left open. It is not clear what is missing in this issue. I wonder what specifically required here to get this feature finished? 17:06:51 ack jgraham 17:08:09 jgraham (IRC): basically in the spec we agreed about the name, sandbox. Details are missing but no one is implementing it from scratch. Semantics are not quite the same but it is not a priority 17:08:47 jgraham (IRC): we can close the issue and say we specified it and we can have another issue about getting an actual definition done later. Or as a issue to track that future work in the same issue. 17:09:05 q? 17:09:44 whimboo: on my side, we can close it and if there are things to add in the future. And then file another issue for this. 17:09:54 + for creating new issue for details 17:09:58 q+ 17:10:04 ack orkon 17:10:57 orkon: I think we found an issue in the Firefox sandbox; if you delete a global object it will deleted in all sandboxes. I'd like this to be specified more. We can't investigate in detail. 17:13:38 orkon: This will cause a failing test in CDP-backed puppeteer in Firefox 17:14:31 Topic: Serialization of platform objects - special type & value? 17:14:40 GitHub: https://github.com/w3c/webdriver-bidi/issues/352 17:15:47 whimboo: so I implemented the support in Firefox and Maskim gave some feedback. We only return an object with types but without the value. In Chrome, the value is empty but preset. Should we keep a type for platform objects? Or if we have a simple objects but include all enumerable props from this platform object? 17:16:47 q? 17:16:51 q+ 17:16:53 jgraham (IRC): at the moment there is contextual difference between empty value and no value. No value = have not tried to serialise, empty value = serialization failed. 17:17:11 jgraham (IRC): not sure if it's a good design, but it is the logic of the current spec 17:18:22 jgraham (IRC): by default serializing all properties of platform objects might not be good. I don't know if there are use cases that require it. I am worried about the platform object type, like we do for Node, it is sort of implementation details. 17:18:39 q- 17:18:53 jgraham (IRC): we should probably add a constructor property to see which type it was constructed with. I think there is some use case for the constructor property. 17:19:48 jgraham (IRC): the current spec is at least internally consistent and we should make a case for changing it 17:19:56 q+ 17:20:21 whimboo: good question. I wonder if there will be useful for clients to distinguish between platform and other objects. For example, we only add constructors for only some objects. 17:20:25 ack sadym 17:20:41 whimboo: not sure if we can some feedback from Selenium 17:21:11 sadym (IRC): relying on not having value seems weird. Having either constructor or having a dedicated type, would be helpful. Both seem to be valid. 17:21:45 jgraham (IRC): value is not meant to determine what is a platform object or not. It's a feature by accident. 17:22:25 jgraham (IRC): maybe we should be completely consistent between js and platform objects and allow means for setting depth. 17:22:44 q? 17:22:44 q+ 17:22:47 ack sadym 17:22:49 jgraham (IRC): currently we set it to 1 in may places 17:23:56 sadym (IRC): meaning that we say that all platform types will have a dedicated type so they will understand why there is no value. From the implementation perspective, we will always handle an object with value and we will always respect the max_depth. Currently, we don't provide a value even if max depth is not reached. 17:24:22 jgraham (IRC): clients should really be able to handle both cases: missing and empty value 17:24:32 @jp 17:25:11 q? 17:25:26 jgraham (IRC): I mean in either case the clients should handle both cases. (Note: missed a sentence about CDP) 17:25:33 Topic: Classic: Handle cases where a navigation happens during script execution 17:25:42 Github: https://github.com/w3c/webdriver/issues/1708 17:26:48 q+ 17:26:54 ack sadym 17:26:54 whimboo: we currently have no way to fail gracefully and a navigation happens. In prompts, we raise an error. in navigation, we don't have anything useful. But we don't know what we should do in this case. Is raising a JS good? or some other way to indicate that the script was aborted 17:27:32 q+ 17:27:40 ack simons 17:27:43 sadym (IRC): what is the use case for that? so technically the user can handle this use case by themselves. Is there an example where it cannot be handled on the user side? 17:28:19 +1 for 17:28:19 q+ 17:28:49 simons: this case here that the js has not actually executed. And potentially for an async script that might wait indefinitely. There is nothing wrong with the js here but the window is gone. Either solution is good: js error or other error 17:28:50 ack jgraham 17:29:11 q+ 17:29:21 q+ 17:29:47 jgraham (IRC): typical example is a buggy case that causes a nav before results are sent back. We need to define how we handle it for correctnes.. 17:29:48 ack whimboo 17:29:51 s/correctnes../correctness./ 17:30:39 I think I prefer JavascriptError, just because I expect clients to handle it somehow, even though technically no such window is providing more information 17:30:40 whimboo: which error type to use? for prompts with use a js error. Should we keep using? Or should we have a new failure here? how will clients handle it if smth aborts? 17:30:43 ack sadym 17:31:26 sadym (IRC): sending an error with no window sounds good. But when will the exception happen? 17:31:49 jgraham (IRC): in classic there is a navigation event and it would be right to handle it as part of the unload handler 17:31:54 q? 17:31:55 q+ 17:32:32 whimboo: should we also have something similar in bidi? 17:32:54 jgraham (IRC): technically the bidi client can handle unresolved promises but perhaps it should be rejected on navigation 17:33:10 whimboo: should we file a separate issue for bidi? 17:33:19 whimboo: AI: to file an issue 17:33:21 action: whimboo to file a BiDi issue covering this scenario 17:33:43 Topic: Shadow DOM selectors in WebDriver (BiDi) 17:33:52 github: https://github.com/w3c/webdriver-bidi/issues/342 17:34:01 scribenick: jgraham 17:35:21 orkon: Is this in the scope of WebDriver/BiDi and if it is how do we move forward? The problem is there's currently no way to address elements inside the shadow DOM in BiDi. Only scoped to open shadow roots. Currently need to do DOM walking by hand. Current solutions are verbose and don't allow combining different selectors. 17:35:56 `div > some-host >>> link-text-strategy("my link text")` 17:35:58 orkon: Proposal is to reuse selectors that were removed from the CSS spec. Would allow multiple stratgies for querying. 17:37:13 orkon: Would allow combining CSS selectors with locator stratgies that would follow a consistent sytax. WebDriver classic has a set of such stratgies already e.g. xpath. 17:37:23 q+ 17:37:32 ack whimboo 17:37:41 orkon: That's the proposal to discuss. 17:37:53 ack jdescottes 17:37:55 q+ 17:37:57 ack jgraham 17:40:33 q+ 17:40:37 jgraham: From a user point of view I see how this makes sense, but I'm worried about collisions with future CSS syntax, and also with how you would actually implement this. But I think we'd need to talk to the CSSWG with our use cases. 17:41:11 orkon: Some of this would be WebDriver specific, don't propose adding it to the actual selector engines. But more research is needed on how to avoid the compat hazard. 17:41:14 ack simons 17:42:43 simons: I'm normally a fan of pushing complexity into the remote end. But in this case I think this should be in the local end. We have the primitives in the spec to allow you to implement this in the spec, with the parsing happening on the local end. That would remove the worry about something colliding with future CSS. It also means that you can mix-and-match style as in the example. 17:43:24 simons: There is some precendent for pushing this kind of thing into clients e.g. orginal webdriver had find by element name, but that's now only implemented in client APIs rather than directly in the protocol. 17:43:28 ack JimEvans 17:44:43 JimEvans: I agree with simons. This sounds like something that from an implementation standpoint it feels like something that would mean that remote end implementations would have to develop a selector parser, and that seems like a complex thing to spec. So I think it should perhaps live in the local end. 17:44:54 q? 17:45:52 orkon: These are valid arguments. We do see many libraries implement this over and over again, and they aren't complatible with each other. Makes it harder to use the protocol directly. It's hard to spec well and avoid conflicts. I'm not sure about the best tradeoffs. 17:46:15 ScribeNickL orkon 17:46:18 ScribeNick: orkon 17:46:31 Topic: Pre-load script - support for custom browser to client messages 17:46:39 Github: https://github.com/w3c/webdriver-bidi/pull/361 17:48:12 jgraham (IRC): in December, we discussed how to implement sending custom messages from the browser to the client. We should implement by having a special type that serialised to a function that is when called sends a message. We have not considered how it interacts with preload scripts. But preload scripts don't accept arguments. We then thought we can convert scripts to functions. But there are some problems (see the issue). 17:48:57 jgraham (IRC): when you have arguments, you can pass any argument and provide a handle to an object but it does not exist in the preload script, so it fails every time the preload script runs. 17:49:16 jgraham (IRC): currently they are JS errors but actually are preload errors 17:49:56 jgraham (IRC): we have a couple of options 1) don't care about return values 2) throw a JS exception for arguments 3) or we can only have arguments that can be serialzed statically, no shared references 17:50:18 jgraham (IRC): there could be cases where shared references are needed but they are fragile 17:50:30 jgraham (IRC): there could be also events for the results of the preload scripts 17:50:43 q? 17:50:53 q+ 17:51:08 ack JimEvans 17:51:24 q+ 17:52:06 Jim Evans: I like the idea of being able to know the result of the preload result if we change them to be functions. I like an idea for the event containing a result or an error. But the clients don't need to subscribe to the event, if they don't need to. 17:52:56 Jim Evans: how does the remote end needs to do to raise the event? 17:52:56 jgraham (IRC): it deserialises to a function and the function emits the event 17:52:56 ack sadym 17:52:56 jgraham (IRC): it doest the impl magic to make the event emitte 17:52:56 s/emitte/emitted/ 17:53:49 q+ 17:54:28 sadym (IRC): arguments and events as the result sound reasonable. We can consider rolling back to the option with allowing only channels because the use case when we want to reuse the sharedId seems artificial. But it sounds like a slippery road to provide this functionality. 17:54:28 ack jgraham 17:55:02 jgraham (IRC): I think I agree with that. Realistically, passing primitive values does not make much sense. Passing sharedId only works in limited circumstances if you know that all preload scrips are in the same origin but I don't have a use case. 17:56:18 jgraham (IRC): my concern with the event is: obviously running a preload script can cause an exception and we emit it as a js error and you need to listen for log events to find that out. On other hand, if we had a specific event, then you kind of have to subscribe to it. E.g., if you had a bug where a preload script does not work, you would not know. 17:56:37 jgraham (IRC): perhaps we could parse the script early but not runtime exceptions 17:56:50 jgraham (IRC): I think none of the tradeoffs are great actually 17:56:50 q? 17:56:58 q+ 17:57:39 jgraham (IRC): I think I am going to try implementing changes in the PR to be the option: it is still a function, can accept only channels as args and all exceptions are js exceptions. If it is not an option, mention this now or comment on the issue. 17:57:40 ack sadym 17:58:21 sadym (IRC): what other option do we have if we rollback from callFunction to evaluate where there was a global handle to raise the event. 17:58:36 jgraham (IRC): I believe that does not solve any problems that channels don't solve 17:58:45 jgraham (IRC): no reason to prefer globals over channels 17:59:12 q+ 17:59:24 ack JimEvans 17:59:37 Jim Evans: looked at the print PR, nothing controversial. 18:00:19 RRSAgent: make minutes 18:00:20 I have made the request to generate https://www.w3.org/2023/02/08-webdriver-minutes.html jgraham 18:01:02 Zakim, bye 18:01:02 leaving. As of this point the attendees have been JimEvans, orkon, brwalder, whimboo, jgraham, patrickangle_, Sasha, jdescottes, sadym, simons 18:01:02 Zakim has left #webdriver 18:01:12 RRSAgent: bye 18:01:12 I see 1 open action item saved in https://www.w3.org/2023/02/08-webdriver-actions.rdf : 18:01:12 ACTION: whimboo to file a BiDi issue covering this scenario [1] 18:01:12 recorded in https://www.w3.org/2023/02/08-webdriver-irc#T17-33-21