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

Issue 801565 link

Starred by 1 user
Status: WontFix
Owner:
pastarmovj@chromium.org
Closed: Apr 2018
Cc:
marcore@chromium.org
█ kotah@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug
LBS



Sign in to add a comment

LBS issue: switching to chrome on __doPostBack

Project Member Reported by marcore@chromium.org, Jan 12 2018 
Chrome version: 62.0.3202.94
Internet Explorer version: 
OS version:Windows10 professional 64bit / Windows7 professional 32bit
Legacy Browser Support (LBS) Version: 5.0
Case#: 14325282

Description: LBS activates Chrome browser while browsing the web page on IE. 
This issue happens when the users click a tab which contains doPostBack with Java script. 

Steps to reproduce: configure LBS with this policy: https://drive.google.com/open?id=1N0U8PJl2poQd3IKMAAjyUEXk-_jiHPBv


Current Behavior / Reproduction: 
on internet explorer, the customer click on a link with a doPostBack script
https://drive.google.com/open?id=1-buxbULJrTMHsgPp3vfzE-YHr1D_fySg
and it loads chrome: https://drive.google.com/open?id=1ThVMMdtI77jHmXbDE_te18O94pSWMANY
Expected Behavior: 
to remain in internet explorer
Drive link to logs: https://drive.google.com/open?id=1g8cZ2vID_5kyoQpP3jAsCZRC8gZ8NsDo

Comment 1 by pastarmovj@chromium.org, Jan 15 2018

Cc: -pastarmovj@chromium.org
Owner: pastarmovj@chromium.org
To cause this effect the doPostBack link might lead to a URL outside of the URL LIST. From checking the list it seems the whole domain that contains the link is whitelisted but this doesn't mean the actual domain that the post happens to is spelled the same. Maybe it contains a fully qualified domain name instead of the short local name listed. Can you check the exact URL that the post back leads to and if it is covered by one of the whitelisted domains?

Comment 2 by marcore@chromium.org, Jan 19 2018 

the customer confirms that the url called is in the whitelist policy
I have asked for:
1) enable the "*" in the policy "greylist"
2) generate an har file of opening the url in IE

Is possible to enable more debug logs of the LBS Internet Explorer Helper Browser Object ?

Comment 3 by pastarmovj@chromium.org, Jan 19 2018 

unfortunately there are no further logs available. 

Let's see what's in the data you get back and worst case I would be happy to try investigate this over VC/remote desktop session with the customer.

Comment 4 by ryutas@chromium.org, Mar 6 2018 

as  marcore@ commented on #2,
the customer got the .har file from IE.
https://drive.google.com/open?id=1e13fT5JW5XzWQrIr2Bs6C4-BSQ7YkaQi

please check the .har file and let us know if you need additional info from the customer.

Comment 5 by ayoneda@chromium.org, Mar 13 2018 

Hi all, do we have any updates on this issue? Thanks!

Comment 6 by yban@chromium.org, Mar 26 2018 

Do you have any updates regarding the issue?
Any small updates will be appreciated.

Thank you very much!

Comment 7 by marcore@chromium.org, Mar 26 2018

Cc: marcore@chromium.org
in the har file some paths are in UPPERCASE instead of lowercase as in the url policy.
from the documentation:
https://support.google.com/chrome/a/answer/3062039?hl=en&ref_topic=3062034

Support for mixed-case URLs. All URLs are subject to proper normalization. This means that domain names are lowercase, whereas paths are preserved as specified. This means EXAMPLE.COM is the same as example.com but example.com/somefile is not the same as example.com/SOMEFILE.

Comment 8 by pastarmovj@chromium.org, Mar 27 2018 

Good catch! The domain part is properly normalized wheras this is impossible for the path as many servers are case sensitive. Please verify this and if you still observe the aforementioned issue we will investigate further,.

Comment 9 by marcore@chromium.org, Apr 9 2018

Status: WontFix (was: Untriaged)
The case # 14325282 is closed.
closing this as won't fix work as intended.
►

Sign in to add a comment