chore(bidi): add support for browser.setDownloadBehavior

[hbenl]

Fixes #39305 and the following tests in Firefox:

• library/download.spec.ts:
  • "download event > should report download when navigation turns into download"
  • "download event > should work with Cross-Origin-Opener-Policy"
  • "download event > should report downloads with acceptDownloads: false"
  • "download event > should report downloads with acceptDownloads: true"
  • "download event > should report downloads for download attribute"
  • "download event > should save to user-specified path without updating original path"
  • "download event > should save to two different paths with multiple saveAs calls"
  • "download event > should save to overwritten filepath"
  • "download event > should create subdirectories when saving to non-existent user-specified path"
  • "download event > should report non-navigation downloads"
  • "download event > should report download path within page.on('download', …) handler for Files"
  • "download event > should delete file"
  • "download event > should expose stream"
  • "download event > should delete downloads on context destruction"
  • "download event > should delete downloads on browser gone"
  • "download event > should download large binary.zip"
  • "download event > should not fail explicitly to cancel a download even if that is already finished"
  • "download event > should report downloads with interception"
  • "download event > should emit download event from nested iframes"
  • "should be able to download a PDF file"
  • "should be able to download a inline PDF file via response interception"
  • "should save to user-specified path"
  • "should download successfully when routing"
• library/downloads-path.spec.ts:
  • "downloads path > should keep downloadsPath folder"
  • "downloads path > should delete downloads when context closes"
  • "downloads path > should accept downloads in persistent context"
  • "downloads path > should delete downloads when persistent context closes"
• library/defaultbrowsercontext-1.spec.ts:
  • "should support acceptDownloads option"

[github-actions]

Test results for "tests 1"

1 failed
❌ [playwright-test] › ui-mode-test-network-tab.spec.ts:371 › should not preserve selection across test runs @macos-latest-node20

6 flaky

⚠️ [chromium-library] › library/popup.spec.ts:258 › should not throw when click closes popup `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-page] › page/page-history.spec.ts:95 › goBack/goForward should work with bfcache-able pages `@chromium-ubuntu-22.04-node24`
⚠️ [firefox-library] › library/inspector/cli-codegen-1.spec.ts:1082 › cli codegen › should not throw csp directive violation errors `@firefox-ubuntu-22.04-node20`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:384 › should reveal errors in the sourcetab `@macos-latest-node20`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:812 › should update state on subsequent run `@macos-latest-node20`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:812 › should update state on subsequent run `@windows-latest-node20`

38565 passed, 843 skipped

---

Merge workflow run.

[hbenl]

Note that I added the test "should throw if browser dies" to the expectations file because of an issue with the current implementation of browser.setDownloadBehavior in Firefox, see https://bugzilla.mozilla.org/show_bug.cgi?id=2017252#c1.

[github-actions]

Test results for "MCP"

1 failed
❌ [msedge] › mcp/roots.spec.ts:47 › check that trace is saved in workspace @mcp-windows-latest

4882 passed, 135 skipped

---

Merge workflow run.

[yury-s]

Why is Bidi different here? If event.navigation is not unique, maybe we can just combine it with with even.timestamp to produce a UUID or have a mapping in the Bidi client Download->UUID ?

[hbenl]

event.navigation is unique and is still being used to identify the download.
The difference with Bidi is that the browsers use event.suggestedFilename as the filename for writing the download to disk (whereas with other protocols they use the ID that is passed to _downloadCreated() as the filename).

[yury-s]

How does it work if the user has two downloads with the same suggestedFilename, e.g. the user clicks twice on a link with download="foo.zip" attribute? If Firefox already modifies the suggested file name and guarantees its uniqueness, we can probably use it as the uuid or in that case we still need to change the logic of the download to use a different id for canceling download? Is there a plan to change the behavior to save the downloads with a guid file name and returning unmodified suggested file name in Bidi?

[hbenl]

e.g. the user clicks twice on a link with download="foo.zip" attribute

In that case the second download would get foo(1).zip as the suggestedFilename. So suggestedFilename is unique in the download folder at the time when the download is started but if a download gets cancelled and then another one started, they could get the same suggestedFilename.

If Firefox already modifies the suggested file name and guarantees its uniqueness, we can probably use it as the uuid or in that case we still need to change the logic of the download to use a different id for canceling download?

Cancelling downloads hasn't been added to the specification yet (w3c/webdriver-bidi#1031) but I don't expect it to use suggestedFilename to identify a download.

Is there a plan to change the behavior to save the downloads with a guid file name and returning unmodified suggested file name in Bidi?

No.

[yury-s]

let's use downloadFilename instead of useSuggestedFilename and avoid the variable with !:

const downloadPath = path.join(downloadsPath, downloadFilename ?? uuid);