1799340 - Download fails to start if window is immediately closed

Status: REOPENED

(WebExtensions :: Untriaged, defect, P5)

Description

[jpd236]

Attachment: extension.zip

Steps to reproduce:

Install the attached sample extension. It shows a simple page, waits 2 seconds, attempts to trigger a text file download (by creating an <a> element w/ a download+href attribute and calling click() on it) and then closes itself.

Actual results:

The download fails to start - the popup just closes.

Expected results:

The download should have started. It starts reliably on Chrome, and it starts if I add some arbitrary delay (e.g. setTimeout with a 1ms delay) before calling window.close(), but not if I immediately close it after calling click() on the <a> element.

This is a distilled sample to reproduce an issue I'm seeing in a real-world extension which extracts data from a page and downloads it. If I try to automatically close the extension popup after starting the download, it does not start reliably on Firefox. It seems to reliably work if I had a 100ms delay, but in that case, 1ms doesn't work 100% of the time, and in any event an arbitrary delay doesn't seem like it should be necessary.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (108.0a1/20221107212933), Beta (107.0b9/20221103190044) and Release (106.0.5/20221104133228) under Windows 10 x64 and Ubuntu 16.04 LTS.

After clicking the extensions toolbar icon, a pop-up is displayed which persists for about 2 seconds as described and then closes itself. No download is triggered.

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

The extensions could be using the downloads API if the download shouldn't be tied to the lifetime of that extension page.

Closing as wontfix because the described behavior is likely to be triggered by assumptions made at a platform level and the same behavior expected if the download was going to be triggered from a webpage or an extension page loaded in a tab that is being closed right away by the user.

Comment 4

[jpd236]

Attachment: updated extension demonstrating issue with browser.downloads API

Comment 5

[jpd236]

Thank you for the reply!

Unfortunately, the problem appears to happen just the same when using the browser.downloads.download API (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/downloads/download). I've attached a revised extension to demonstrate. The window.close() call is chained to the Promise returned by the download() call, so in theory that should mean that the download started successfully. But it is still highly likely to fail unless there is a delay before closing the window.

We could go one step further and monitor for download completion before closing the window, but I would argue that this shouldn't be necessary, and would be a worse experience for larger downloads. (As a less vital point, using the downloads API is less ideal since it requires an additional permission + consent, vs. emulating a link click. But if this were the only issue, that seems acceptable).

Regarding your point that the same behavior would happen if the tab is closed by the user, IMO the key here though is that the user has the ability to respond to the indication that the download has started before closing it. In contrast, the extension doesn't appear have a reliable way of knowing that the download has started, so it has no way of safely implementing the same approximate behavior.

I hope it's not rude of me to reopen this particularly in light of the issue impacting the download API, which feels like pertinent information to consider. But please let me know if I've misunderstood anything (or if the example isn't doing what it purports to do).

Comment 6

[Tomislav Jovanovic :zombie]

You could probably await the downloads.onCreated event, or send a message to the background page and start the download from there.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/downloads/onCreated

Otherwise, what you're trying to do is inherently racy, as there are multiple processes and async tasks. Since workarounds exist, this is unlikely to be a priority to fix.