search

GoogleChromeLabs / chromium-bidi

Implementation of WebDriver BiDi for Chromium
https://googlechromelabs.github.io/chromium-bidi/
Apache License 2.0
90 stars 31 forks source link

Navigating to some websites is not possible #2709

Open OrKoN opened 1 week ago

OrKoN commented 1 week ago 
import puppeteer from "puppeteer";

const browser = await puppeteer.launch({
    protocol: "webDriverBiDi"
});

const page = await browser.newPage();

await page.goto("https://x.com/"); // Crash!

await browser.close();

Results in

file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/common/CallbackRegistry.js:89
    #error = new ProtocolError();
             ^

ProtocolError: Protocol error (browsingContext.navigate): unknown error navigation canceled, as new navigation is requested by scriptInitiated Error
    at new UnknownErrorException (/Users/alexrudenko/src/pptr-test/node_modules/chromium-bidi/lib/cjs/protocol/ErrorResponse.js:122:39)
    at /Users/alexrudenko/src/pptr-test/node_modules/chromium-bidi/lib/cjs/bidiMapper/modules/context/BrowsingContextImpl.js:348:52
    at /Users/alexrudenko/src/pptr-test/node_modules/mitt/dist/mitt.js:1:255
    at Array.map (<anonymous>)
    at Object.emit (/Users/alexrudenko/src/pptr-test/node_modules/mitt/dist/mitt.js:1:239)
    at CDPClientAdapter.emit (/Users/alexrudenko/src/pptr-test/node_modules/chromium-bidi/lib/cjs/utils/EventEmitter.js:55:23)
    at #forwardMessage (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/bidi/BidiOverCdp.js:98:14)
    at file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/third_party/mitt/mitt.js:38:7
    at Array.map (<anonymous>)
    at Object.emit (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/third_party/mitt/mitt.js:37:39) at https://x.com/
    at <instance_members_initializer> (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/common/CallbackRegistry.js:89:14)
    at new Callback (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/common/CallbackRegistry.js:93:16)
    at CallbackRegistry.create (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/common/CallbackRegistry.js:19:26)
    at BidiConnection.send (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/bidi/Connection.js:51:32)
    at Session.send (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/bidi/core/Session.js:134:42)
    at Session.<anonymous> (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/util/decorators.js:96:27)
    at BrowsingContext.navigate (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/bidi/core/BrowsingContext.js:306:33)
    at BrowsingContext.<anonymous> (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/util/decorators.js:96:27)
    at BidiFrame.goto (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/bidi/Frame.js:336:22)
    at BidiFrame.<anonymous> (file:///Users/alexrudenko/src/pptr-test/node_modules/puppeteer-core/lib/esm/puppeteer/util/decorators.js:96:27)

Originally reported in https://github.com/puppeteer/puppeteer/issues/12929

OrKoN commented 1 week ago

@sadym-chromium would you be able to take a look?

sadym-chromium commented 1 week ago

on it

sadym-chromium commented 1 week ago

It looks like this is what WebDriver BiDi specifies to do:

  1. Puppeteer sends he command 'browsingContext.navigate' with wait: 'interactive' and url: 'https://x.com'. The navigation will be finished on 'domContentLoaded' or 'navigation failed' event.
  2. (for whatever reason I cannot get the response body of the initial navigation to https://x.com, so this is my speculation) x.com sets window.location to https://twitter.com/x/migrate?tok=....
  3. This causes navigation, and specifically this HTML spec step:
OrKoN commented 1 week ago

We looked offline and we could not confirm that unload counter step is actually the reason. At least, we should add a specific error code for this situation so that the client knows to wait for subsequent navigation IDs to implement waiting.

sadym-chromium commented 1 week ago

Spec:

juliandescottes commented 1 week ago

Spec:

* [`browsingContext.navigate`](https://w3c.github.io/webdriver-bidi/#command-browsingContext-navigate)

* [Aawait a navigation](https://w3c.github.io/webdriver-bidi/#await-a-navigation):

* [Navigate](https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate) navigable...

* [navigate](https://html.spec.whatwg.org/#navigate), step 22.3: [abort a document and its descendants](https://html.spec.whatwg.org/#abort-a-document-and-its-descendants) given navigable's [active document](https://html.spec.whatwg.org/#nav-document).

* [Abort a document and its descendants](https://html.spec.whatwg.org/#abort-a-document-and-its-descendants):

* [Abort a document](https://html.spec.whatwg.org/#abort-a-document)

* If document's [during-loading navigation ID for WebDriver BiDi](https://html.spec.whatwg.org/#concept-document-navigation-id) is non-null, then:

* Invoke [WebDriver BiDi navigation aborted](https://w3c.github.io/webdriver-bidi/#webdriver-bidi-navigation-aborted) (emits `browsingContext.navigationAborted` event).

* This case does not fall under **_"If event received is "navigation failed" return [error](https://w3c.github.io/webdriver/#dfn-errors) with [error code](https://w3c.github.io/webdriver/#dfn-error-code) [unknown error](https://w3c.github.io/webdriver/#dfn-unknown-error)"_**

* The command should **_"Return [success](https://w3c.github.io/webdriver/#dfn-success) with data body."_**

Thanks for checking this! So as it looks like we should not fail the navigation for abort scenarios? I assume the current tests at https://github.com/web-platform-tests/wpt/pull/48751 need to be updated to reflect this?

OrKoN commented 1 week ago

Spec:

* [`browsingContext.navigate`](https://w3c.github.io/webdriver-bidi/#command-browsingContext-navigate)

* [Aawait a navigation](https://w3c.github.io/webdriver-bidi/#await-a-navigation):

* [Navigate](https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate) navigable...

* [navigate](https://html.spec.whatwg.org/#navigate), step 22.3: [abort a document and its descendants](https://html.spec.whatwg.org/#abort-a-document-and-its-descendants) given navigable's [active document](https://html.spec.whatwg.org/#nav-document).

* [Abort a document and its descendants](https://html.spec.whatwg.org/#abort-a-document-and-its-descendants):

* [Abort a document](https://html.spec.whatwg.org/#abort-a-document)

* If document's [during-loading navigation ID for WebDriver BiDi](https://html.spec.whatwg.org/#concept-document-navigation-id) is non-null, then:

* Invoke [WebDriver BiDi navigation aborted](https://w3c.github.io/webdriver-bidi/#webdriver-bidi-navigation-aborted) (emits `browsingContext.navigationAborted` event).

* This case does not fall under **_"If event received is "navigation failed" return [error](https://w3c.github.io/webdriver/#dfn-errors) with [error code](https://w3c.github.io/webdriver/#dfn-error-code) [unknown error](https://w3c.github.io/webdriver/#dfn-unknown-error)"_**

* The command should **_"Return [success](https://w3c.github.io/webdriver/#dfn-success) with data body."_**

Thanks for checking this! So as it looks like we should not fail the navigation for abort scenarios? I assume the current tests at web-platform-tests/wpt#48751 need to be updated to reflect this?

I suspect it is not the intention not to fail here so perhaps we need to discuss what's expected in this situation.