1338981 - Exporting files via Javascript in WebExtension Settings does not Work

Status: RESOLVED DUPLICATE of bug 1331176

(WebExtensions :: Untriaged, defect)

Description

[Kenny D]

Attachment: Test Extension

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170212004007

Steps to reproduce:

Other people are having this problem too.
https://discourse.mozilla-community.org/t/bug-exporting-files-via-javascript/

1. Load temporary the manifest.json file.
2. Open the settings of the extension and click the test button.


Actual results:

The contents of the text file is displayed in the browser.


Expected results:

Firefox should have downloaded the text file instead. This works correctly in Chrome and if you open the test.html directly in Firefox.

Comment 1

[Niklas Gollenstede]

I have downloaded the attached extension and installed it in two profiles.
In one of them the down load works, in the other the URL is opened in the same tab.
When I tried a blob:-URL instead of the data:-URL, it worked in the first profile, and in the second profile the tab turned completely blank and displayed the connecting favicon, but didn't change the displayed URL or pushed a state to the tabs history.

Comment 2

[Andy McKay]

I'm unclear on why it should do this. In this case you've made a link containing data: and then clicked it. If you do that in a regular web page in Firefox and click on it you get the same effect, Firefox just opens the data, the same as Chrome. It's only in a extension context (moz-extension or chrome-extension) that Chrome and Firefox do something different.

If you want to export data, you can call the downloads.download(..) method and pass a blob through to it. It's actually a bit more concise than what you have and will be consistent across all browsers.

Comment 3

[Niklas Gollenstede]

> If you do that in a regular web page [...], Firefox just opens the data, the same as Chrome

No. If you click a link with a download="file.name" attribute, the browser should and usually does offer the file of download instead of opening it. This already is/should be "consistent across all browsers".

> you can call the downloads.download(..)

That would require an extra permission to do something every normal website is able to do.
Specifying "downloads" as a permission only to, for example, export the preferences doesn't seem appropriate to me.

And besides, this really shouldn't depend on the profile it is in.

Comment 4

[Andy McKay]

(In reply to Niklas Gollenstede from comment #3)
> No. If you click a link with a download="file.name" attribute, the browser
> should and usually does offer the file of download instead of opening it.
> This already is/should be "consistent across all browsers".

Ah I missed the download part in the example, thanks.

Comment 5

[Niklas Gollenstede]

Ok ^^

Regarding

> When I tried a blob:-URL [...] the tab turned completely blank and displayed the connecting favicon, but didn't change the displayed URL or pushed a state to the tabs history.

I have to add that I waited 1000ms to revoke the URL, that should have been enough tome to (failing to offer it for download) display it, instead of completely hanging up.

Comment 6

[:shell escalante]

please re-open if questions still exist

Comment 7

[Niklas Gollenstede]

Citing myself again

> it worked in the first profile, and in the second profile the tab turned completely blank and displayed the connecting favicon

"WORKSFORME" hardly seems like a solution to that -.-

Comment 8

[Andrew Swan [:aswan]]

(In reply to Niklas Gollenstede from comment #5)
> I have to add that I waited 1000ms to revoke the URL, that should have been
> enough tome to (failing to offer it for download) display it, instead of
> completely hanging up.

I think there was meant to be a comment along with resolving the bug, but what you describe is consistent with the blob being revoked too soon.  Using a timeout is a recipe for unreliable code that fails intermittently.  In the short term you can try increasing the timout, but in the long run, I think you'll be happier if you can figure out through some other means when the download is finished and only revoke the url after that.

Comment 9

[Niklas Gollenstede]

> Using a timeout is a recipe for unreliable code that fails intermittently.

I agree. Even though I think the timeout already is multiple times higher than necessary.

> if you can figure out through some other means when the download is finished and only revoke the url after that.

I am reasonably sure that's impossible. But it is also besides the point of this bug.

> what you describe is consistent with the blob being revoked too soon

If the blob was revoked to soon, I think the expected behavior should be that nothing happens, not that (from comment #1)

> the tab turn[s] completely blank and display[s] the connecting favicon [indefinitely], but didn't change the displayed URL or pushed a state to the tabs history.

---

I think this bug is actually related to bug 1347022.

So please allow me to rephrase the bug description: 

Steps to reproduce:

1. Download and unpach the "Test Extension Version 2".
2. Launch FF with 'browser.tabs.remote.autostart.2' set to true.
3. Load the simple test plugin using "Load temporary add-on".
4. Click on the options button.
5. In the tab that opens, click on the save button.
6. Notice no download and the symtoms described in comment #1 (Actual results).
7. Now set 'browser.tabs.remote.autostart.2' to false.
8. Restart the browser.
9. Load the simple test plugin using "Load temporary add-on".
10. Click on the options button.
11. In the tab that opens, click on the save button.
12. The browser prompts to open or save a JSON file (Expected results).

Actual results:

The tab turns completely blank and displays the connecting favicon indefinitely, but didn't change the displayed URL or pushed a state to the tabs history.
No download happens.

Expected results:

The browser prompts to open or save a JSON file.

Note: The blob:-URL is never revoked.

Comment 10

[Niklas Gollenstede]

Attachment: Text Extension Version 2.zip

See comment 9