What's the status here?

Status: It's a UI bug, likely introduced by fullscreen changes made by another team about 3-6 months ago. I don't currently have resources on my team to work on this. I might be able to look into it in about 2 months, alongside other UX work related to this feature.

Thanks for the update! Do you think it's still a Pri-1?

anatolid: Yes, unfortunately, since it pretty much negatively impacts all users of the feature on Mac. Actually, on second thought, we should do a bisect and assign this bug to the individual(s) responsible.

dbbrooks: Can you bisect please? Even if the granularity is just daily builds, I can probably easily determine the exact commit that caused the problem if I know which day it happened.

Yuri, it repros on M56. Do want me to go back further looking for the culprit? Sorry I missed this one in testing. 

What's the latest status here?

Ping.

Same status as in comment 3 and 5. I'm removing myself from "assigned" status since I have no intention to work on it in the near-term, and want someone else to be able to take it if they have time.

Is there any chance of this being looked at anytime soon? If not, then we should probably lower the prio to reflect that.

We'll, the priority is correct. Available manpower is the problem. ;-)

The NextAction date has arrived: 2017-10-02

Sending back to triage. It's been 7 months without action on this bug.

Ping for triaging.

See comment 12.

Started looking into this.  Apparently we are incrementing capturer count twice for each capture, and we never decrement it...

This naturally leads to the code that enables fullscreen-in-tab always detecting that capture is ongoing, even after it has stopped, and never leaving that state for a particular web contents (opening a new tab with the same contents is one work around).

It's not clear what is different on Mac for these paths versus other platforms which don't exhibit this bug.

Assigning to self for thorough bisect if possible.

I've used the bisect tool to narrow it down to somewhere between a couple Chrome versions after 56.0.2904.0 and 56.0.2906.0. But during that range, there's a compatibility issue with the oldest version of MR we have in CWS (M61) so device discovery isn't working. 

What I need to bisect to a specific CL is for someone to build the M56 component extension so I can discover devices. Or I need a version of self_mirroring.zip that supports stop casting.

Xiangjun and Yuri, can one of you guys help me with that? 

Xiangjun, it looks like Yuri is OOO, can you help me with this (#24)?

Sure, I'll send you a version of self_mirroring that supports stop casting after 5s (can be easily changed to other duration).

I apologize for taking this long to do a thorough bisect. But on a positive note, I have a feeling this P1 issue is about to be fixed :) This is the cl that introduced the issue: https://chromium.googlesource.com/chromium/src/+log/4d49a63121af456f4463857abeee53c504d2778e..c227f1bb6dc4e286df809a97abaef9bdef63c19e 

Thanks David for taking the bisect. Will take a look on the CL that causes this issue, though it is weird that this only happens with M56, but the CL was also merged in 55.0.2883.34.

Xiangjun and I took a look at 55.0.2883.34 and indeed, it does repro on that version as well. I guess if it was a merge then it makes sense that 56.0.2904.0 didn't have that CL, but 56.0.2906.0 did (IIUC).

We also double checked that this indeed is only reproducible on Mac, not Win or Linux, and it still repros on latest M69 canary.

The suspected CL added increasing/decreasing capturer count for audio capturing. According to Comment 21, it sounds that the capturer count was only increased but not decreased on Mac. Will take a look on this. 

Did some debugging today. The above CL is not the cause. Still reproed after reverted. This issue is actually caused by some weird execution order of the posted tasks on Browser::UI thread on Mac. The capturing count (both video and audio) is never decreased since the WebContentsObserver stops observing the WebContents before decreasing the count when mirroring stops. Will upload a patch to fix this.

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

commit f3af0cc5b3cb425aae2b094d87c49da9cb97d22f
Author: Xiangjun Zhang <xjz@chromium.org>
Date: Wed Jun 20 18:55:46 2018

Fix thread racing on decreament of audio/video capturing count.

When audio/video capturing stops, the capturing count is not
decremented before stopping observing the WebContents due to some
thread racing on Mac. This CL ensures the correct order of these two
operation.

Bug:  704797 
Change-Id: Ia6168facbb5241321bf5a193da3f67811969f314
Reviewed-on: https://chromium-review.googlesource.com/1101920
Commit-Queue: Xiangjun Zhang <xjz@chromium.org>
Reviewed-by: Yuri Wiitala <miu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568957}
[modify] https://crrev.com/f3af0cc5b3cb425aae2b094d87c49da9cb97d22f/content/browser/media/capture/content_capture_device_browsertest_base.cc
[modify] https://crrev.com/f3af0cc5b3cb425aae2b094d87c49da9cb97d22f/content/browser/media/capture/web_contents_audio_input_stream.cc
[modify] https://crrev.com/f3af0cc5b3cb425aae2b094d87c49da9cb97d22f/content/browser/media/capture/web_contents_video_capture_device.cc
[modify] https://crrev.com/f3af0cc5b3cb425aae2b094d87c49da9cb97d22f/content/browser/media/capture/web_contents_video_capture_device_browsertest.cc