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

Issue 611603 link

Starred by 6 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Chrome browser: Open SSL certificate and no more clicks are entertained for another website.

Reported by dhoot.vi...@gmail.com, May 12 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2716.0 Safari/537.36

Steps to reproduce the problem:
1. Open any website supporting on https. Say open https://www.facebook.com
2. Click on the lock icon "view site information" and click on the "Details" link to open up the Security tab.
3. Click on the "View Certificate" button in Security tab opened up after above steps.
4. Keep the SSL certificate opened. DON'T CLOSE THE CERTIFICATE (DON'T CLICK OK).
5. Open another tab and open up any other website, say open gmail.
6. Try accessing few emails, compose email, etc...This may work fine. But..
7. Try traversing between different tabs like "Primary", "Social", and "Promotions"...Ans this is not working. Clicks on this tabs are NOT entertained.
8. You can also reproduce this issue by open certificate for gmail in one tab and try traversing through facebook in another tab. Mostly nothing will work for facebook then.

What is the expected behavior?
Website opened in one tab should not impact another website opened in  different tab unless and until both of them have anything in common like session, cookies, etc...

What went wrong?
Clicks are NOT entertained if SSL certificate is opened for another website in different tab.

Did this work before? N/A 

Chrome version: 52.0.2716.0  Channel: n/a
OS Version: OS X 10.11.4
Flash Version: Shockwave Flash 21.0 r0

Generally we have many tabs opened and then say try to open facebook in last tab (say 30th or more where we don't know whats all opened in another tabs) and then see its not working, no click is entertained then user is left with no clue and this seems annoying situation for any user.
 
Status: Untriaged (was: Unconfirmed)
Components: -UI UI>Browser>TabCapture
Components: Platform>DevTools
Cc: a...@chromium.org est...@chromium.org
Components: -UI>Browser>TabCapture UI>Browser
Status: Unconfirmed (was: Untriaged)
I wasn't able to repro, but maybe Avi has some ideas? Could be a tab-modal dialog misbehaving.
Not able to reproduce here on Ubuntu.
Components: -Platform>DevTools
After reading through all the latest comments, I tried to reproduce it again on my side and succeed. I have prepared video for the same, but cannot load that here as its size is ~64 MB. So please let me know how else I can share that video with you.

Comment 8 by rsesek@chromium.org, May 23 2016

Can you put it on Google Drive or another storage service (YouTube, DropBox, etc.)?
Uploaded in Google Drive. Please get it from - https://drive.google.com/file/d/0B1nn8gJq67KhYU1CcXlpODJVLUk/view?usp=sharing

Comment 10 by a...@chromium.org, May 23 2016

Cc: f...@chromium.org
Ah, you need to have the devtools window docked.


I am not sure what you mean by docked, if it is as same as keeping open, then I am not sure whether certificate can be kept open without keeping devtools window open. 

But main step to re-pro this issue is keeping certificate open.

Comment 12 by a...@chromium.org, May 23 2016

What I mean is that the devtools can be put into its own window, but if you do so then you can't reproduce this issue.
Owner: a...@chromium.org
Status: Assigned (was: Unconfirmed)
I can confirm this with the docked devtools window. This only appears to affect the area that would be covered by the sheet, not any other parts of the page.

This is probably because -hideSheet only sets the alpha value but doesn't do anything about event handling.

Comment 14 by a...@chromium.org, May 27 2016

This is using a system sheet, not our constrained window... Can we switch it over?

Comment 15 by a...@chromium.org, May 31 2016

Labels: -Type-Bug Type-Bug-Regression
Owner: spqc...@chromium.org
If we look at certificate_viewer_mac.mm's -hideSheet and -unhideSheet, you'll see that they save and restore the sheet view's autoresizesSubviews value. Why? Because the certificate sheet used to not only be alpha-ed out but it used to be resized out, and resizing the sheet while autoresizesSubviews was set would break the layout. (See the similar code using oldResizesSubviews_ in ssl_client_certificate_selector_cocoa.mm's -hideSheet to see how it used to be done.) The oldResizesSubviews_ is unneeded if no resizing happens, but it was left as a remnant.

Resizing of the sheet was done explicitly to avoid this problem. Since spqchan removed the resizing code in https://codereview.chromium.org/1495623008, I'm assigning this bug to her.
Status: Fixed (was: Assigned)
Cc: spqc...@chromium.org nyerramilli@chromium.org ashej...@chromium.org
 Issue 609063  has been merged into this issue.
As this issue is fixed now, so I wonder whether this is been considered under any of your bounty programs or it doesn't meet the criteria.

Comment 20 by f...@chromium.org, Jun 14 2016

Unfortunately, this does not meed the criteria for the security rewards program. It was a real bug, but it was not a security vulnerability. We currently only reward security vulnerabilities.
Cc: patricia...@chromium.org ellyjo...@chromium.org tkonch...@chromium.org
 Issue 641792  has been merged into this issue.

Sign in to add a comment