Resources in MHTML saved from local files are not shown
Reported by
haiku...@gmail.com,
Sep 18 2016
|
|||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Example URL: https://www.wikipedia.org/ Steps to reproduce the problem: 1. Open https://www.wikipedia.org/ 2. Save it to local file - Complete Web Page (html + folder with images, css etc). 3. Open locally saved file in Chrome. All images and resources are displayed fine. 4. Save locally opened file to Single MHTML file. 5. Open MHTML file in Chrome - images and css resources, described in file, are not shown. 6. Open the same MHTML in Firefox / IE - page displayed with images and styles. 7. Pages saved from local HTML files in IE / Firefox to MHTML format are also displayed without resources in Chrome. What is the expected behavior? Irrespectively of data source (internet page or local HTML file) Chrome should properly display all resources saved in MHTML. What went wrong? Chrome does not show resources (css, images) in MHTML pages saved from local HTML file (i.e. not site). 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? Yes Chrome version: 53.0.2785.116 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 23.0 r0 Please see the screenshots attached.
,
Nov 8 2016
Reproduced on: Chrome 56.0.2913.0 on Windows 7 Chrome 54.0.2840.71 on Windows 7
,
Nov 10 2016
When I saved MHTML from locally-saved HTML, the URLs for the HTML and embedded images have file:// scheme, and the access to the embedded image is rejected because the URL is local, just like http:// pages are rejected to access local files. The request to the embedded image fails because SecurityOrigin::canLoadLocalResources() returns false (called from FrameFetchContext::canRequestInternal() called from FrameFetchContext::canRequest()). We might allow MHTML archive to access local file:// URLs if the URL is in the archive (and thus actual local file is not accessed and the embedded image file is displayed instead), but I'm not sure about its security implication.
,
Nov 22 2016
+mkwst, do you see anything wrong with allowing MHTML archives to access file URLs in the archive? Sounds relatively benign to me.
,
Nov 23 2016
Can we distinguish between locally-stored resources that were originally same-origin with the HTML file, and those that weren't? As I recall, we can't. We currently err on the side of turning the MHTML bundle into a unique origin, and follow all the SOP rules that come along with it. Until something fundamental changes (https://discourse.wicg.io/t/proposal-packaging-for-the-web-signed-and-indexed/1827, for example), it doesn't seem prudent to change that stance.
,
Nov 23 2016
Ah good point, let's mark this as WontFix for now then. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by dtapu...@chromium.org
, Sep 20 2016