Fix for the revert of r172659. The problem was that MediaStreamImpl's constructor was getting a Ren…

Fix for the revert of Blink r172659. The problem was that MediaStreamImpl's constructor was getting a RenderView with an uninitialized routing_id. Also add a dcheck to catch this happening in the future to make debugging easier.

BUG=304341
R=nasko@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=266588

[nasko, 2014-04-28 14:03:08]

Is it really uninitialized routing_id_ or some other part of RV? It looks like
in the code before this CL the RV is constructed first, which gives it the
routing id, but it hasn't run the actual initialization code.

[jam, 2014-04-28 14:43:45]

On 2014/04/28 14:03:08, nasko wrote:
> Is it really uninitialized routing_id_ or some other part of RV? It looks like
> in the code before this CL the RV is constructed first, which gives it the
> routing id, but it hasn't run the actual initialization code.

it's routing_id_:

in RenderViewImpl::Create, a RenderFrameImpl is being created. When it calls
back to content and we create a RenderFrameImpl, it does have the pointer to the
RenderView and it uses that to create a MediaStreamImpl (RenderViewObserver for
now, but will be changed to RenderFrameObserver after the blink side lands). The
RenderViewObserver constructor caches the RenderView's routing id, which, since
RenderViewImpl::Initialize hasn't been called yet, is MSG_ROUTING_NONE.

[nasko, 2014-04-28 16:18:40]

LGTM