Have sent feedback for this issue, mentioning the bug # in the description.

I wonder if it's being woken up by discovery events?

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Wez, do you still see this behavior?  We believe we've addressed the main issue here.

I still see random-looking Media Router process wake-ups fairly often.

Bizarrely, they have been 100% correllated with [GMail] pop-up notifications. Is GMail (or the ChromeOS pop-up notification code) poking at MR in some way..?

+Jacob

It's possible the system tray UI is poking the MR in some way that causes this to happen.  Is this 100% reproducible?

You can seemingly repro this 100% reliably using HTML5 notifications, e.g:

1. Visit https://davidwalsh.name/demo/notifications-api.php
2. Grant the site permission to show notifications.
3. Click to show a notification.

The Media Router extension process will start at both #2 and #3.

However, if you install the Hangouts extension and send messages to trigger that to show notifications, those don't seem to cause the Media Router process to start up. The extension uses <webview> internally, so perhaps the notification source is not the top-level frame and that affects whether MR gets tickled?

Updating this bug's wording to focus on this particular repro case.

Verified (by sending GMails to myself :) that issue also repros 100% reliably on Windows devices; might be worth checking whether it also repros on Mac (non-Aura) and/or Linux (Aura).

I can repro on Linux.

Comparing histograms of Extensions.Events.DispatchWithSuspendedEventPage before and after the notification, it seems the SETTINGS_PRIVATE_ON_PREFS_CHANGED / settingsPrivate.onPrefsChanged event is getting fired. 

Derek, can you take this, or reassign, as necessary, plz?

Well, if the notifications system is firing an onPrefsChange event then the event page will get woken.  Two paths forward are:

- Remove event handler for onPrefsChange (possibly replacing with a custom Mojo API)
- See if we can add a filter for onPrefsChange to filter out notification events.

I'd like to understand why HTML5 notifications trigger an onPrefsChange
notification in the first place - that seems strange, and may mean that
they're more heavyweight than they're intended to be.

This issue no longer repros for me, but I still see the Media Router component extension start every time I open (or close) a tab (though not if I just navigate within an already-open tab).

Leaving task manager open, I definitely see wakeups while opening new tabs to news sites.  It's difficult to discern without more logging exactly why.  From the modules loaded on wakeup it looks like network events.

The next steps are to repro this with logging turned up in MR and the wake reason in the component output as well to understand why the component is being woken up. 

Dug into this.

Some logging reveals it's the CastRemotingConnector, which is instantiating multiple MediaRouteObservers when loading the NTP.  It appears to be an O(N^2) operation: when tab N is opened, N additional connectors/observers are created.  It should be a high priority to figure out why we are creating so many CRC objects.   miu@ can you PTAL?

    at T (chrome-extension://noondiphcddnnabmjcihcjfbhfklnnep/content_script_compiled.js:22:378)
    at chrome-extension://noondiphcddnnabmjcihcjfbhfklnnep/content_script_compiled.js:22:348", source: https://www.google.com/_/chrome/newtab?espv=2&ie=UTF-8 (0)
[25351:1572:0228/140744.099387:VERBOSE1:media_stream_dispatcher_host.cc(100)] MediaStreamDispatcherHost::OnChannelClosing
[25351:25351:0228/140748.708196:VERBOSE2:media_routes_observer.cc(17)] MediaRoutesObserver
[25351:25351:0228/140748.708306:VERBOSE1:media_router_mojo_impl.cc(811)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: Waking event page.
[25351:25351:0228/140748.708366:VERBOSE2:media_router_mojo_impl.cc(799)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: EnqueueTask (queue-length=1)
[25351:25351:0228/140748.708421:VERBOSE1:media_router_mojo_impl.cc(836)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: Attempting to wake up event page: attempt 1
[25351:25351:0228/140748.724094:VERBOSE2:cast_remoting_connector.cc(186)] CastRemotingConnector
[25351:25351:0228/140749.058221:VERBOSE2:media_routes_observer.cc(17)] MediaRoutesObserver
[25351:25351:0228/140749.058315:VERBOSE1:media_router_mojo_impl.cc(816)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: Extension is awake, awaiting ProvideMediaRouter  to be called.
[25351:25351:0228/140749.058355:VERBOSE2:media_router_mojo_impl.cc(799)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: EnqueueTask (queue-length=2)
[25351:25351:0228/140749.058422:VERBOSE2:cast_remoting_connector.cc(186)] CastRemotingConnector
[25351:25351:0228/140749.064371:INFO:CONSOLE(6)] "SW registered", source: https://www.google.com/_/chrome/newtab?espv=2&ie=UTF-8 (6)
[25351:25351:0228/140750.006627:VERBOSE1:media_router_mojo_impl.cc(762)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: DoStartObservingMediaRoutes
[25351:25351:0228/140750.006711:VERBOSE1:media_router_mojo_impl.cc(770)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: MRPM.StartObservingMediaRoutes: 
[25351:25351:0228/140750.006827:VERBOSE1:media_router_mojo_impl.cc(762)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: DoStartObservingMediaRoutes
[25351:25351:0228/140750.006869:VERBOSE1:media_router_mojo_impl.cc(770)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: MRPM.StartObservingMediaRoutes: 
[25351:25351:0228/140750.238822:VERBOSE1:media_router_mojo_impl.cc(209)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: OnRoutesUpdated
[25351:25351:0228/140750.754616:VERBOSE1:media_router_mojo_impl.cc(209)] MR #2b4efc82-5a57-488b-8b47-05652d149e29: OnRoutesUpdated
[25351:1572:0228/140804.145148:VERBOSE1:media_stream_dispatcher_host.cc(100)] MediaStreamDispatcherHost::OnChannelClosing
[25351:1572:0228/140805.328422:VERBOSE1:media_stream_dispatcher_host.cc(100)] MediaStreamDispatcherHost::OnChannelClosing

It should not be O(N^2): Just one CastRemotingConnector (and one route observer) should be created for each tab (1:1 with a WebContents instance). Creating the CastRemotingConnector for every tab is necessary because of the way the Mojo API bindings/notifications happen in the render process.

Ref: https://cs.chromium.org/chromium/src/chrome/browser/media/cast_remoting_connector.cc?rcl=a6395911b0dc6cad281c0e13c62578689be02b93&l=136

Back to the issue at-hand: It seems we should not wake up the extension whenever C++ code creates a MediaRoutesObserver. With the extension asleep, no routes/messages could be created anyway, right? So, maybe we need to add some code to prevent that and/or delay notifications to the extension for when it is woken up for a different reason?

The logging I added showed the CRC constructor invoked N times on opening the Nth tab.  In the log excerpt above, I had just opened a second tab.   When I opened the third, I saw three invocations, etc.   Is that expected?

In the past, the number of live observers was constant per profile (we create one in the MR, and 2-3 to integrate with various bits of UX).  This is the first use case where an arbitrary number need to be created on demand.  In general all observers will receive the same data; is there a need to create more than one for media remoting?

FYI, UMA reports a 10-12x increase in event page wakeups on dev channel starting around 11/10.

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=6dc5db7ebf3112904b0ccd1c2becc9ad

All of them are due to calls to StartObservingMediaRoutes.

Let's investigate mfoltz@ findings in #19/#20 and identify whether we need to restructure the observer handling in the browser, and whether there's a short-term work-around we can apply to stop this hurting performance in M58.

Investigating...

Confirmed only one MediaRoutesObserver is created per CastRemotingConnector (because CRC inherits from MRO), and that only one is created per WebContents. There are about a dozen WebContents instances at start-up, mostly extensions I would assume.

Opening a second new tab page did cause 3 more WebContentses to be created.

Okay, I logged the URLs for all of the WebContentses. They are all for various extensions, except one for chrome://newtab/. When I open new tab pages, only ONE WebContents is created for the new tab page, but two other extensions are "woken up" and have their WebContents re-created.

So, this is the reason there are several instances; and why more than one is being created for each single new tab being opened.

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

commit 34e86af9f3ebe792b7681053eca4c08b27eca52d
Author: miu <miu@chromium.org>
Date: Sat Mar 04 09:09:09 2017

MediaRouter: Cache MediaRoutesObserver queries to prevent ext wake-ups

Resolved a performance issue where the Media Router component extension
was being woken-up each time a new tab was opened. The solution is to
cache route list updates so that the registration of new observers does
not force the extension to wake-up to report on something we can cache
browser-side. (This is the same as what is already being done for the
MediaSinksObservers.)

BUG= 621246 
TEST=Ran chrome with --enable-logging=stderr --vmodule=media_router_mojo_impl=1 to confirm extension wake-ups do not happen when opening new tabs.

Review-Url: https://codereview.chromium.org/2735493002
Cr-Commit-Position: refs/heads/master@{#454769}

[modify] https://crrev.com/34e86af9f3ebe792b7681053eca4c08b27eca52d/chrome/browser/media/router/mojo/media_router_mojo_impl.cc
[modify] https://crrev.com/34e86af9f3ebe792b7681053eca4c08b27eca52d/chrome/browser/media/router/mojo/media_router_mojo_impl.h
[modify] https://crrev.com/34e86af9f3ebe792b7681053eca4c08b27eca52d/chrome/browser/media/router/mojo/media_router_mojo_impl_unittest.cc

Looks like this landed just after the M58 branch; we should make sure to merge it back once we've verified it in Canary.

Requesting merge for M58, since this wastes CPU/Memory/Battery.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit ea43cd3d503c13abfa3f15ed97a4db1b1f37dcb0
Author: Yuri Wiitala <miu@chromium.org>
Date: Mon Mar 06 21:02:55 2017

MediaRouter: Cache MediaRoutesObserver queries to prevent ext wake-ups

Resolved a performance issue where the Media Router component extension
was being woken-up each time a new tab was opened. The solution is to
cache route list updates so that the registration of new observers does
not force the extension to wake-up to report on something we can cache
browser-side. (This is the same as what is already being done for the
MediaSinksObservers.)

BUG= 621246 
TEST=Ran chrome with --enable-logging=stderr --vmodule=media_router_mojo_impl=1 to confirm extension wake-ups do not happen when opening new tabs.

Review-Url: https://codereview.chromium.org/2735493002
Cr-Commit-Position: refs/heads/master@{#454769}
(cherry picked from commit 34e86af9f3ebe792b7681053eca4c08b27eca52d)

Review-Url: https://codereview.chromium.org/2728293003 .
Cr-Commit-Position: refs/branch-heads/3029@{#26}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/ea43cd3d503c13abfa3f15ed97a4db1b1f37dcb0/chrome/browser/media/router/mojo/media_router_mojo_impl.cc
[modify] https://crrev.com/ea43cd3d503c13abfa3f15ed97a4db1b1f37dcb0/chrome/browser/media/router/mojo/media_router_mojo_impl.h
[modify] https://crrev.com/ea43cd3d503c13abfa3f15ed97a4db1b1f37dcb0/chrome/browser/media/router/mojo/media_router_mojo_impl_unittest.cc

Thanks for the quick fix.  Let's discuss offline if there is a way to reasonably reduce the number of observers required by Media Remoting as a small cleanup.