Images, links, etc. using relative URIs don't work on local HTML files loaded using content:// URIs
Reported by
jh-goo...@buttercookie.de,
Mar 31 2018
|
|||||||||
Issue descriptionExample URL: Steps to reproduce the problem: 1. Save/create a local HTML file that references some images using a relative path (see e.g. the contents of the attached archive). 2. Copy that HTML file and its associated file/directory structure to your phone. 3. Use Android's built-in file explorer (Settings -> Storage) to navigate to that HTML file, click on it and open it in Chrome. What is the expected behavior? The HTML document is displayed correctly, including the images. Clicking a link to another locally stored HTML file works. What went wrong? The image isn't displayed and clicking on the link yields a ERR_FILE_NOT_FOUND. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? N/A Chrome version: 65.0.3325.109 Channel: stable OS Version: Android 6.0.1 Flash Version: Opening content:// URIs in Chrome Canary is currently broken, see https://bugs.chromium.org/p/chromium/issues/detail?id=827796. Working in Firefox, although only because they are still using file:// URIs.
,
Apr 2 2018
@jh-google: Thanks for the report!! Could you please help us with a screencast to check the issue from our end? Thanks!!
,
Apr 4 2018
,
Apr 5 2018
Reproduced on Chrome Beta (66.0.3359.82) / Android 8.1.0. I've stored the contents of the attached zip under the download folder, and opened a.html. It opened with the following url: content://com.android.providers.downloads.documents/document/raw%3A%2Fstorage%2Femulated%2F0%2FDownload%2Ftest%2Fa.html. Relative url "img/dot.png" was resolved to content://com.android.providers.downloads.documents/document/img/dot.png. It doesn't work because "raw%3A%2Fstorage%2F..." part is missing. For me, clicking a link with relative URL didn't work too, as it opened content://com.android.providers.downloads.documents/document/b.html.
,
Apr 5 2018
> It doesn't work because "raw%3A%2Fstorage%2F..." part is missing. Interesting, although I wonder - even if that issue was resolved and we'd be guessing the correct url to use for the documents provider, wouldn't we possibly run into the issue that we might not actually have the permission to actually open that file, since by default a content url only grants permissions for that specific file and nothing else? Note that I've also opened a corresponding Android bug for this more general drawback of conent:// urls for this use case: https://issuetracker.google.com/issues/77406791
,
Aug 31
I'm not sure if we want to support the feature. I don't know the correct component as well. Cc-ing some chrome/android owners. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by pnangunoori@chromium.org
, Apr 2 2018