Re: Interested in writing up an initial design for bidirectional WebDriver protocol

Hi,

I finally had a chance to sit down and read things! Some combined feedback:

The Good
 • JSON-RPC based
 • Exposing existing WebDriver functionality via the new protocol is good
  • Opens the door to implementing the existing protocol on the new one.
 • I quite like the section on establishing a bidi connection
  • I strongly dislike the “client can infer” approach to figuring out the bidi URL. Much prefer the explicit capability.
   • Also removes the ability for a service provider to redirect to another URL entirely
  • It’s not clear what the client is supposed to do with the WebSocket URL. You can’t make an HTTP GET over WebSockets, it’s just a dumb socket.
 • Generalising the window handle idea to all contexts is good.

Unsure
 • Using OpenRPC instead of OpenAPI.
  • Reasoning seems okay, but the W3C might want something more formal
 • How does a local end apply to receive multiple events?
  • eg. for the equivalent of a CDP domain?
  • Or do we imagine a flat namespace?
 • The ref counting for event calling would work, but I suspect that it’ll lead to unexpected behaviour
  • eg. in the example they give, the test code would still be receiving the events, even if they’d turned asked to no longer ask for events
  • Typically this is handled by attaching and detaching listeners, though this doesn’t fit with a low-impact way of mapping from the existing CDP approach
  • This seems like an implementation detail. Is it really needed in the spec? Browser implementors are smart enough to turn instrumentation on/off as needed.
 • To establish a bidi connection, we could assume that any WebSocket connection to /session would indicate that the client wants to use bidi
 • Differentiating all the contexts seems easy to implement, but confusing
  • We have a tuple of (id, type, parent) that effectively describes all contexts that are covered in this explainer. I’d suggest leaning into that
  • Internally, WebKit uses a frameID, so this should be straightforward... If a bit confusing and tedious for clients.
Notes
 • The original wire protocol had numerical status codes. “Nice” to see those are coming back.
 • The “message” in error objects should map to the error strings in the existing spec
 • The “data” in error objects should map to something similar to that in the existing spec.
  • Notably, the session id will be required
 • I imagine command ids will need to increment, though not necessarily monotonically
 • The section about targeting other contexts (eg. webworkers) with the current protocol implies that new functionality will also be available that way
  • Why not have the additional functionality be present only in the new version?
 • I’d suggest keeping the concept of the “default context”
  • Sending commands to an element would imply having switched to that context already
  • Receiving messages from an element implies that the message contains both the element id and the context id.
 • Once upgraded to bidi, do we want the original end points to continue working? Or is upgrading a “one way” operation, and all subsequent commands are expected to be sent via the bidi protocol?
  • I'd prefer to allow both, but this could lead to races if command processing is not serialized as it is now.
 • We need to understand how to communicate multiple error messages in one response (to maintain strict JSON-RPC compat, only one response message expected per command).
  • Web Inspector protocol may already deviates from this and allows multiple errors (or perhaps they are pasted together into one payload)
 • Sending ‘jsonrpc’: “2.0” in every command seems like a waste. Can it be dropped, if we’re already thinking of bending the JSON-RPC protocol…

Simon


> On 14 Jan 2020, at 22:35, John Jansen <John.Jansen@microsoft.com> wrote:
> 
> Hey all, 
> 
> We are thinking about talking about this at BlinkOn, and would love feedback (even a "this is crazy!!" or a "LGTM").
> 
> If you have a minute to check it out, please let us know what you think by posting an issue in the github repo.
> 
> Thanks!
> -John
> 
> Sent from Outlook <http://aka.ms/weboutlook>
> From: Brandon Walderman <brwalder@microsoft.com>
> Sent: Monday, December 9, 2019 2:38 PM
> To: public-browser-tools-testing@w3.org <public-browser-tools-testing@w3.org>
> Subject: RE: Interested in writing up an initial design for bidirectional WebDriver protocol
>  
> Hi folks,
>  
> I’ve published a pair of explainer documents to the MSEdgeExplainers repo (link below). The first document, “webdriver.md” outlines our team’s concept for a bidirectional WebDriver protocol and mostly explores how the existing WebDriver feature set might look in a bidirectional world. The next document, “bootstrap-scripts.md” takes a new feature that we touched on at TPAC 2019 and illustrates how that feature might work using the protocol outlined in “webdriver.md”. There’s also some protocol documentation (work-in-progress) alongside these explainers. I’m looking forward to hearing everyone’s thoughts.
>  
> https://github.com/MicrosoftEdge/MSEdgeExplainers/tree/master/WebDriverRPC <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Ftree%2Fmaster%2FWebDriverRPC&data=02%7C01%7CJohn.Jansen%40microsoft.com%7C1010804a7d6f468a4db408d77cf88e1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115279290818367&sdata=AFKFpa8%2Bq5BD4Q6ZFFimIIXs6Tizga8s8CuI%2BKv%2B7QA%3D&reserved=0>
>  
> Thanks,
> Brandon W.
>  
> From: Brandon Walderman <brwalder@microsoft.com> 
> Sent: Friday, October 18, 2019 2:00 PM
> To: public-browser-tools-testing@w3.org
> Subject: Interested in writing up an initial design for bidirectional WebDriver protocol
>  
> Hi folks,
>  
> I should have some spare cycles in the near future, and I'd like to take a stab at an initial design for the bidirectional WebDriver protocol. The purpose would be to get the ball rolling and get some early feedback on one possible approach. Would anyone mind if I go ahead with this? It would be in the form of an explainer written in markdown or google doc for now and I'd share it out as soon as it's ready to look at. The idea is not to write a spec draft yet but to put some thoughts on paper and see what others think. How does that sound?
>  
> Thanks,
> Brandon W.