Meeting minutes
<jgraham> RRSAgent: make logs public]
<jgraham> RRSAgent: make logs public
<jgraham> RRSAgent: make minutes
Awaiting review
<jgraham> Network module: w3c/
<orkon> jgraham (IRC): first PR to review is the network module
<jgraham> Input module: w3c/
<orkon> the other one is the input module
<sadym> I removed the "sharedID" from the agenta, as it was merged
<orkon> 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
Sandboxed script execution
<jgraham> GitHub: w3c/
<orkon> 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?
<orkon> 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
<orkon> 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.
<orkon> 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.
<sadym> + for creating new issue for details
<jgraham> 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.
<jgraham> orkon: This will cause a failing test in CDP-backed puppeteer in Firefox
Serialization of platform objects - special type & value?
<jgraham> GitHub: w3c/
<orkon> 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?
<orkon> 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.
<orkon> jgraham (IRC): not sure if it's a good design, but it is the logic of the current spec
<orkon> 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.
<orkon> 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.
<orkon> jgraham (IRC): the current spec is at least internally consistent and we should make a case for changing it
<orkon> 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.
<orkon> whimboo: not sure if we can some feedback from Selenium
<orkon> 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.
<orkon> jgraham (IRC): value is not meant to determine what is a platform object or not. It's a feature by accident.
<orkon> jgraham (IRC): maybe we should be completely consistent between js and platform objects and allow means for setting depth.
<orkon> jgraham (IRC): currently we set it to 1 in may places
<orkon> 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.
<orkon> jgraham (IRC): clients should really be able to handle both cases: missing and empty value
<orkon> @jp
<orkon> jgraham (IRC): I mean in either case the clients should handle both cases. (Note: missed a sentence about CDP)
Classic: Handle cases where a navigation happens during script execution
<jgraham> Github: w3c/
<orkon> 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
<orkon> 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?
<patrickangle_> +1 for
<orkon> 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
<orkon> 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 correctness.
<jgraham> I think I prefer JavascriptError, just because I expect clients to handle it somehow, even though technically no such window is providing more information
<orkon> 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?
<orkon> sadym (IRC): sending an error with no window sounds good. But when will the exception happen?
<orkon> jgraham (IRC): in classic there is a navigation event and it would be right to handle it as part of the unload handler
<orkon> whimboo: should we also have something similar in bidi?
<orkon> jgraham (IRC): technically the bidi client can handle unresolved promises but perhaps it should be rejected on navigation
<orkon> whimboo: should we file a separate issue for bidi?
<orkon> whimboo: AI: to file an issue
ACTION: whimboo to file a BiDi issue covering this scenario
Shadow DOM selectors in WebDriver (BiDi)
<jgraham> github: w3c/
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.
<orkon> `div > some-host >>> link-text-strategy("my link text")`
orkon: Proposal is to reuse selectors that were removed from the CSS spec. Would allow multiple stratgies for querying.
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.
orkon: That's the proposal to discuss.
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.
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.
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.
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.
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.
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.
ScribeNickL orkon
Pre-load script - support for custom browser to client messages
<jgraham> Github: w3c/
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).
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.
jgraham (IRC): currently they are JS errors but actually are preload errors
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
jgraham (IRC): there could be cases where shared references are needed but they are fragile
jgraham (IRC): there could be also events for the results of the preload scripts
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.
Jim Evans: how does the remote end needs to do to raise the event?
jgraham (IRC): it deserialises to a function and the function emits the event
jgraham (IRC): it doest the impl magic to make the event emitted
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.
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.
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.
jgraham (IRC): perhaps we could parse the script early but not runtime exceptions
jgraham (IRC): I think none of the tradeoffs are great actually
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.
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.
jgraham (IRC): I believe that does not solve any problems that channels don't solve
jgraham (IRC): no reason to prefer globals over channels
Jim Evans: looked at the print PR, nothing controversial.
<jgraham> RRSAgent: make minutes