1872307 - Cannot save JSON results from file:/// url or blob object URL

Status: RESOLVED FIXED

(DevTools :: JSON Viewer, defect, P3)

Description

[websitemakingguy+1]

Attachment: failed.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

Open a .json file on disk using file protocol (e.g. file:///c:/Users/hello/test.json) and then click the "Save" option in the JSON viewer

Actual results:

Firefox's download manager says the file download failed

Expected results:

File download fails

Comment 1

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

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

Comment 2

[Oriol Brufau [:Oriol]]

The browser console says:

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebBrowserPersist.saveURI]
    internalPersist chrome://global/content/contentAreaUtils.js:507
    continueSave chrome://global/content/contentAreaUtils.js:396
    internalSave chrome://global/content/contentAreaUtils.js:341

https://searchfox.org/mozilla-central/rev/6321fb8f7533456a62dfa2aa68ee0477a6c8f693/toolkit/content/contentAreaUtils.js#507

Regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=987ea0d6a000b95cf93928b25a74a7fb1dfe37b2&tochange=6c0fa9a675c91390ca27664ffb626c56e8afea4d

Suspect: https://hg.mozilla.org/mozilla-central/rev/9a2b02fe351bd65f6850a5c80b91dd0eec4a878a because of the changes in devtools/startup/devtools-startup.js

Comment 4

[:Gijs (out for now; he/him)]

Oddly, it's not the change in devtools-startup.js that broke this, but the change in internalSave that added an optional principal argument. One isn't passed in the flow where we call saveBrowser

So we try to save with the content principal in saveBrowser via internalSave and that won't work for file URLs opened in the JSON viewer, as the document's own principal is the resource URL for the JSON viewer, which isn't allowed to access arbitrary file URLs.

We could attempt to holepunch the JSON viewer specifically (there's already one for PDF.js in internalSave) but we'd have to be quite careful how we do it so we don't create a vector that allows a compromised content process to do arbitrary file writes.

As an aside, I was initially a little surprised that cmd/ctrl-s or "save page as" break in the same way here - but it's because they too call saveBrowser without any arguments so end up with the resource principal.

Nika, can you take a look at what you think the "right" solution here should look like? There's a similar-ish bug in bug 1872310 about blob: URIs that I imagine has a similar cause.

Comment 6

[Nika Layzell [:nika] (ni? for response)]

We might want to do something similar to what is done for PDF.js to ensure we talk to the webpage and get it to handle the save for us, and then save the JSON data which is known within the viewer's global rather than re-fetching the document from the network (which I believe is why we are getting the error in this situation).

When clicking save from within the json viewer itself, we already sometimes do this, as when prettified, we'll construct and save a blob URI from the prettified text content. I believe that we could theoretically also do this in the non-prettified case (with input.jsonText.textContent) to make the save action within the json viewer work, but that may not handle cases like cmd/ctrl-s and "save page as", meaning we'd likely need something similar to what we have for pdf.js form data.

Comment 7

[Julian Descottes [:jdescottes]]

Thanks for the input Gijs and Nika. The proposed solution makes sense, we can just use the blob approach for all the save actions in JSON viewer, and maybe have a followup for "save as" etc.

Matt: In your case, were you trying to save from JSON viewer in order to have a pretty-printed version of the JSON file?

Comment 8

[websitemakingguy+1]

I was more so interested in bug 1872310 where the JSON output was being generated by a web app that I wanted to save, in which case I didn't already have a copy of the file. I only reported this one because I came across it when trying to reproduce the bug in general. I don't really need to save a file again that I already have

Comment 9

[Julian Descottes [:jdescottes]]

Thanks for the feedback. The blob object use case makes sense, I'll update the title. Quick STRs:

• open a tab
• run URL.createObjectURL(new Blob([JSON.stringify({test: 1})], {type: "application/json"})) (eg with the devtools console)
• open the URL in a new tab
• the JSON will open in the JSON viewer
• click save

Comment 10

[Julian Descottes [:jdescottes]]

Also I can confirm that in this case, switching to "Raw data", clicking on "Pretty Print" and then hitting "Save" works

Comment 11

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

Set release status flags based on info from the regressing bug 1469916

Comment 12

[Connor Pearson]

I've encountered a similar issue when downloading JSON files from the viewer. I'm not sure if I should create a new bug since I believe it would also be fixed by Nika's solution.

In my case I'm opening a JSON file stored GitLab as a job artifact. When I click save I see in the browser toolbox that it sends another request for the JSON file, but the response is a 403 HTML page. Firefox saves this HTML instead of the JSON.

I'm not sure what difference in the request causes this behavior. I tried creating a simple reproduction with basic auth, but the download request includes the Authorization header so it works. However, something similar also happens with 404s.

• Create a HTTP server which serves a JSON file
• Open the JSON file
• Remove the JSON file
• Click Save

In this case the body of the 404 response is saved in the file. Does it make sense that the download succeeds if the response is not successful?

Comment 13

[:Gijs (out for now; he/him)]

The bug as filed was fixed by bug 1908629.

(In reply to Connor Pearson from comment #12)

I've encountered a similar issue when downloading JSON files from the viewer. I'm not sure if I should create a new bug since I believe it would also be fixed by Nika's solution.

In my case I'm opening a JSON file stored GitLab as a job artifact. When I click save I see in the browser toolbox that it sends another request for the JSON file, but the response is a 403 HTML page. Firefox saves this HTML instead of the JSON.

I'm not sure what difference in the request causes this behavior. I tried creating a simple reproduction with basic auth, but the download request includes the Authorization header so it works. However, something similar also happens with 404s.

• Create a HTTP server which serves a JSON file
• Open the JSON file
• Remove the JSON file
• Click Save

In this case the body of the 404 response is saved in the file. Does it make sense that the download succeeds if the response is not successful?

This is not yet fixed. I'll file a separate follow-up and copy you in.