Issue metadata
Sign in to add a comment
|
U+2001 does not render in URL properly for local files and ends in Error.
Reported by
abhinic...@gmail.com,
May 9 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3425.0 Safari/537.36 Steps to reproduce the problem: 1. Create a local directory in any drive named ' ' only with the character between single quote. 2. Create/Copy any single text/PDF file in this folder. 3. Open this file and it shows this message: Your file was not found It may have been moved or deleted. ERR_FILE_NOT_FOUND 4. URL shows this path: file:///D:/Abhinickz/%E2%80%81/test.pdf What is the expected behavior? 1. URL should resolve to: file:///D:/Abhinickz/ /test.pdf Tested on Current latest Stable Chrome Version. What went wrong? URL resolved to: file:///D:/Abhinickz/%E2%80%81/test.pdf With ERROR: Your file was not found It may have been moved or deleted. ERR_FILE_NOT_FOUND instead of Error, File should be open in browser. Did this work before? N/A Chrome version: 68.0.3425.0 Channel: canary OS Version: 10.0 Flash Version:
,
May 9 2018
Yes, It(%E2%80%81) is a white-space character.
,
May 9 2018
It's not safe to display weird spaces in the omnibox for a number of reasons, though files with such paths should presumably be accessible via file URLs.
,
May 9 2018
>It's not safe to display weird spaces in the omnibox for a number of reasons. Yes, It is not safe But I am not sure about whether it is shows the character in case of Web URL. > though files with such paths should presumably be accessible via file URLs. File URLs are accessible with the Current Stable Chrome Version.
,
May 9 2018
abhinickz6@, it sounds like you're saying this is a regression. Is that right? It worked before (current stable) and doesn't work now (current dev)?
,
May 9 2018
This would be because of https://chromium-review.googlesource.com/c/chromium/src/+/1014367 - no bisect needed. The entire unescaping logic is a bit of a mess, unfortunately, with different consumers wanting very different behavior.
,
May 10 2018
Updating title to properly reflect the character in question: U+2001 EM QUAD. Interesting, I think this may actually be a dupe of Issue 585422 (which I was investigating for awhile but I never solved), which happened when we blacklisted U+1F512 LOCK using the same mechanism. I suspect whatever system is translating file:// URLs into filesystem paths is using the escaping logic, but should actually be using UnescapeBinaryURLComponent (since it is never correct to leave percent-encoded bytes in a file path. To be clear, file:///D:/Abhinickz/%E2%80%81/test.pdf is correct to *display* in the URL bar, but it is likely that we're searching on disk for the file D:\Abhinickz\%E2%80%81\test.pdf, where we should be searching for D:\Abhinickz\ \test.pdf.
,
May 10 2018
Confirmed that this is a bug (file:///tmp/%E2%80%81/test.pdf), and I also confirmed that a padlock URL (file:///tmp/%F0%9F%94%92/test.pdf) has the same problem. So this is Issue 585422 and it looks like elawrence did some analysis in there (which seems correct) so I'll continue discussing there. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by morlovich@chromium.org
, May 9 2018Status: Untriaged (was: Unconfirmed)