New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 509522
Owner: ----
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Compat

Sign in to add a comment

Issue 679157: Windows local file PDF Paths with # symbol fail

Reported by, Jan 7 2017

Issue description

UserAgent: 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

Comment 1 by, Jan 9 2017

Labels: Needs-Triage-M55

Comment 2 by, Jan 13 2017

Labels: Needs-Feedback
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.

Comment 3 by, Jan 13 2017

Please see attached file for making Chrome the default pdf reader
573 KB View Download

Comment 4 by, Jan 13 2017

This is the result
17.6 KB View Download

Comment 5 by, Jan 20 2017

Project Member
Labels: -Needs-Feedback Needs-Review
Thank you for providing more feedback. Adding requester "" for another review and adding "Needs-Review" label for tracking.

For more details visit - Your friendly Sheriffbot

Comment 6 by, Jan 23 2017

Components: Internals>Plugins>PDF

Comment 7 by, Mar 13 2017

Cleaning up "Needs-Review" label as we are not using this label for triage. Ref  bug 684919 

Comment 8 by, Mar 13 2017

Labels: -Needs-Review

Comment 9 by, Mar 15 2017

Components: Blink>Storage>FileSystem
Umm I don't know if this will even reach the PDF plugin when the file is not found

Comment 10 by, Mar 15 2017

Components: -Blink>Storage>FileSystem Internals>Network
Nothing to do with the sandboxed file system API - this is handling of file:/// URLs at the network(?) layer.

Comment 11 by, Mar 15 2017

Status: WontFix (was: Unconfirmed)
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."

Comment 12 by, Mar 15 2017

Owner: ----
Status: Available (was: WontFix)
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.

Comment 13 by, Mar 15 2017

Components: -Internals>Plugins>PDF -Internals>Network
(Removing network and PDF labels, per above comment)

Comment 14 by, Mar 15 2017

Mergedinto: 509522
Status: Duplicate (was: Available)

Sign in to add a comment