Legacy Browser Support redirect looping
Reported by
reili...@gmail.com,
Feb 20 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299 Steps to reproduce the problem: 1. Ensure LBS extension and Add-on is enabled 2. Configure policy to look at our Enterprise Mode List, and gray list our home page, proxy and authentication sites 3. Browse to a site on our enterprise mode list. What is the expected behavior? I'd expect chrome to redirect the site to IE What went wrong? Chrome is redirecting the site to IE, and IE is redirecting it back to Chrome - Entering into an endless loop Did this work before? N/A Chrome version: 58.0.3029.110 Channel: n/a OS Version: 10.0 Flash Version: If I disable the LBS Add-on in IE, the solution appears to work as expected (Redirects pages from Chrome to IE). I suspect it will NOT redirect items back to chrome, but is that really a problem? I suppose the other item, we may have users who want IE as their default browser - so having the add-on turned on, it may cause a situation where sites are incorrectly redirected to Chrome when they are intended to be in IE (standard user browsing).
,
Feb 20 2018
One item I just tried - if I put an offending URL directly into the URLlist policy, it will NOT loop. It only appears to loop on items that are found within the Enterprise Mode list. Could there be an offending character or something in the enterprise mode list file that could be causing this behavior?
,
Feb 27 2018
It is possible that some entries in the site list can cause issues as this is relatively new feature and some edge cases might have not been encountered/covered yet. Can you share privately with us your site list (or a simplified sample reproducing the issue) together with the url that causes the problem? You can use my email address pastarmovj at chromium.org or share it via google drive with that email address.
,
Mar 8 2018
A change is in the making to allow for prefix entries in the site lists (both from the intrinsic LBS policies as well as the IE Site List to be specified without a schema e.g. until now "http://test.com/" would be a proper prefix entry but "test.com/" would not be now the rule is extended to allow for this and either entries of the form "//test.com/" as well as "test.com/" are allowed. Single slash will not be allowed to disambiguate from incomplete directory path. We will soon publish a version containing this change to the beta channel of LBS and then the bug will be marked as fixed.
,
Mar 8 2018
Great, thank you for the update. How can I participate in the early release testing? John
,
Mar 8 2018
Hi, the beta channels info is here https://support.google.com/chrome/a/answer/6096882?hl=en&ref_topic=3062034 I will update this bug once the changes are present on this channel. Thank you! :)
,
Mar 28 2018
The bug should be fixed on the beta channel now. Please give it a shot and let me know.
,
Mar 28 2018
Great, thank you! Will test and report back.
,
Mar 29 2018
Hello - We tested the beta file. There is good news and bad news. The good news - the looping does appear to have stopped for sites that are listed in our enterprise mode list. The bad news is that sites that are in our Enteprise mode list are being directed back to Chrome with the IE Add-in enabled. I presume the IE Add-in is detecting that the site 'can' be run in Chrome and pushing the URL back to Chrome. Is there a way to prevent this behavior? We'd want whatever is in our enterprise mode list to open in IE as defined. We do not want the Add-in to self declare what sites open where (ignoring the IE enterprise mode list). Thanks, John
,
Mar 29 2018
Thanks for the quick feedback! The IE Addon should not "decide" on its own anything for sure! I will check what is going on and update the bug asap.
,
Apr 5 2018
Update for the bug. The issue has been identified to being non-ascii characters in the site list were causing issues with LBS. The extension has been fixed to operate properly with any Unicode characters and an updated version will soon be posted to the beta channel. Meanwhile clearing URLs which contain non-ascii characters from the list should be sufficient to overcome this issue.
,
Apr 12 2018
The new beta version (5.3) should fix the issue with non-ascii characters in URLs. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by reili...@gmail.com
, Feb 20 2018