Issue metadata
Sign in to add a comment
|
Chrome can't load file/image if it contains IDEOGRAPHIC SPACE U'3000/e38080
Reported by
athar...@gmail.com,
Aug 17
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. add ideographic space to any image file name on local drive 2. link to it in an html page as <img src="file://d:/mytest/special%e3%80%80space.jpg"/> 3. image broken, file couldn't be found this space is used in Japanese language and perhaps similar languages, if you switch to kana on IME on windows and type space, you get a slightly larger space that has hex e3 80 80 (utf-8) instead of 20. best way to reproduce is to use a hex editor. copy paste may convert it to normal space. What is the expected behavior? The image should be shown. it works on firefox. but not chrome. What went wrong? image broken. whether using hex encoding e.g. %e3%80%80 in img src or without. Did this work before? N/A Chrome version: 68.0.3440.106 Channel: stable OS Version: 10.0 Flash Version: Chrome is probably processing the url to normalize it, there might be problem in the normalization. I notice that chrome changes normal spaces to %20. while firefox doesn't do that.
,
Aug 17
I attached a file to test. if you drag and drop the file onto chrome address bar and hit enter. it will say "Your file was not found" if you rename the file and remove the big space, it will work. I'm not sure if alt-3000 would work. but can also be injected into a txt file using hex edit (e3 80 80) then copy paste the result. the attachment should work hopefully to reproduce the issue.
,
Aug 17
I see when downloaded, the file name is changed. but the name can be copied and pasted. テスト ファイル
,
Aug 19
,
Aug 20
Can confirm it's broken on Windows (but works on Linux), also it looks like we do get the proper path at //net level:
t=129379 [st=0] +REQUEST_ALIVE [dt=1]
--> priority = "HIGHEST"
--> url = "file:///C:/Users/morlovich/Downloads/%E3%83%86%E3%82%B9%E3%83%88%E3%80%80%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB.png"
t=129379 [st=0] URL_REQUEST_DELEGATE [dt=0]
t=129379 [st=0] +URL_REQUEST_START_JOB [dt=1]
--> load_flags = 18432 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE)
--> method = "GET"
--> url = "file:///C:/Users/morlovich/Downloads/%E3%83%86%E3%82%B9%E3%83%88%E3%80%80%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB.png"
t=129380 [st=1] -URL_REQUEST_START_JOB
--> net_error = -6 (ERR_FILE_NOT_FOUND)
t=129380 [st=1] URL_REQUEST_DELEGATE [dt=0]
t=129380 [st=1] -REQUEST_ALIVE
--> net_error = -6 (ERR_FILE_NOT_FOUND)
(Also this would probably need to be re-tested with the FileURLLoaderFactory-based path)
,
Aug 21
This is a result of tightening up on what characters we unescape in HTTP URLs for display - sadly, the same unescape logic is also used when loading file URLs from disk. :( This is definitely a bug that we need to fix.
,
Aug 22
Seems like a dupe of Issue 585422 , which was fixed in Chrome 69. (That was 2.5 months ago... sometimes it amazes me how far behind Stable is from tip-of-tree!) morlovich: You confirmed this. Were you testing on 68 or 69? Should not be an issue from 69 onwards. I just tested on Chrome OS 69 and could not reproduce.
,
Aug 22
The windows testing (which reproduced it) was on stable/68... Not sure of Linux-testing (which didn't) --- it's on Beta channel, so likely 69, but I am not sure if it was updated then. I will re-check on Windows canary.
,
Aug 23
Confirm works in 70.0.3530.0 canary
,
Aug 24
Thanks for checking. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by morlovich@chromium.org
, Aug 17