Also, precedes the above message:

[2947:2947:1111/145303:800449585676:ERROR:interface_registry.cc(210)] Failed to locate a binder for interface: media::mojom::RemoterFactory requested by: service:content_renderer exposed by: service:content_browser via InterfaceProviderSpec "navigation:frame".

Well the spec is correct, but this indicates nobody has actually registered a RemoterFactory interface on RenderFrameHostImpl's InterfaceRegistry.

I see it's registered by chrome browser only, here: https://cs.chromium.org/chromium/src/chrome/browser/media/cast_remoting_connector.cc

But this happening in content_shell implies there is probably some content renderer code which tries connecting to the RemoterFactory regardless of who the embedder is.

It is generally not OK to have content renderer code be dependent on embedder-specific features, and that seems to be happening here. Of course one hack workaround would be to bind a fake RemoterFactory via shell's content client, but that still leaves every other content embedder in a broken state.

We have lots of non-mojo "client" implementations in content that are exposed via a public API from libcontent where each embedder can optionally provide a "service" implementation. So, I don't see how this is any different. (FWIW, our mojo API is sufficiently generic, declared at a layer *lower* than content, and could be implemented by any embedder.)

Nevertheless, we need a way to solve the problem at-hand: The spammy logs. Does the existing InterfaceRegistry allow a declaration like "the renderer will request a binding to a service that may not exist?"

No, nothing like that exists. Maybe we need something like that, or maybe the lack of an interface binder should not be treated this way (i.e., treated as harshly as a request which violates manifest spec.)

Another possible workaround which seems sane to me is that we could add a content client API which returns a binder for this interface, and content can always use that to register the binder. The default implementation can be a no-op.

 Issue 664154  has been merged into this issue.

The log spam makes it difficult to investigate failures in content_browsertests and in layout tests, so let me try to increase the priority here?

I mentioned this to yuri over chat, but I'm wondering if we can fix this by having content shell just provide a dummy implementation of RemoterFactory? i.e. add an override to ContentShellBrowserClient::RegisterRenderFrameMojoInterfaces, and register something to create FakeRemoterFactory's?

Sure you can do that, but again, every other content embedder will still
have the same problem.

Note to all: Yes, I am looking into this. Raised priority.

Okay, since there are a lot of people affected; and this is causing spammy logs; and the solution to this may not be simple (i.e., no immediate solution is apparent); I'm going to put up a short-term patch to disable the spammy logging.

Patch to temporarily disable spammy logging is now in CQ: https://codereview.chromium.org/2504803002/

To be clear, this should be reverted once the fix for this issue is in-place.

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

commit face478e9879692bae410d450acceaddf6106532
Author: miu <miu@chromium.org>
Date: Wed Nov 16 01:35:33 2016

Disable spammy logging in InterfaceRegistry affecting too many people.

A recent change added error logging to InterfaceRegistry which has, at
some point since then, become suddenly spammy. This change sets the log
level to VLOG(1) since the cause of the problem is well-understood, but
the solution is not as of yet; and the spammy logging is affecting all
non-Chrome embedders (including tests running on bots, or locally by
devs).

Change that added the error logging:
https://codereview.chromium.org/2457493004

BUG= 664595 
R=rockot@chromium.org

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

[modify] https://crrev.com/face478e9879692bae410d450acceaddf6106532/services/service_manager/public/cpp/lib/interface_registry.cc

Patch with permanent fix up for review: https://codereview.chromium.org/2498203004/

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

commit 54dca6cd9ef8e64e8600ed9cb2994e3e8352e514
Author: miu <miu@chromium.org>
Date: Thu Nov 17 10:59:38 2016

Move media::mojom::RemoterFactory to content, add ContentBrowserClient API.

This reverts commit face478e9879692bae410d450acceaddf6106532 ("Disable
spammy logging in InterfaceRegistry affecting too many people."), and
moves the implementation of media::mojom::RemoterFactory to content. From
there, embedders (such as Chrome) may optionally override a new
ContentBrowserClient::CreateMediaRemoter() method to provide the browser-
side media remoting implementation.

BUG= 664595 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/chrome/browser/DEPS
[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/chrome/browser/chrome_content_browser_client.h
[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/chrome/browser/media/cast_remoting_connector.cc
[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/chrome/browser/media/cast_remoting_connector.h
[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/content/browser/BUILD.gn
[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/content/public/browser/content_browser_client.h
[modify] https://crrev.com/54dca6cd9ef8e64e8600ed9cb2994e3e8352e514/services/service_manager/public/cpp/lib/interface_registry.cc

I'm still seeing similar logs. What do you make of this?

https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20%28dbg%29/builds/30/steps/webkit_tests/logs/stdio

14:35:27.412 12244   [12805:12928:1117/143526:9307530260:ERROR:interface_registry.cc(210)] Failed to locate a binder for interface: blink::mojom::BudgetService requested by: content_renderer exposed by: content_browser via InterfaceProviderSpec "service_manager:connector".
14:35:27.412 12244   
14:35:27.412 12244   InterfaceRegistry(service_manager:connector):
14:35:27.412 12244   Owned by:
14:35:27.412 12244     content_browser@ run as: f5895681-49bf-4f66-8f7d-3edc62de6908
14:35:27.412 12244   
14:35:27.412 12244     Providing:
14:35:27.412 12244       capability: gpu containing interfaces:
14:35:27.412 12244         device::mojom::PowerMonitor
14:35:27.412 12244       capability: plugin containing interfaces:
14:35:27.412 12244         device::mojom::PowerMonitor
14:35:27.412 12244       capability: renderer containing interfaces:
14:35:27.412 12244         blink::mojom::BackgroundSyncService
14:35:27.412 12244         blink::mojom::BroadcastChannelProvider
14:35:27.413 12244         blink::mojom::BudgetService
14:35:27.413 12244         blink::mojom::Hyphenation
14:35:27.413 12244         blink::mojom::MimeRegistry
14:35:27.413 12244         blink::mojom::NotificationService
14:35:27.413 12244         blink::mojom::OffscreenCanvasCompositorFrameSinkProvider
14:35:27.413 12244         blink::mojom::OffscreenCanvasSurface
14:35:27.413 12244         blink::mojom::PermissionService
14:35:27.413 12244         blink::mojom::ShapeDetection
14:35:27.413 12244         blink::mojom::WebSocket
14:35:27.413 12244         content::mojom::LayoutTestBluetoothFakeAdapterSetter
14:35:27.413 12244         content::mojom::MemoryCoordinatorHandle
14:35:27.413 12244         content::mojom::ServiceWorkerDispatcherHost
14:35:27.413 12244         content::mojom::StoragePartitionService
14:35:27.413 12244         content::mojom::URLLoaderFactory
14:35:27.413 12244         content::mojom::VideoCaptureHost
14:35:27.413 12244         device::BatteryMonitor
14:35:27.413 12244         device::mojom::LightSensor
14:35:27.413 12244         device::mojom::MotionSensor
14:35:27.413 12244         device::mojom::OrientationSensor
14:35:27.413 12244         device::mojom::PowerMonitor
14:35:27.413 12244         device::mojom::TimeZoneMonitor
14:35:27.413 12244         media::mojom::ImageCapture
14:35:27.413 12244         memory_coordinator::mojom::MemoryCoordinatorHandle
14:35:27.414 12244         payments::mojom::PaymentAppManager
14:35:27.414 12244       capability: service_manager:service_factory containing interfaces:
14:35:27.414 12244         service_manager::mojom::ServiceFactory

Different bug. The key here is the first log line, in your case
blink::mojom::BudgetService.