JSON viewer redownloads http JSON files when saving (which breaks if the file is no longer available from the server)
Categories
(DevTools :: JSON Viewer, defect, P3)
Tracking
(Not tracked)
People
(Reporter: Gijs, Unassigned)
References
Details
From bug 1872307 comment 12:
(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?
Nika's suggestion from bug 1872307 comment 6:
(In reply to Nika Layzell [:nika] (ni? for response) from comment #6)
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.
Actually, re-reading those comments, I'm not clear on whether or not this is fixed - AIUI bug 1908629 was about getting the right cookies for requests like this, so perhaps the original case is fixed? It would still be useful to consider changing how we do saving for the JSON viewer to approximate the PDF.js scenario in order to avoid redownloading the content.
Connor, could you confirm if you're still seeing the gitlab issue with Firefox 130 (currently in beta) or later?
|
||
Comment 2•3 months ago
|
||
I tried out the GitLab scenario on 130.0b9 and it works well now. Thanks for the fix!
|
||
Comment 3•3 months ago
|
||
Ok so to be clear, the specific scenarios around downloads failing due to incorrect cookies are fixed, similarly the file and blob scenarios seems fixed.
Remains the issue for json files over the network when the file changed/is no longer available.
Description
•