Saving a page with svgz files generates bad file set
Reported by
paul.leb...@gmail.com,
Oct 11 2016
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Extract the attached test case 2. Load test.html 3. Do a "Save as.." with "Webpage, Complete" 4. Attempt to load the saved page What is the expected behavior? Page displays correctly What went wrong? Broken image The svgz file is actually being saved as SVG plaintext with a .svgz extension. So Chrome thinks the content is corrupted. The original compressed version of the svgz file should be the one that is saved. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 53.0.2785.116 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 23.0 r0 Source of original report: http://stackoverflow.com/questions/39874475/chrome-not-rendering-svgz-from-local-file-but-does-render-svgz-from-server
,
Oct 11 2016
,
Oct 13 2016
Able to reproduce the issue on MAC 10.11.4, Windows 10 and Ubuntu 14.04 using chrome reported version #553.0.2785.116 and latest canary #56.0.2889.0 This is a non regression as it is observed from M30, M45 and M50 old builds. Hence, marking it as untriaged to get more inputs from dev team. Please find the attached screencast of the reported version for reference. Thanks,
,
Oct 13 2016
Typo in Chrome Version in the above comment. Chrome Version-53.0.2785.116.
,
Dec 15 2016
Lukasz can you take a look? If you don't have the cycles can you bump this to shaktisahu@ and give him some pointers on what you'd suggest doing?
,
Dec 15 2016
I am guessing that the problem is that: 1) http response indicates the mime type of the resource 2) the saved file doesn't explicitly indicate the mime type of the resource (so the browser has to guess the mime type based on the extension) 3) in this bug / repro steps, the extension doesn't quite match the mime type This problem is solved in MHTML, by including the mime type in the saved file. I am not sure how to solve this problem for Save-Page-As-Complete-Html format. I think we could try to generate better filenames - maybe the extension can be based on the actual mime type. Today, the filename is generated in SavePackage::StartSave, with the help from SavePackage::GenerateFileName. Today these methods don't take the mime type into account. I am not sure if the mime type (for deciding which filename extension to use) should be taken from 1) the network request kicked off by SavePackage or 2) sent by renderer in FrameHostMsg_SavableResourceLinksResponse. I think #2 sounds better for the long-term (given issue 158957).
,
Dec 15 2016
shaktisahu@, could you please take a look? I might be able to help in January.
,
Dec 15 2016
When it comes to regression tests, I think this bug can be potentially covered by a new SavePageOriginalVsSavedComparisonTest test in chrome/browser/downloads/save_page_browsertest.cc. OTOH, I am not sure about the details: 1. Current verification depends on ability to verify presence of expected content via Ctrl-F / find-in-page. This probably means that the subresource should have mime type = text/plain? 2. I am not sure how the subresource can be embedded in the page. Embedding via an iframe, will automatically force using .html extension (special cased today by SavePackage::GenerateFileName and |need_html_ext|). Embedding via something like <img> might or might not work. 3. I think that .mock-http-headers can be used to control mime type reported by embedded_test_server. If verification via Ctrl-F in SavePageOriginalVsSavedComparisonTest won't work, then we can always just verify presence of a saved file with the right extension (i.e. similarily to the verification done by SavePageBrowserTest.SaveDownloadableIFrame). |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by f...@opera.com
, Oct 11 2016