Issue metadata
Sign in to add a comment
|
Windows local file PDF Paths with # symbol fail
Reported by
andyst...@gmail.com,
Jan 7 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Example URL: Create a local pdf on Windows with a (#) hash symbol in the path Steps to reproduce the problem: 1. Create a file or folder on Windows with # (hash) symbol 2. Associate .pdf files with Google Chrome 3. Attempt to open to file via double click 4. File not found tab appears instead of file Note: Look at the address bar and note that the slash near the # (hash) symbol is not reversed from backslash to forward slash. What is the expected behavior? PDF File opens correctly What went wrong? Path back slash to foward slash replacement issue for Windows paths Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0
,
Jan 13 2017
1.Could you please confirm that are you creating a new folder in system using # symbol? 2.Are you making chrome browser as your default pdf reader. If yes, how? Could you please help us by providing the above details for further triage.
,
Jan 20 2017
Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 23 2017
,
Mar 13 2017
Cleaning up "Needs-Review" label as we are not using this label for triage. Ref bug 684919
,
Mar 13 2017
,
Mar 15 2017
Umm I don't know if this will even reach the PDF plugin when the file is not found
,
Mar 15 2017
Nothing to do with the sandboxed file system API - this is handling of file:/// URLs at the network(?) layer.
,
Mar 15 2017
This is behaving according to spec. # is used as a fragment delimiter in URLs, so you have to escape it if it's actually part of the path. The same is true for HTTP URLs. From RFC 1738: "The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it."
,
Mar 15 2017
Actually, if the association is running "Chrome C:\<path>", and we're convering that to a file URL, we should probably be escaping the # ourselves. net's FilePathToFileURL method does this, but is apparently not being used. I have no idea who owns code to handle command line input. [+pkasting]: Don't suppose you know? Seem to remember having to run a refactor that affected that code by you, for an owners review.
,
Mar 15 2017
(Removing network and PDF labels, per above comment)
,
Mar 15 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Jan 9 2017