As far as I can tell, updating permission settings doesn't terminate access to permission-protected API calls that are currently live. Therefore, I'm not sure it would be a good idea to remove the omnibox and tabstrip icons from currently open tabs after settings are updated. 

Here's an example using https://permission.site/:

1. Go to https://permission.site/
2. Click the Location button
3. Grant location permission when prompted
4. Click the omnibar location icon -> Manage location settings. That opens a new tab to chrome://settings/contentExceptions#location
5. Clear the location permission for https://permission.site:443
6. Return to the https://permission.site browser tab
7. Click the omnibar location icon. The text bubble text still indicates that the page is tracking my location, but also includes the text, "Settings will be cleared on next reload." (see attached screenshot)

I'm setting this bug to Available with the expectation that someone from someone on the Permission side chimes in, as I don't think this is specific to the getUserMedia API.

Deleted: locationpermission.png 14.3 KB

	locationpermission.png 14.3 KB View Download

This is by design since it only controls the permissions and not the actual device (like firefox does) hence all ongoing streams that already have permission will keep running.

I do not see this as problem in reality but I have no data on if users do.

tommi@ WDYT?

This is currently working as designed.  Users can close the tab, hit refresh after disabling access, etc.  If the page is doing something it shouldn't be doing, closing the tab is probably what users would do and the permissions UI is something advanced users would know about.

When other permissions are changed, the user is informed that it won't take effect until the page is reloaded (see attachment).

Is there any reason we shouldn't do the same here?

Deleted: Reload.png 40.0 KB

	Reload.png 40.0 KB View Download

That makes sense -- we should probably just display that same bar when page actions change.

I'm not sure if this is intended behavior, but the icon also remains after stopping all MediaStreamTracks and no longer accessing the microphone, or webcam, etc. For example, see this JSFiddle: https://jsfiddle.net/avgra0xx/2/

The camera icon in the omnibar indicates that permissions has been given to the page, that's it.

The red recording indicator in the tab is present as long as a MediaStream is alive.

Your jsfiddle illustrates exactly that.

Assigning owner. Might be possible to close.

This seems to be working as intended. 
Adding dominickn@, who knows more about how permissions and the corresponding UI should work.

dominickn@: Do you think the camera icon should be removed from the omnibar when the microphone/camera is no longer being accessed?

We keep showing the camera because otherwise you can turn on the camera for tiny periods of time to create photos of the user or record voices in the room after you have observed some inactivity by the user (assuming that the user would not notice that the microphone icon shows up). This is working as intended.

I would support an information as suggested in comment #5.

I agree that this is currently working as intended. There's an argument to be made about the page action icon, but we have broader long term goal to remove those icons and move the indication of permission state completely into the page info dialog (perhaps combined with notifications via anchored toasts). So I don't think there's much point in changing when that icon does and doesn't appear right now - it's not misleading, and it provides utility.

Moving myself to cc and marking this as available for someone to pick up to implement c#5.

Closing, since both battre@ and dominick@ also agree that this is currently working as intended.

I think there is still something here - it is weird that the user can block access and we don't show the same infobar to reload the page like we do with other permissions.

Repurposing bug to address this, and assigning to raymes@ who's been looking at unifying the media permissions code paths with the other permissions code paths.

 Issue 653500  has been merged into this issue.

 Issue 806063  has been merged into this issue.

 Issue 814110  has been merged into this issue.

Long time since last updated. What's the latest status? Still an issue?