intoli / remote-browser

A low-level browser automation framework built on top of the Web Extensions API standard.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Consider Selenium/WebDriver compatible API

vitalets opened this issue · comments

Supporting Selenium JavaScript API would be great as it seems to be more popular that WebExtensions API.
For example, navigation to url can be done in Selenium terms:

await driver.get('https://intoli.com');

instead of:

browser.tabs.create({ url: 'https://intoli.com' });

PS: some time ago I've made similar project - autotester. It's a browser extension that transforms selenium commands into WebExtensions API calls. Maybe it would be useful.

@vitalets Thanks for sharing this, it's really neat. We absolutely agree that the Web Extensions API isn't quite as user-friendly as some other APIs when it comes to automated testing. We like to think of Remote Browser as being more analogous to something like the Chrome DevTools Protocol than to Puppeteer. It's probably not the tool that you would want to use directly for automated testing, but it makes it easy to build higher-level APIs. If Remote Browser can handle launching browsers, connecting to them, remote code execution, remote error proxying, and other things like that, then those are things that you don't need to worry about when building a higher-level API.

Any library which takes a browser object upon initialization should be able to mostly work out of the box both directly inside of extensions, as with autotester, and also with Remote Browser. We actually have some higher-level APIs in the works right now that function in this way, and we're really excited to get them out there in the near future. I haven't dug into the autotester code yet, but there's a good chance that the Selenium/Extension mappings could be relatively easily adapted to this sort of interface.

I'm going to close the issue because we believe that higher-level APIs are best suited for separate projects like I described above. The core Remote Browser API will always be tightly coupled with the Web Extensions API, but we're highly supportive of high-level APIs being built on top of it.

Ok, thanks for detailed explanation! 👍