w3c / webdriver-bidi

Bidirectional WebDriver protocol for browser automation
https://w3c.github.io/webdriver-bidi/
363 stars 40 forks source link

websocketUrl is determined incorrectly if the browser is launched in a container #574

Closed DudaGod closed 11 months ago

DudaGod commented 11 months ago

I use selenoid to run browsers in docker containers. And run the code using bidi:

import {remote} from 'webdriverio';

let browser;

(async () => {
    try {
        browser = await remote({
            hostname: 'localhost',
            path: '/wd/hub',
            port: 4444,
            automationProtocol: 'webdriver',
            capabilities: {
                webSocketUrl: true,
                browserName: 'chrome',
                browserVersion: '112.0',
            },
        });

        await browser.sessionSubscribe({ events: ['log.entryAdded'] })

        browser.on('message', (data) => console.log('received %s', data))

        await browser.executeScript('console.log("Hello Bidi")', []);

        await browser.deleteSession();
    } catch (_) {
        if (browser) {
            await browser.deleteSession();
        }
    }
})();

When I run this script I get an error:

2023-10-19T12:01:35.529Z INFO webdriver: Register BiDi handler for session with id 858cc2297866dc9d3a321e89ac96c30a
2023-10-19T12:01:35.529Z INFO webdriver: Connect to webSocketUrl ws://0fd33d64b3b5:4444/session/858cc2297866dc9d3a321e89ac96c30a
node:events:505
      throw er; // Unhandled 'error' event
      ^

Error: getaddrinfo ENOTFOUND 0fd33d64b3b5

Where 0fd33d64b3b5 is a part of container id.

whimboo commented 11 months ago

Thanks for filing the issue but please note that this repository is for the WebDriver BiDi specification and not for remote end implementations or Selenium. If you could tell us for which browser it's not working we might help to forward this issue. Please note that for a container you most likely have to setup port forwarding given that otherwise a client that runs outside of docker would indeed not be able to access this given WebSocket.

diemol commented 11 months ago

Selenium Grid can alter the webSocketUrl in the response so it works for the bindings. Maybe Selenoid has that as well.

In any case, this is not a WebDriver BiDi issue, please reach out to the Selenoid project.

DudaGod commented 11 months ago

Thanks for filing the issue but please note that this repository is for the WebDriver BiDi specification and not for remote end implementations or Selenium.

I know it. I brought the issue here because I didn’t find the code responsible for modifying websocketUrl on selenium/selenoid/webdriverio side. And then I found that websocketUrl generated by browser (in my case in chrome). Locally with using webderiverio everything works fine. But when run chrome inside container I found strange behaviour, which described above.

If you could tell us for which browser it's not working we might help to forward this issue

In chrome.

Please note that for a container you most likely have to setup port forwarding given that otherwise a client that runs outside of docker would indeed not be able to access this given WebSocket

Yeah, I know it. But in my case host shouldn't consist of container id.

Selenium Grid can alter the webSocketUrl in the response so it works for the bindings. Maybe Selenoid has that as well.

Hm, I don't find where they replace it, search from source code. Looks like they just use what the browser returns.

In any case, this is not a WebDriver BiDi issue, please reach out to the Selenoid project.

Ok. Thank you.