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

Issue 633706 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug



Sign in to add a comment

"incognito": "not_allowed" does not disable incognito in auto updates

Project Member Reported by rdevlin....@chromium.org, Aug 2 2016

Issue description

Taking from an internal report % private stuff.

It's reported that updating an extension to have the "incognito": "not_allowed" entry in the manifest doesn't update the existing preferences for users who may have already allowed it incognito, and isn't shown properly in the settings.

If an extension adds the incognito: not_allowed setting, we should be sure that the chrome://extensions page displays the extension info correctly.  We *may* also want to clear the preference for the extension; however, that would mean the extension wouldn't retain the permission if it was added back at a later point.
 
Cc: rhalavati@chromium.org
Hi,

Is this still an issue?

Comment 2 by jawag@chromium.org, Apr 19 2018

Cc: scottchen@chromium.org hcarmona@chromium.org dpa...@chromium.org
Did we address this in MD Extensions?
Not that I know of.

It would also be very strange, since we'd have the toggle visible while it was enabled, and then the user would disable it and it would immediately vanish.

I think the right thing to do here is probably to just have "not_allowed" revoke incognito access.
Components: Privacy>Incognito
Status: Available (was: Untriaged)

Sign in to add a comment