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 1 user

Issue metadata

Status: Fixed
Closed: Feb 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Sign in to add a comment

Issue 681628: LBS removes blank spaces in URI fragment if IE is open

Reported by, Jan 16 2017 Project Member

Issue description

Chrome Version: 55.0.2883.87 (Official Build)m
OS: Windows Server 2012, and clients attached to the server are Windows 7 Enterprise. 
IE version: 10
LBS extension version: 4.6
LBS host version:4.6

What steps will reproduce the problem?
(1) Set a policy in LBS to open a link with spaces and pound signs in between. Example: word2/fine name.pdf
(2) In a computer that has the policy set, open that website.
(3) Website is opened incorrectly in alternate browser (IE specifically) if the browser is already open.

What is the expected result?
Website should be displayed correctly.

What happens instead?
Website is not displayed, since the spaces will be removed, thus, changing the path to the URL.

Additional notes:
This behavior is seen if IE is already open, since it simply deletes the spaces and put the URL words altogether. If IE is closed when the user access that URL in Chrome, then IE opens from scratch, IE instead of trimming the spaces, replace them with ‘%20’, and the resource is correctly located and opened, which should be the expected behavior. It only happens when the following factors met IE already open, a pound sign and a space in the URL.

By performing a net-internals capture, we see that the URL that Chrome passes to the alternate browser is not altered in anyway, it sends the URL with the spaces in between. We can say that the issue is related to the way that IE interprets the URLs that’s being sent from Chrome.

Comment 1 by, Jan 16 2017

Labels: hotlist-enterprise-support

Comment 2 by, Jan 17 2017

Labels: -Pri-3 Hotlist-Enterprise LBS Pri-2
Summary: LBS removes blank spaces in URI fragment if IE is open (was: Blank spaces trimmed when opening a website using LBS)
I can reproduce the issue in my local setup. Ex. when I configure LBS to redirect from Chrome to IE and:

- Go to " bar" in Chrome while IE open >> Fragment becomes "#foobar" without blank space
- Go to " bar" in Chrome while IE closed >> Blank space encoded to "#foo%20bar"
- Go to " bar" in Chrome while IE open >> Blank space encoded to "foo%20bar"
- Go to " bar" in Chrome while IE closed >> Blank space encoded to "foo%20bar"

I am not sure if we want to support use of blank spaces in URI fragment, but routing anyway since the behavior changes depending just on whether IE window is open.

Comment 3 by, Jan 17 2017

Thanks for flagging this Kota. Certainly the lack of consistency is a bug and if we can support spaces (which I belive we can) we should do it always and only if there is a case where it is impossible this should be made consistent and documented.

I am assinging this to me for further investigation and fixing.

Comment 4 by, Feb 2 2017

Status: Started (was: Untriaged)

Comment 5 by, Feb 3 2017

Status: Fixed (was: Started)
The issue is fixed in the current beta release 4.7. Please download the new beta msi package to test the fix.

Unfortunately I can not promise that no other characters might get eaten in the same due to the nature of how IE has to be invoked to respect the user setting to open tabs or windows but I will do my best to fix any such issues as fast as I can.

Sign in to add a comment