serenity icon indicating copy to clipboard operation
serenity copied to clipboard

WebDriver: Missing endpoints

Open AtkinsSJ opened this issue 3 years ago • 5 comments

WebDriver is the API for remote-controlling a Browser process, as used by WebPlatformTests. It has a lot of different endpoints, so to make it clear which ones are missing, here's a handy list!

To add an endpoint you'll need to modify the code in two places: The WebDriver end at Userland/Services/WebDriver, and the Browser end at Userland/Services/WebContent/WebDriver*. Comment here or refer to this issue in your PR to get your endpoints checked off the list. :^)

You can find the same table in the spec at https://w3c.github.io/webdriver/#endpoints

AtkinsSJ avatar Oct 12 '22 10:10 AtkinsSJ

Hey! This will probably seem a really dumb off-hopic noob question jumping onto a tracking issue, so I'm sorry but I was wondering if you folks plan to support WebDriver Bi-directional that utilizes WebSocket?

I thought it was a really useful protocol, and I had a lot of success using an prototype/prehistory implementation of it (Chrome Remote Debugging Protocol / Chrome DevTools Protocol) to create a virtualized remote isolated Browser (BrowserBox).

crisdosaygo avatar Jun 18 '23 10:06 crisdosaygo

Hey! This will probably seem a really dumb off-hopic noob question jumping onto a tracking issue, so I'm sorry but I was wondering if you folks plan to support WebDriver Bi-directional that utilizes WebSocket?

I thought it was a really useful protocol, and I had a lot of success using an prototype/prehistory implementation of it (Chrome Remote Debugging Protocol / Chrome DevTools Protocol) to create a virtualized remote isolated Browser (BrowserBox).

Hi! I don't know about anyone else but I hadn't heard of the BiDi extension before. We don't really do plans, but that does seem interesting.

The main (only?) reason we're attempting to get WebDriver working is to be able to run the WPT test suite. So that's the focus here for now. But that does look like it would be convenient for building the browser devtools on top of, so we'll see.

AtkinsSJ avatar Jun 18 '23 11:06 AtkinsSJ

Hey @AtkinsSJ Cool! Yes, it is useful for DevTools. In fact, as you probably already know, the Chrome DevTools is basically a front-end web app interface with functionality to instrument the browser built entirely using these protocol commands (I think ~~ I'm no expert!). The use of the protocol without WebSocket (using HTTP requests) may introduce some weird lag for some things you want to do.

Thanks for your reply, @AtkinsSJ and cool to hear you don't do plans! Very fun! :)

crisdosaygo avatar Jun 18 '23 12:06 crisdosaygo

Hi! Just a quick fly-by comment re: webdriver bidi and devtools. As we're implementing WebDriver BiDi in Firefox, we built a small devtools-like frontend at https://github.com/firefox-devtools/bidi-webconsole-prototype

At the moment we only added a "webconsole" and a "netmonitor" (which is really just a list of request), but you could easily do more. We don't really have debugging APIs on the roadmap for the spec yet (https://github.com/w3c/webdriver-bidi/issues/), but maybe in the future we could imagine having a cross browser devtools based on webdriver bidi.

juliandescottes avatar Feb 20 '24 14:02 juliandescottes

That's awesome! That is so cool, @juliandescottes. Really happy to see some external devtools that uses the protocol! 😃

crisdosaygo avatar Feb 21 '24 03:02 crisdosaygo