Adding Internals>Sandbox>SiteIsolation component, because r584254 (site-per-process is the default on desktop even without of field trials) got blamed.

I have trouble reproing (Win/70.0.3538.67 and Linux/71.0.3573.0):

1. After navigating to https://permission.site/, when I click "Microphone" the button turns red, not green and no permission bubble appears.

2. After clicking "Location", the button turns green and a permission bubble appears, but the omnibox icon disappears after navigating to https://w3c.github.io/clipboard-apis/

Actually, I can repro now - it turns out that step 0 of the repro steps is: ensure that you've actually have a microphone connected to the repro machine.

I can confirm that this issue goes away without Site Isolation (e.g. when launching chrome with --disable-site-isolation-trials).

AFAICT, the order of the following 2 events differs with and without Site Isolation:

1. Without Site Isolation we have the following order
    - MediaStreamCaptureIndicator::WebContentsDeviceUsage::RemoveDevices
    - TabSpecificContentSettings::DidFinishNavigation

2. With Site Isolation we have the following order:
    - TabSpecificContentSettings::DidFinishNavigation
    - MediaStreamCaptureIndicator::WebContentsDeviceUsage::RemoveDevices

Callstacks:

#1 MediaStreamCaptureIndicator::WebContentsDeviceUsage::RemoveDevices()
#2 MediaStreamCaptureIndicator::UIDelegate::~UIDelegate()
#3 MediaStreamCaptureIndicator::UIDelegate::~UIDelegate()
#4 content::MediaStreamUIProxy::Core::~Core()
#5 base::DeleteHelper<>::DoDelete()
#6 base::debug::TaskAnnotator::RunTask()

#1 TabSpecificContentSettings::DidFinishNavigation()
#2 content::WebContentsImpl::DidFinishNavigation()
#3 content::NavigationHandleImpl::~NavigationHandleImpl()
#4 content::NavigationHandleImpl::~NavigationHandleImpl()
#5 content::NavigatorImpl::DidNavigate()
#6 content::RenderFrameHostImpl::DidCommitNavigationInternal()
#7 content::RenderFrameHostImpl::DidCommitProvisionalLoad()
#8 content::mojom::FrameHostStubDispatch::Accept()
#9 mojo::InterfaceEndpointClient::HandleValidatedMessage()

AFAICT, "removal" of a streaming audio device happens in the following callstack on the browser side:

(IO thread)
#1 content::MediaStreamUIProxy::~MediaStreamUIProxy()
        -> will trigger deletion of content::MediaStreamUIProxy::Core on the UI thread
#2 content::MediaStreamUIProxy::~MediaStreamUIProxy()
#3 content::MediaStreamManager::DeviceRequest::~DeviceRequest()
#4 content::MediaStreamManager::DeleteRequest()
#5 content::MediaStreamManager::StopDevice()
#6 content::MediaStreamManager::StopStreamDevice()
#7 content::MediaStreamDispatcherHost::StopStreamDevice()
#8 content::mojom::MediaStreamDispatcherHostStubDispatch::Accept()
#9 mojo::InterfaceEndpointClient::HandleValidatedMessage()

and the following callstack on the renderer side:

#1 content::UserMediaProcessor::StopLocalSource()
#2 content::UserMediaProcessor::StopAllProcessing()
#3 content::UserMediaClientImpl::DeleteAllUserMediaRequests()
#4 content::UserMediaClientImpl::WillCommitProvisionalLoad()
#5 content::RenderFrameImpl::WillCommitProvisionalLoad()
#6 blink::FrameLoader::PrepareForCommit()
#7 blink::WebFrame::Swap()
#8 content::RenderFrameImpl::OnSwapOut()

+wolenetz@ from //media/OWNERS
+raymes@ from //chrome/browser/content_settings/OWNERS

Browser process should stop all audio/video streams when it navigates the main frame (without relying on getting notified by a renderer, which can be delayed as seen in this repro).  This should also cover hiding all the content setting icons.

I don't know what is the best way to achieve the above.  I hope that somebody from //media/OWNERS or //chrome/browser/content_settings/OWNERS can help triage the bug further...

PS. Cross-process swaps are possible even without strict Site Isolation (which shipped in M67), so this bug technically is not a regression...  OTOH, Site Isolation makes cross-process swaps more frequent which makes the bug more likely to repro.  For example - the following repro steps show the same problem even without Site Isolation (when launching chrome with --disable-site-isolation-trials):
1. Launch Google Chrome and navigate to https://permission.site/.
2. Click 'Microphone' button (permission bubble will appear).
3. Click on 'Allow' button of permission bubble.
4. Using the Omnibox, navigate to chrome://version (this will force a process swap)
5. Ta-da - the camera/media icon in the omnibox is still shown for chrome://version

-> dalecurtis@ for better triage from //media (is this for media capture folks?)

=>guidou@ who I think is the current maintainer of media streams.

I bisected with --disable-site-isolation-trials and using the procedure in #7 (i.e., going to chrome://version) and got this range:

https://chromium.googlesource.com/chromium/src/+log/3f16ca95660bbe3f7294db7e3049bdfb39644928..772559ed7f79de8395dfb24eae582172a1840655

Suspecting r455717 back in M59, since it's about updating the toolbar state.

treib@: Can you take a look or reassign to a better owner?

Hm. I was ready to say "no way", since the whole concept of "Instant support" had effectively been gone by that point, and anyway Instant has had no effect on the toolbar for even longer.
However, before that CL, we did make some extraneous calls to UpdateToolbar, which might have accidentally fixed up the microphone icon in this situation? So I guess that CL exposed a bug in the microphone-icon-updating logic, wherever that may be. I have no idea who a good owner would be, so back to you.

raymes@: Can you take a look or help triage this bug?

I'm no longer working on permissions. It look like lukasza found the reason for the bug in #5 and #6? The next thing to work out is whether the order swapping is an expected race or revealing some deeper issue. If it's expected that the functions could be called in either order then we should handle that case.

On a local build with ToT I can reproduce the bug even with --disable-site-isolation-trials.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d014a672eb4bf7cb281303a0723c0e4e9cb9d2c5

commit d014a672eb4bf7cb281303a0723c0e4e9cb9d2c5
Author: Guido Urdaneta <guidou@chromium.org>
Date: Tue Nov 06 16:06:21 2018

Notify web_contents() when a media capture device stops being used.

This CL sends the chrome::NOTIFICATION_WEB_CONTENT_SETTINGS_CHANGED
when a device is removed.
This fixes a bug that occurs when a navigation occurs on a tab that
is capturing audio or video.
In this case, it is possible that the navigation will complete
before the device has been completely stopped, and the new page will
show an icon with the device capture permission corresponding to the
previous page on the omnibar.
To remove that icon, it is necessary to let the tab know that content
settings might have changed.
If the navigation completes after the device stops, the bug does not
reproduce because completing the navigation sends the notification
about the change in content settings.

This bug becomes much more frequent when Site Isolation is enabled.

Bug:  896211 
Change-Id: I6e9d7197d549b00b458ffc84d155487cb3db2fe6
Reviewed-on: https://chromium-review.googlesource.com/c/1319595
Reviewed-by: Tommi <tommi@chromium.org>
Commit-Queue: Tommi <tommi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605695}
[modify] https://crrev.com/d014a672eb4bf7cb281303a0723c0e4e9cb9d2c5/chrome/browser/media/webrtc/media_stream_capture_indicator.cc