Issue metadata
Sign in to add a comment
|
Re-enable Warnings doesn't work reliably in Incognito |
||||||||||||||||||||||
Issue descriptionChrome Version: 59.0.3037 What steps will reproduce the problem? 1. Visit https://wrong.host.badssl.com/ in a normal browser instance. 2. Click through interstitial. 3. Open a new incognito instance to https://wrong.host.badssl.com/. Observe no warning interstitial. 4. Click the lock to show Page Info. Click "Re-enable warnings". 5. Refresh the page. Bug: No Interstitial. Presumably because we're using a throwaway incognito profile and the base user profile still has the warning disabled? (Do we even want to propagate certificate warning exceptions from the regular user profile into the Incognito profile?)
,
Mar 10 2017
According to the design doc, this isn't intended: https://docs.google.com/document/d/12c5FkgS3Cl5BXWF0_VErSolq9bO1_vY80NOXRfoQf9U/edit#heading=h.cb4y275mon62 But then, according to IncognitoSSLHostStateDelegateTest.PRE_AfterRestart test, it's intended: https://cs.chromium.org/chromium/src/chrome/browser/ssl/chrome_ssl_host_state_delegate_test.cc?type=cs&q=IncognitoSSLHostStateDelegateTest,+PRE_AfterRestart So, intended?
,
May 12 2017
Issue 718594 has been merged into this issue.
,
Nov 10 2017
,
Feb 18 2018
,
Apr 17 2018
,
Apr 20 2018
,
Oct 1
meacer@, Has there been any activity on this? We reset the permissions that sites have in incognito mode to safer states. I think this should be done for security warnings as well. Therefore I think this should be considered as bug and not intended.
,
Oct 2
No activity apart from comment #2, as far as I know. felt: Do you happen to remember whether we eventually decided to carry over cert exceptions to incognito? (see comment #2)
,
Dec 4
Gentle ping to bring this up.
,
Dec 4
felt for comment #9 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by est...@chromium.org
, Mar 10 2017Components: UI>Browser>Interstitials
Labels: OS-All