Reporter - Thanks for filing the issue...!!

Could you please provide a sample test file/url to test the issue from TE-end. This will help us in triaging the issue further.

Thanks...!!

TE - I've attached a file with a space in the name.  Can you try it?  (I don't have a windows machine to try for myself.)

Deleted: file with space.txt 0 bytes

file with space.txt 0 bytes View Download

OS: Microsoft Windows
Chrome version: 64 and 65
URL: Local files (file:///)
Bug: Special characters and blank spaces are misinterpreted and not matching
Proof: attached images

Deleted: chrome_64_65_workspaces_override_bug.png 180 KB

	chrome_64_65_workspaces_override_bug.png 180 KB View Download

Deleted: override-bug.gif 68.5 KB

	override-bug.gif 68.5 KB View Download

Unable to reproduce the issue on Win-10 using chrome latest stable #64.0.3282.186 and latest canary #67.0.3362.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Added a folder with file with space.txt in the filesystem.
2. Hovered over the file.
3. Observed that special characters and blank spaces are not misinterpreted and matching.

reporter@ - Could you please check the attached screen cast and please let us know if anything missed from our end.

Thanks...!!

Deleted: 816305.mp4 517 KB

	816305.mp4 517 KB View Download

Workspace not matching if in url contains space, attach video and resource files.

- Similar problem with Override :-(
- Chrome 63 not have this problem
- Chrome 64 and 65 have this problem

Deleted: Workspaces-space-bug.mp4 1.4 MB

	Workspaces-space-bug.mp4 1.4 MB View Download

Deleted: resource_files.zip 1.3 KB

resource_files.zip 1.3 KB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

krajshree@ - request for you in here.

It looks like there are two issues here:

1) When the user is on a local page (file://) for a filename with a space, then space is displayed escaped as %20 in the omnibox.  I'm not sure if that is the right thing to do.  I read the relevant standard, RFC 8089 ( https://tools.ietf.org/html/rfc8089 ), and cannot figure out whether percent encoding is implicitly required.  It sounds like Chrome 63 didn't used to escape these.
  - krajshree@, can you load the file with the space (not in dev tools, just regular Chrome)?  If so, do you see the %20 in the omnibox?  And if you try it again with Chrome 63, is there still a percent %20 there?

2) Dev tools apparently is also displaying the filename escaped.  I don't know if this is a separate issue or if dev tools is deriving its information from the same source as the omnibox.

#9

1) This is correct behaviour from the URL standard (and I believe would have been considered correct under all previous URL specs as well); see [1] --- a SPACE in the path must be encoded as "%20" as part of URL parsing, so it is correct to display "%20". It can also be displayed as " " (since the URL spec allows decoding to happen as part of the rendering process [2]). Note that while the spec actually mandates decoding characters, it's actually broken to suggest that all characters be decoded [3], so I think it's fine either way if it is displayed as " " or "%20". What's important is that " " and "%20" are always treated the same way. RFC 8089 isn't relevant here because the equivalence of " " and "%20" is established by the URL Standard, before any scheme-specific consideration is made.

2) This seems like a dev tools issue. I can't find any standard that explicitly says how to map a file: URL onto a local filename. Neither the URL standard nor RFC 8089 [4] (ironically?) explicitly state that percent encoded bytes should be decoded in the local file system, but this is the obvious behaviour. "%20" should be decoded into " " before mapping onto a file system path. Tagging with dev tools.

[1] https://url.spec.whatwg.org/#path-percent-encode-set
[2] https://url.spec.whatwg.org/#url-rendering
[3] https://github.com/whatwg/url/issues/369
[4] https://tools.ietf.org/html/rfc8089

Able to reproduce the issue on Win-10 using chrome latest stable #65.0.3325.146 and latest canary #67.0.3366.0.
Observing the same behaviour on M63 chrome version #63.0.3239.132. But again in M-60, Workspace is not matching if url contains blank spaces or not. The color is not changing instantaneously on changing the color in the css file in M-60.

Attaching screen cast of both M-60 and M-63 behaviour.

Reporter@ - Could you please check the attached screen casts and please let us know your inputs.

Thanks...!! 

Deleted: 816305_M63.mp4 917 KB

	816305_M63.mp4 917 KB View Download

Deleted: 816305@M60.mp4 1.3 MB

	816305@M60.mp4 1.3 MB View Download

Excuse me! I test Chrome 62, 63, 64 and 65, all buged T_T. Attach video with me chrome 62 test.

@krajshree, no, since chrome 63 the Workspace auto-matching, but chrome 62 it must be done manually: Right Click over file > Map to file system resource (view attached video)

@mgiuca, correct, but workspaces and overwrites saved the file with spaces translated as %2520 instead %20, this makes it not matching.

Deleted: chrome-62-workspaces-file-space-name-bug.mp4 1.2 MB

	chrome-62-workspaces-file-space-name-bug.mp4 1.2 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot