chore(bidi): add support for the browsingContext.download* events

[hbenl]

Fixes #37217 and the following tests in tests/library/download.spec.ts in Chrome:

• "should report downloads with acceptDownloads: false"
• "should report proper download url when download is from download attribute"
• "should error when saving with downloads disabled"
• "should close the context without awaiting the download"
• "should be able to cancel pending downloads"
• "should download even if there is no "attachment" value"
• "should convert navigation to a resource with unsupported mime type into download"
• "should download links with data url"

Most of the download tests are still failing because Chrome sends the browsingContext.downloadEnd event with status: "canceled" and so methods like download.path() fail.
In Firefox the tests fail mostly because the browsingContext.downloadEnd event isn't implemented yet and so methods like download.path() hang.

[whimboo]

Fixes #37217 and the following tests in tests/library/download.spec.ts in Chrome:
Most of the download tests are still failing because Chrome sends the browsingContext.downloadEnd event with status: "canceled" and so methods like download.path() fail.

CC @OrKoN and @sadym-chromium given that you might be interested in those details. Looks like you may miss to update the status property in case of a successful download.

[whimboo]

In Firefox the tests fail mostly because the browsingContext.downloadEnd event isn't implemented yet and so methods like download.path() hang.

@hbenl, how many tests are these which are hanging? We probably should add them as timing out to the expectation file.

[OrKoN]

I think playwright is not using the latest chromium-bidi? Could that be bumped? The latest code looks correct https://github.com/GoogleChromeLabs/chromium-bidi/blob/main/src/bidiMapper/modules/context/BrowsingContextImpl.ts#L835 so it might be indeed cancelled?

[hbenl]

@hbenl, how many tests are these which are hanging? We probably should add them as timing out to the expectation file.

All of the tests in tests/library/download.spec.ts (36 in total) are hanging in Firefox, with or without this PR, and they're already in the expectations file.

[whimboo]

I think playwright is not using the latest chromium-bidi? Could that be bumped? The latest code looks correct https://github.com/GoogleChromeLabs/chromium-bidi/blob/main/src/bidiMapper/modules/context/BrowsingContextImpl.ts#L835 so it might be indeed cancelled?

I would suggest to get this done in a separate PR once this landed. Could you do this @OrKoN?

@hbenl, how many tests are these which are hanging? We probably should add them as timing out to the expectation file.

All of the tests in tests/library/download.spec.ts (36 in total) are hanging in Firefox, with or without this PR, and they're already in the expectations file.

Perfect. Then BiDi-wise this PR looks good to me. Thanks!

[OrKoN]

Bumping chromium-bidi here #37318

Actually I looked up existing tests and I think the headless shell would cancel all downloads by default (https://github.com/GoogleChromeLabs/chromium-bidi/blob/main/tests/browsing_context/test_download.py#L83) I think playwright might be using the headless shell for the headless mode? or is it running with chrome --headless? Feel free to file an issue for https://github.com/GoogleChromeLabs/chromium-bidi/issues if it still does not work.

[hbenl]

Bumping chromium-bidi here #37318

Actually I looked up existing tests and I think the headless shell would cancel all downloads by default (https://github.com/GoogleChromeLabs/chromium-bidi/blob/main/tests/browsing_context/test_download.py#L83) I think playwright might be using the headless shell for the headless mode? or is it running with chrome --headless? Feel free to file an issue for https://github.com/GoogleChromeLabs/chromium-bidi/issues if it still does not work.

I've rebased the PR but that didn't fix any tests in Chromium.
Then I tried running the tests in headed mode, in that case no additional tests are passing and the following tests are failing that pass in headless mode:

• "should report downloads with acceptDownloads: false"
• "should close the context without awaiting the download"
• "should be able to cancel pending downloads"

But in headed mode the failures that are not timeouts throw the error "Path is not available when connecting remotely. Use saveAs() to save a local copy." and I don't see a browsingContext.downloadEnd event from the browser.
I filed GoogleChromeLabs/chromium-bidi#3711.

[github-actions]

Test results for "tests 1"

5 flaky

⚠️ [firefox-library] › library/inspector/cli-codegen-1.spec.ts:1079 › cli codegen › should not throw csp directive violation errors `@firefox-ubuntu-22.04-node18`
⚠️ [firefox-page] › page/page-event-request.spec.ts:182 › should return response body when Cross-Origin-Opener-Policy is set `@firefox-ubuntu-22.04-node18`
⚠️ [firefox-page] › page/page-network-response.spec.ts:301 › should return body for prefetch script `@firefox-ubuntu-22.04-node18`
⚠️ [chromium-library] › library/popup.spec.ts:258 › should not throw when click closes popup `@ubuntu-22.04-chromium-tip-of-tree`
⚠️ [webkit-library] › library/browsercontext-add-cookies.spec.ts:426 › should allow unnamed cookies `@webkit-ubuntu-22.04-node18`

46762 passed, 819 skipped

---

Merge workflow run.

[yury-s]

I think playwright might be using the headless shell for the headless mode? or is it running with chrome --headless?

Yes, by default we run with headless shell, unless users explicitly opt-in to the new headless, see https://playwright.dev/docs/browsers#chromium-new-headless-mode

[yury-s]

Does it mean the code only applies to the navigations converted into downloads or what is this check for?