PDF won't download or load on homedepot.ca

[anikiki]

Task/Issue URL: https://app.asana.com/1/137249556945/project/488551667048375/task/1211134676219652?focus=true

Description

Added User-Agent header to file downloads to ensure proper handling by servers. This PR:

• Adds a userAgent parameter to the PendingFileDownload class
• Passes the User-Agent from the browser to download requests in BrowserTabFragment, DuckChatWebViewFragment, and SubscriptionsWebViewActivity
• Updates the download service to include the User-Agent header in requests

Steps to test this PR

File Downloads

• Download a file from a website that checks User-Agent headers
• Verify the download starts and completes successfully
• Test downloads from BrowserTabFragment
• Test downloads from DuckChat
• Test downloads from Subscriptions screen
• Test retrying a failed download to ensure User-Agent is preserved

NO UI changes

---

Note

Ensures servers receive a proper User-Agent during downloads and adds a resilient fallback when HTTP/2 breaks.

• Adds userAgent to PendingFileDownload and threads it through workers (FileDownloadWorker), receivers, and callers (BrowserTabFragment, DuckChat, Subscriptions)
• Updates DownloadFileService to send User-Agent for both HEAD and streaming GET
• Refines ApiRequestInterceptor to skip adding User-Agent if already present and to use WebView UA for re-query pixels
• Introduces HTTP/1.1-only OkHttp/Retrofit (@Named("downloadsHttp1")) and DI wiring; provides @Named("http1Fallback") DownloadFileService
• Enhances UrlFileDownloader to include UA, handle StreamResetException, and retry via HTTP/1.1 client; cleans up on cancel/failure
• Adds required module deps and updates tests to reflect new headers and fallback path

^{Written by Cursor Bugbot for commit f4cba05. This will update automatically on new commits. Configure here.}

[anikiki]

• PDF won't download or load on homedepot.ca #7543 👈 (View in Graphite)
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

HTTP/1.1 retry error handling discards actual failure reason

Low Severity

When the HTTP/1.1 fallback download fails, the else branch hardcodes ConnectionRefused as the error reason instead of extracting it from retryResult. Since retryResult can be a DownloadResult.Error containing a different reason (like Other when writing to disk fails), the actual failure reason is lost. This causes users to see downloadsErrorMessage instead of downloadsDownloadGenericErrorMessage for disk-write failures, showing an incorrect error message.