The usage of getCapturedTabs() is very low, for example on Windows the ratio of getCapturedTabs()/capture() may be only 0.1% per daily usage. 
No statistic about how many users will listen on onStatusChanged().

Deprecating these two will save tons of logic in tabCapture. 

So the next step should be to update the document page about the deprecation after sign-off this request? Target M71?

I think removing getCapturedTabs() sounds fine - the extension should be able to maintain this state on their own, and usage is very low.  I'm a little more worried about removing onStatusChanged, since it seems like that would be the normal way to monitor capture state.  Is there another way the extension could detect if a capture stream was broken?  Can the stream be broken by factors other than the extension itself?

Ah, sorry for not giving detailed reasons earlier.

The major purpose is to deprecate the tab_capture_registry and use the desktop_streams_registry only as same as desktopCapture does. The logic in tabCaptureReistry is quite heavy with several workarounds to satisfy it without many outputs. Also it causes the unnecessary limitation that same tab can't be captured again by tabCapture, while desktopCapture can.

If tabCaptureRegistry is removed, then the two services, getCapturedTabs() and onStatusChanged(), will be deprecated too. Fortunately, they don't have much usage.

Without onStatusChanged(), developer still can monitor stream status by MediaStream events as in all the other getUserMedia() use cases.

Sorry for the delay, and thanks for the extra information.

Given the low usage rate of getCapturedTabs(), I think we can definitely remove that.  I'd like us to gather a bit more data on the number of users of onStatusChanged before we remove it.

I think it's safe to do the former without waiting for the latter.  If that sounds good to you, we can flip the bit here and then follow-up to remove onStatusChanged.

FWIW, onStatusChanged should be removed as well. It provides two events containing information easily acquired in other ways.

1. Lifecycle information about the capture stream: This status is available from the MediaStreamTracks returned by chrome.tabCapture.capture().

2. Fullscreen state: The chrome.windows.getXYZ() extension APIs provide this information (in WindowState).

I'm fine with removing it eventually, but we need data to verify whether doing so would break significant numbers of extensions.  If so, the deprecation path will need to be longer, with an announcement and migration period.  If it's not being used by any extensions, we can expedite and deprecate it more-or-less immediately (on trunk, and let it roll through the normal release channels).

Agree both of you.
I suppose we can proceed with following steps:
- gather data on the number of users of onStatusChanged to decide the process of deprecation.
- remove tabCaptureRegistry with getCapturedTabs() and onStatusChanged() all together.

The remaining question is how to find out the user counts of onStatusChanged()?
I searched around again and still got no clue.
If there is no way for it, then maybe just give an announcement and migration period. WDYT?

It looks like Extensions.Events.Dispatch might give us the UMA we're looking for?

Taking a look at that, it seems like onStatusChanged is only fired for around 0.01% of users.  This is probably small enough that marking it as deprecated and sending a quick email announcement is sufficient, rather than having a long migration period.

With that, full speed ahead! :)

Good to know the UMA of Extensions.Events.Dispatch.

I'll prepare the cl soon.