Connecting webrtc-internals WebUI frontend with the backend

Connecting webrtc-internals WebUI frontend with the backend


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

[jiayl, 2013-01-12 01:33:23]

This change connects the webrtc-internals backend with the WebUI frontend to
have a funtional webrtc-internals page.
Changes include:
1. Class WebRTCInternals is moved into chrome/browser/media/ from
content/browser/media/ for WebUI to access. Class WebRTCInternalsInterface is
added to content public API, so the backend inside content can callback.
2. Class WebRTCInternalsMessageHandler is created to handler messages from/to
WebUI on the UI thread. Class WebRTCInternalsProxy forwards these messages to
the IO thread to WebRTCInternals.
3. The javascript code handles updates from WebUI and alters the DOM to present
the udpate.

Reviewers,

please take a look at the change in these folders:

vrk: chrome/browser/media/, content/browser/media/,
content/browser/renderer_host/media/,
jam: chrome/, content/, content/public/,
csilv: chrome/browser/ui/browserui/, chrome/browser/resources/.

Thanks!

[vrk (LEFT CHROMIUM), 2013-01-15 22:54:13]

LGTM for media stuff.

Sorry for the delay and thanks for moving things into media namespace! Just
minor style nits.

https://codereview.chromium.org/11876007/diff/9001/chrome/browser/media/webrt...
File chrome/browser/media/webrtc_internals.h (right):

https://codereview.chromium.org/11876007/diff/9001/chrome/browser/media/webrt...
chrome/browser/media/webrtc_internals.h:20: class WebRTCInternals : public
content::WebRTCInternalsInterface{
nit: space between "content::WebRTCInternalsInterface" and "{"

https://codereview.chromium.org/11876007/diff/9001/chrome/browser/ui/webui/we...
File chrome/browser/ui/webui/webrtc_internals_proxy.h (right):

https://codereview.chromium.org/11876007/diff/9001/chrome/browser/ui/webui/we...
chrome/browser/ui/webui/webrtc_internals_proxy.h:27: //
WebRTCInternalsUIObserver override
nit: period at end of sentence.

https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
File content/public/browser/webrtc_internals_interface.h (right):

https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
content/public/browser/webrtc_internals_interface.h:24: const std::string&
constraints) = 0;
nit: blank line here between method declaration and comment.

https://codereview.chromium.org/11876007/diff/5002/content/browser/renderer_h...
File content/browser/renderer_host/media/peer_connection_tracker_host.cc
(right):

https://codereview.chromium.org/11876007/diff/5002/content/browser/renderer_h...
content/browser/renderer_host/media/peer_connection_tracker_host.cc:35:
->AddPeerConnection(base::GetProcId(peer_handle()),
nit: move the -> to the line before

https://codereview.chromium.org/11876007/diff/5002/content/browser/renderer_h...
content/browser/renderer_host/media/peer_connection_tracker_host.cc:44:
->RemovePeerConnection(base::GetProcId(peer_handle()), lid);
nit: move the -> to the line before

[jiayl, 2013-01-15 23:03:31]

Fixed vrk's comments. Thanks!

https://codereview.chromium.org/11876007/diff/9001/chrome/browser/media/webrt...
File chrome/browser/media/webrtc_internals.h (right):

https://codereview.chromium.org/11876007/diff/9001/chrome/browser/media/webrt...
chrome/browser/media/webrtc_internals.h:20: class WebRTCInternals : public
content::WebRTCInternalsInterface{
On 2013/01/15 22:54:13, Victoria Kirst wrote:
> nit: space between "content::WebRTCInternalsInterface" and "{"

Done.

https://codereview.chromium.org/11876007/diff/9001/chrome/browser/ui/webui/we...
File chrome/browser/ui/webui/webrtc_internals_proxy.h (right):

https://codereview.chromium.org/11876007/diff/9001/chrome/browser/ui/webui/we...
chrome/browser/ui/webui/webrtc_internals_proxy.h:27: //
WebRTCInternalsUIObserver override
On 2013/01/15 22:54:13, Victoria Kirst wrote:
> nit: period at end of sentence.

Done.

https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
File content/public/browser/webrtc_internals_interface.h (right):

https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
content/public/browser/webrtc_internals_interface.h:24: const std::string&
constraints) = 0;
On 2013/01/15 22:54:13, Victoria Kirst wrote:
> nit: blank line here between method declaration and comment.

Done.

https://codereview.chromium.org/11876007/diff/5002/content/browser/renderer_h...
File content/browser/renderer_host/media/peer_connection_tracker_host.cc
(right):

https://codereview.chromium.org/11876007/diff/5002/content/browser/renderer_h...
content/browser/renderer_host/media/peer_connection_tracker_host.cc:35:
->AddPeerConnection(base::GetProcId(peer_handle()),
On 2013/01/15 22:54:13, Victoria Kirst wrote:
> nit: move the -> to the line before

Done.

https://codereview.chromium.org/11876007/diff/5002/content/browser/renderer_h...
content/browser/renderer_host/media/peer_connection_tracker_host.cc:44:
->RemovePeerConnection(base::GetProcId(peer_handle()), lid);
On 2013/01/15 22:54:13, Victoria Kirst wrote:
> nit: move the -> to the line before

Done.

[juberti, 2013-01-16 01:11:21]

https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
File content/public/browser/webrtc_internals_interface.h (right):

https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
content/public/browser/webrtc_internals_interface.h:13: class
WebRTCInternalsInterface {
Not sure what the prevailing style is here, but should we call this
WebRtcObserver, like the seemingly similar MediaObserver class?

[jiayl, 2013-01-16 01:43:48]

On 2013/01/16 01:11:21, juberti wrote:
>
https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
> File content/public/browser/webrtc_internals_interface.h (right):
> 
>
https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
> content/public/browser/webrtc_internals_interface.h:13: class
> WebRTCInternalsInterface {
> Not sure what the prevailing style is here, but should we call this
> WebRtcObserver, like the seemingly similar MediaObserver class?

I didn't call it WebRtcObserver because
1. we already have a WebRTCUIObserver representing a webrtc-internals page.
It'll be confusing to have a WebRtcObserver at the same time.
2. the WebUI impl will eventually be entirely moved into 'content/' and
WebRTCInternalsInterface will be removed at that point. So I think it is fine to
call it WebRTCInternalsInterface for now.

[juberti, 2013-01-16 05:58:10]

On 2013/01/16 01:43:48, jiayl wrote:
> On 2013/01/16 01:11:21, juberti wrote:
> >
>
https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
> > File content/public/browser/webrtc_internals_interface.h (right):
> > 
> >
>
https://codereview.chromium.org/11876007/diff/9001/content/public/browser/web...
> > content/public/browser/webrtc_internals_interface.h:13: class
> > WebRTCInternalsInterface {
> > Not sure what the prevailing style is here, but should we call this
> > WebRtcObserver, like the seemingly similar MediaObserver class?
> 
> I didn't call it WebRtcObserver because
> 1. we already have a WebRTCUIObserver representing a webrtc-internals page.
> It'll be confusing to have a WebRtcObserver at the same time.
> 2. the WebUI impl will eventually be entirely moved into 'content/' and
> WebRTCInternalsInterface will be removed at that point. So I think it is fine
to
> call it WebRTCInternalsInterface for now.

lgtm, ok

[jam, 2013-01-16 16:55:46]

https://codereview.chromium.org/11876007/diff/17001/content/public/browser/we...
File content/public/browser/webrtc_internals_interface.h (right):

https://codereview.chromium.org/11876007/diff/17001/content/public/browser/we...
content/public/browser/webrtc_internals_interface.h:13: class
WebRTCInternalsInterface {
nit: interface is redundant. it's also not used elsewhere in the content api.
something like WebRTCObserver is more common.

https://codereview.chromium.org/11876007/diff/17001/content/public/browser/we...
content/public/browser/webrtc_internals_interface.h:16: // |pid| is the renderer
process id, |lid| is the renderer local id used to
where does local id come from? it's the first time i hear that

[jiayl, 2013-01-16 17:08:53]

https://codereview.chromium.org/11876007/diff/17001/content/public/browser/we...
File content/public/browser/webrtc_internals_interface.h (right):

https://codereview.chromium.org/11876007/diff/17001/content/public/browser/we...
content/public/browser/webrtc_internals_interface.h:13: class
WebRTCInternalsInterface {
On 2013/01/16 16:55:46, John Abd-El-Malek wrote:
> nit: interface is redundant. it's also not used elsewhere in the content api.
> something like WebRTCObserver is more common.

I didn't call it WebRtcObserver because
 1. we already have a WebRTCUIObserver representing a webrtc-internals page.
It'll be confusing to have a WebRtcObserver at the same time.
 2. the WebUI impl will eventually be entirely moved into 'content/' and
WebRTCInternalsInterface will be removed at that point. So I think it is fine
to call it WebRTCInternalsInterface for now.

https://codereview.chromium.org/11876007/diff/17001/content/public/browser/we...
content/public/browser/webrtc_internals_interface.h:16: // |pid| is the renderer
process id, |lid| is the renderer local id used to
On 2013/01/16 16:55:46, John Abd-El-Malek wrote:
> where does local id come from? it's the first time i hear that
It's assigned to each PeerConnection by PeerConnectionTracker. See
PeerConnectionTracker::GetNextLocalID.

[jam, 2013-01-16 19:36:05]

I didn't look at the whole change in detail. but it seems that the ICPs, since
they are calling an observer which really wants this on the UI thread, should be
dispatched on the UI thread. you can do this through RenderViewObserver
interfaces. that should remove the need for the proxy class

https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
File chrome/browser/media/webrtc_internals.h (right):

https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
chrome/browser/media/webrtc_internals.h:21: class WebRTCInternals : public
content::WebRTCInternalsInterface {
(this is a continution of my previous comment)

the convention is that content declares an interface Foo, chrome's
implementation is ChromeFoo. i.e. see the Content*Client interfaces

https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
chrome/browser/media/webrtc_internals.h:25: // Methods called when peer
connection status changes.
nit: don't comment methods from parent interface

[jiayl, 2013-01-16 20:13:13]

On 2013/01/16 19:36:05, John Abd-El-Malek wrote:
> I didn't look at the whole change in detail. but it seems that the ICPs, since
> they are calling an observer which really wants this on the UI thread, should
be
> dispatched on the UI thread. you can do this through RenderViewObserver
> interfaces. that should remove the need for the proxy class
> 
>
https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
> File chrome/browser/media/webrtc_internals.h (right):
> 
>
https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
> chrome/browser/media/webrtc_internals.h:21: class WebRTCInternals : public
> content::WebRTCInternalsInterface {
> (this is a continution of my previous comment)
> 
> the convention is that content declares an interface Foo, chrome's
> implementation is ChromeFoo. i.e. see the Content*Client interfaces
> 
>
https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
> chrome/browser/media/webrtc_internals.h:25: // Methods called when peer
> connection status changes.
> nit: don't comment methods from parent interface

The messages are sent to the browser process, so I guess you meant using
RenderViewHostObserver? I couldn't find a good example of
RenderViewHostObserver. It seems I can achieve the same goal by overriding
BrowserMessageFilter::OverrideThreadForMessage in PeerConnectionTrackerHost. Do
you think it is a good solution?

[jam, 2013-01-16 20:15:52]

On Wed, Jan 16, 2013 at 12:13 PM, <[email protected]> wrote:

> On 2013/01/16 19:36:05, John Abd-El-Malek wrote:
>
>> I didn't look at the whole change in detail. but it seems that the ICPs,
>> since
>> they are calling an observer which really wants this on the UI thread,
>> should
>>
> be
>
>> dispatched on the UI thread. you can do this through RenderViewObserver
>> interfaces. that should remove the need for the proxy class
>>
>
>
> https://codereview.chromium.**org/11876007/diff/17001/**
>
chrome/browser/media/webrtc_**internals.h<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h>
>
>> File chrome/browser/media/webrtc_**internals.h (right):
>>
>
>
> https://codereview.chromium.**org/11876007/diff/17001/**
>
chrome/browser/media/webrtc_**internals.h#newcode21<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h#newcode21>
>
>> chrome/browser/media/webrtc_**internals.h:21: class WebRTCInternals :
>> public
>> content::**WebRTCInternalsInterface {
>> (this is a continution of my previous comment)
>>
>
>  the convention is that content declares an interface Foo, chrome's
>> implementation is ChromeFoo. i.e. see the Content*Client interfaces
>>
>
>
> https://codereview.chromium.**org/11876007/diff/17001/**
>
chrome/browser/media/webrtc_**internals.h#newcode25<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h#newcode25>
>
>> chrome/browser/media/webrtc_**internals.h:25: // Methods called when peer
>> connection status changes.
>> nit: don't comment methods from parent interface
>>
>
> The messages are sent to the browser process, so I guess you meant using
> RenderViewHostObserver?


yep sorry


> I couldn't find a good example of
> RenderViewHostObserver.


you can search for
"public RenderViewHostObserver" file:content


> It seems I can achieve the same goal by overriding
> BrowserMessageFilter::**OverrideThreadForMessage in
> PeerConnectionTrackerHost. Do
> you think it is a good solution?
>

better to derive from RVHO since the OverrideThreadForMessage is usually
used when a class wants to filter IPCs on multiple threads (or one thread
that's not UI). if dispatching on main thread, then observers are the
convention

>
>
https://codereview.chromium.**org/11876007/<https://codereview.chromium.org/1...
>

[jiayl, 2013-01-16 20:51:09]

On 2013/01/16 20:15:52, John Abd-El-Malek wrote:
> On Wed, Jan 16, 2013 at 12:13 PM, <mailto:[email protected]> wrote:
> 
> > On 2013/01/16 19:36:05, John Abd-El-Malek wrote:
> >
> >> I didn't look at the whole change in detail. but it seems that the ICPs,
> >> since
> >> they are calling an observer which really wants this on the UI thread,
> >> should
> >>
> > be
> >
> >> dispatched on the UI thread. you can do this through RenderViewObserver
> >> interfaces. that should remove the need for the proxy class
> >>
> >
> >
> > https://codereview.chromium.**org/11876007/diff/17001/**
> >
>
chrome/browser/media/webrtc_**internals.h<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h>
> >
> >> File chrome/browser/media/webrtc_**internals.h (right):
> >>
> >
> >
> > https://codereview.chromium.**org/11876007/diff/17001/**
> >
>
chrome/browser/media/webrtc_**internals.h#newcode21<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h#newcode21>
> >
> >> chrome/browser/media/webrtc_**internals.h:21: class WebRTCInternals :
> >> public
> >> content::**WebRTCInternalsInterface {
> >> (this is a continution of my previous comment)
> >>
> >
> >  the convention is that content declares an interface Foo, chrome's
> >> implementation is ChromeFoo. i.e. see the Content*Client interfaces
> >>
> >
> >
> > https://codereview.chromium.**org/11876007/diff/17001/**
> >
>
chrome/browser/media/webrtc_**internals.h#newcode25<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h#newcode25>
> >
> >> chrome/browser/media/webrtc_**internals.h:25: // Methods called when peer
> >> connection status changes.
> >> nit: don't comment methods from parent interface
> >>
> >
> > The messages are sent to the browser process, so I guess you meant using
> > RenderViewHostObserver?
> 
> 
> yep sorry
> 
> 
> > I couldn't find a good example of
> > RenderViewHostObserver.
> 
> 
> you can search for
> "public RenderViewHostObserver" file:content
> 
> 
> > It seems I can achieve the same goal by overriding
> > BrowserMessageFilter::**OverrideThreadForMessage in
> > PeerConnectionTrackerHost. Do
> > you think it is a good solution?
> >
> 
> better to derive from RVHO since the OverrideThreadForMessage is usually
> used when a class wants to filter IPCs on multiple threads (or one thread
> that's not UI). if dispatching on main thread, then observers are the
> convention
> 
> >
> >
>
https://codereview.chromium.**org/11876007/%3Chttps://codereview.chromium.org...>
> >

Right now the lifetime of PeerConnectionTrackerHost is managed by
RenderProcessHostImpl. If I make the change to implement RVHO, its lifetime
should be same as RenderViewHostImpl. Where do you think
PeerConnectionTrackerHost should live in?
I searched for classes impelementing RVHO, but they are tests or for android or
plugin, really different scenarios. 

Thanks!

[csilv, 2013-01-16 21:23:18]

chrome/browser/ui/webui/, chrome/browser/resources/ lgtm

[jiayl, 2013-01-17 00:29:27]

I did more search and still could not find a good example of using it in
content/browser/. It seems it is not commonly used except for tests and I cannot
find a good place to call RenderViewHost::AddObserver. Do you think it is OK to
override BrowserMessageFilter::OverrideThreadForMessage instead?


On 2013/01/16 20:15:52, John Abd-El-Malek wrote:
> On Wed, Jan 16, 2013 at 12:13 PM, <mailto:[email protected]> wrote:
> 
> > On 2013/01/16 19:36:05, John Abd-El-Malek wrote:
> >
> >> I didn't look at the whole change in detail. but it seems that the ICPs,
> >> since
> >> they are calling an observer which really wants this on the UI thread,
> >> should
> >>
> > be
> >
> >> dispatched on the UI thread. you can do this through RenderViewObserver
> >> interfaces. that should remove the need for the proxy class
> >>
> >
> >
> > https://codereview.chromium.**org/11876007/diff/17001/**
> >
>
chrome/browser/media/webrtc_**internals.h<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h>
> >
> >> File chrome/browser/media/webrtc_**internals.h (right):
> >>
> >
> >
> > https://codereview.chromium.**org/11876007/diff/17001/**
> >
>
chrome/browser/media/webrtc_**internals.h#newcode21<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h#newcode21>
> >
> >> chrome/browser/media/webrtc_**internals.h:21: class WebRTCInternals :
> >> public
> >> content::**WebRTCInternalsInterface {
> >> (this is a continution of my previous comment)
> >>
> >
> >  the convention is that content declares an interface Foo, chrome's
> >> implementation is ChromeFoo. i.e. see the Content*Client interfaces
> >>
> >
> >
> > https://codereview.chromium.**org/11876007/diff/17001/**
> >
>
chrome/browser/media/webrtc_**internals.h#newcode25<https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webrtc_internals.h#newcode25>
> >
> >> chrome/browser/media/webrtc_**internals.h:25: // Methods called when peer
> >> connection status changes.
> >> nit: don't comment methods from parent interface
> >>
> >
> > The messages are sent to the browser process, so I guess you meant using
> > RenderViewHostObserver?
> 
> 
> yep sorry
> 
> 
> > I couldn't find a good example of
> > RenderViewHostObserver.
> 
> 
> you can search for
> "public RenderViewHostObserver" file:content
> 
> 
> > It seems I can achieve the same goal by overriding
> > BrowserMessageFilter::**OverrideThreadForMessage in
> > PeerConnectionTrackerHost. Do
> > you think it is a good solution?
> >
> 
> better to derive from RVHO since the OverrideThreadForMessage is usually
> used when a class wants to filter IPCs on multiple threads (or one thread
> that's not UI). if dispatching on main thread, then observers are the
> convention
> 
> >
> >
>
https://codereview.chromium.**org/11876007/%3Chttps://codereview.chromium.org...>
> >

[jam, 2013-01-17 00:51:48]

On 2013/01/17 00:29:27, jiayl wrote:
> I did more search and still could not find a good example of using it in
> content/browser/. It seems it is not commonly used except for tests and I
cannot
> find a good place to call RenderViewHost::AddObserver. Do you think it is OK
to
> override BrowserMessageFilter::OverrideThreadForMessage instead?
> 

Theres's no AddObserver for RVHO/RVO, it happens automatically in the
constructor of the interface

[jiayl1, 2013-01-17 01:02:34]

How can I get the RenderViewHost pointer to pass to the constructor? If the
observer (i.e. PeerConnectionTrackerHost) is created per RenderViewHost,
which object should manage its lifetime? I don't see any observer living in
RenderViewHostImpl. PeerConnectionTrackerHost currently lives in
RenderProcessHostImpl.


On Wed, Jan 16, 2013 at 4:51 PM, <[email protected]> wrote:

> On 2013/01/17 00:29:27, jiayl wrote:
>
>> I did more search and still could not find a good example of using it in
>> content/browser/. It seems it is not commonly used except for tests and I
>>
> cannot
>
>> find a good place to call RenderViewHost::AddObserver. Do you think it is
>> OK
>>
> to
>
>> override BrowserMessageFilter::**OverrideThreadForMessage instead?
>>
>
>
> Theres's no AddObserver for RVHO/RVO, it happens automatically in the
> constructor of the interface
>
>
https://codereview.chromium.**org/11876007/<https://codereview.chromium.org/1...
>



-- 
Best wishes,
Jiayang

[jiayl, 2013-01-17 19:14:11]

An updated patch is uploaded for renaming WebRTCInternalsInterface.

I didn't make PeerConnectionTrackerHost to implement RenderViewHostObserver
because the messages are "control" messages, not render view specific. The
sender of the messages has no idea about which routing ID should the messages be
sent to. RenderViewHostObserver cannot receive "control" messages.
We could possibly move WebRTCInternals to UI thread by making
PeerConnectionTrackerHost posting tasks to the UI thread. 

John,
please let me know if you think that is what you want to see.

https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
File chrome/browser/media/webrtc_internals.h (right):

https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
chrome/browser/media/webrtc_internals.h:21: class WebRTCInternals : public
content::WebRTCInternalsInterface {
On 2013/01/16 19:36:05, John Abd-El-Malek wrote:
> (this is a continution of my previous comment)
> 
> the convention is that content declares an interface Foo, chrome's
> implementation is ChromeFoo. i.e. see the Content*Client interfaces

Done. WebRTCInternalsInterface --> WebRTCInternals; WebRTCInternals
-->ChromeWebRTCInternals.

https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
chrome/browser/media/webrtc_internals.h:25: // Methods called when peer
connection status changes.
On 2013/01/16 19:36:05, John Abd-El-Malek wrote:
> nit: don't comment methods from parent interface

Done.

[jiayl, 2013-01-17 19:35:30]

A new patch is uploaded to move ChromeWebRTCInternals to UI thread and remove
WebRTCInternalsProxy. This is done by making PeerConnectionTrackerHost call
WebRTCInternals from the UI thread.
On 2013/01/17 19:14:11, jiayl wrote:
> An updated patch is uploaded for renaming WebRTCInternalsInterface.
> 
> I didn't make PeerConnectionTrackerHost to implement RenderViewHostObserver
> because the messages are "control" messages, not render view specific. The
> sender of the messages has no idea about which routing ID should the messages
be
> sent to. RenderViewHostObserver cannot receive "control" messages.
> We could possibly move WebRTCInternals to UI thread by making
> PeerConnectionTrackerHost posting tasks to the UI thread. 
> 
> John,
> please let me know if you think that is what you want to see.
> 
>
https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
> File chrome/browser/media/webrtc_internals.h (right):
> 
>
https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
> chrome/browser/media/webrtc_internals.h:21: class WebRTCInternals : public
> content::WebRTCInternalsInterface {
> On 2013/01/16 19:36:05, John Abd-El-Malek wrote:
> > (this is a continution of my previous comment)
> > 
> > the convention is that content declares an interface Foo, chrome's
> > implementation is ChromeFoo. i.e. see the Content*Client interfaces
> 
> Done. WebRTCInternalsInterface --> WebRTCInternals; WebRTCInternals
> -->ChromeWebRTCInternals.
> 
>
https://codereview.chromium.org/11876007/diff/17001/chrome/browser/media/webr...
> chrome/browser/media/webrtc_internals.h:25: // Methods called when peer
> connection status changes.
> On 2013/01/16 19:36:05, John Abd-El-Malek wrote:
> > nit: don't comment methods from parent interface
> 
> Done.

[jam, 2013-01-18 18:27:33]

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.cc (right):

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:33: if (observers_.size()) {
nit: here and below, better to early return when the rest of the body is under
an if statement. this helps avoid unnecessary indentation, which is nice with
the 80 char limit

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.h (right):

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.h:14: namespace media {
code in chrome doesn't need to be in a namespace. sometimes people use the
chrome namespace for static methods. but definitely don't use media namespace,
that should only be used for code under src\media

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/ui/webui/m...
File chrome/browser/ui/webui/media/webrtc_internals_message_handler.cc (right):

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/ui/webui/m...
chrome/browser/ui/webui/media/webrtc_internals_message_handler.cc:34: // Don't
try to execute JavaScript in a RenderView that no longer exists.
nit: this comment is just explainging what the code does, and is against the
style guide

https://codereview.chromium.org/11876007/diff/33001/content/browser/renderer_...
File content/browser/renderer_host/media/peer_connection_tracker_host.cc
(right):

https://codereview.chromium.org/11876007/diff/33001/content/browser/renderer_...
content/browser/renderer_host/media/peer_connection_tracker_host.cc:36:
base::Bind(&PeerConnectionTrackerHost::OnAddPeerConnectionOnUIThread,
why are you doing the dispatching manually instead of using
OverrideThreadForMessage?

[jiayl, 2013-01-18 19:20:00]

A new patch fixed jam's comments. Please take another look.
 Thanks!!

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.cc (right):

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:33: if (observers_.size()) {
On 2013/01/18 18:27:33, John Abd-El-Malek wrote:
> nit: here and below, better to early return when the rest of the body is under
> an if statement. this helps avoid unnecessary indentation, which is nice with
> the 80 char limit

Done.

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.h (right):

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.h:14: namespace media {
On 2013/01/18 18:27:33, John Abd-El-Malek wrote:
> code in chrome doesn't need to be in a namespace. sometimes people use the
> chrome namespace for static methods. but definitely don't use media namespace,
> that should only be used for code under src\media

Done.

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/ui/webui/m...
File chrome/browser/ui/webui/media/webrtc_internals_message_handler.cc (right):

https://codereview.chromium.org/11876007/diff/33001/chrome/browser/ui/webui/m...
chrome/browser/ui/webui/media/webrtc_internals_message_handler.cc:34: // Don't
try to execute JavaScript in a RenderView that no longer exists.
On 2013/01/18 18:27:33, John Abd-El-Malek wrote:
> nit: this comment is just explainging what the code does, and is against the
> style guide

Done.

https://codereview.chromium.org/11876007/diff/33001/content/browser/renderer_...
File content/browser/renderer_host/media/peer_connection_tracker_host.cc
(right):

https://codereview.chromium.org/11876007/diff/33001/content/browser/renderer_...
content/browser/renderer_host/media/peer_connection_tracker_host.cc:36:
base::Bind(&PeerConnectionTrackerHost::OnAddPeerConnectionOnUIThread,
On 2013/01/18 18:27:33, John Abd-El-Malek wrote:
> why are you doing the dispatching manually instead of using
> OverrideThreadForMessage?

I tried using OverrideThreadForMessage and it didn't work and I thought it needs
to be override on the sender side. But then I looked more and found I checked
the message type wrongly. :P
Now It works.

[jam, 2013-01-18 22:23:45]

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.cc (right):

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:31: if (observers_.size()) {
nit: early return here

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:49: if (observers_.size()) {
ditto

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.h (right):

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.h:24: // Methods called when peer
connection status changes.
nit: don't document overridden methods. just say

// content::WebRTCInternals implementation:

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.h:45: // Only the UI thread should
access these fields.
nit: this class is now always used on the UI thread, so the threading comments
are unnecessary

https://codereview.chromium.org/11876007/diff/42001/content/browser/renderer_...
File content/browser/renderer_host/media/peer_connection_tracker_host.cc
(right):

https://codereview.chromium.org/11876007/diff/42001/content/browser/renderer_...
content/browser/renderer_host/media/peer_connection_tracker_host.cc:31: if
(message.type() == PeerConnectionTrackerHost_AddPeerConnection::ID ||
since you're doing this for all PeerConnection messages, just do

if (IPC_MESSAGE_CLASS(message) == PeerConnectionTrackerMsgStart)
  *thread=BrowserThread::UI

[jiayl, 2013-01-18 22:39:51]

A new patch is uploaded for jam's comments. Please take another look. Thanks!!

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.cc (right):

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:31: if (observers_.size()) {
On 2013/01/18 22:23:45, John Abd-El-Malek wrote:
> nit: early return here

I moved the check into SendUpdate and return early from there

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:49: if (observers_.size()) {
On 2013/01/18 22:23:45, John Abd-El-Malek wrote:
> ditto

Done.

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.h (right):

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.h:24: // Methods called when peer
connection status changes.
On 2013/01/18 22:23:45, John Abd-El-Malek wrote:
> nit: don't document overridden methods. just say
> 
> // content::WebRTCInternals implementation:

Done.

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.h:45: // Only the UI thread should
access these fields.
On 2013/01/18 22:23:45, John Abd-El-Malek wrote:
> nit: this class is now always used on the UI thread, so the threading comments
> are unnecessary

Done.

https://codereview.chromium.org/11876007/diff/42001/content/browser/renderer_...
File content/browser/renderer_host/media/peer_connection_tracker_host.cc
(right):

https://codereview.chromium.org/11876007/diff/42001/content/browser/renderer_...
content/browser/renderer_host/media/peer_connection_tracker_host.cc:31: if
(message.type() == PeerConnectionTrackerHost_AddPeerConnection::ID ||
On 2013/01/18 22:23:45, John Abd-El-Malek wrote:
> since you're doing this for all PeerConnection messages, just do
> 
> if (IPC_MESSAGE_CLASS(message) == PeerConnectionTrackerMsgStart)
>   *thread=BrowserThread::UI

Done.

[jam, 2013-01-18 22:52:01]

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.cc (right):

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:31: if (observers_.size()) {
On 2013/01/18 22:39:51, jiayl wrote:
> On 2013/01/18 22:23:45, John Abd-El-Malek wrote:
> > nit: early return here
> 
> I moved the check into SendUpdate and return early from there

why do this work when webrtc webui page isn't shown?

[jiayl, 2013-01-18 22:59:05]

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.cc (right):

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:31: if (observers_.size()) {


It's for sending the cached updates to a webrtc-internals page if it is opened
*after* the updates happened. In my next CL, the javascript will send a message
to chrome to get all cached updates.

On 2013/01/18 22:52:01, John Abd-El-Malek wrote:
> On 2013/01/18 22:39:51, jiayl wrote:
> > On 2013/01/18 22:23:45, John Abd-El-Malek wrote:
> > > nit: early return here
> > 
> > I moved the check into SendUpdate and return early from there
> 
> why do this work when webrtc webui page isn't shown?

[jam, 2013-01-22 07:03:12]

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.cc (right):

https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:31: if (observers_.size()) {
On 2013/01/18 22:59:06, jiayl wrote:
> 
> 
> It's for sending the cached updates to a webrtc-internals page if it is opened
> *after* the updates happened. In my next CL, the javascript will send a
message
> to chrome to get all cached updates.

i'm not sure i follow. what i mean is that this function (in the latest
patchset) does work which gets thrown out if obserers_ is empty. what i'm asking
is why create the dictionaryvalue object and add stuff to it if it won't be
used, instead of early existing here?

[jiayl, 2013-01-22 17:14:11]

You are right that creating 'id' in RemovePeerConnection is unnecessary. I moved
the check back to the caller of SendUpdate to avoid the wasted work. Updating
peer_connection_data_ is still needed for the reason I stated before.

On 2013/01/22 07:03:12, John Abd-El-Malek wrote:
>
https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
> File chrome/browser/media/chrome_webrtc_internals.cc (right):
> 
>
https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
> chrome/browser/media/chrome_webrtc_internals.cc:31: if (observers_.size()) {
> On 2013/01/18 22:59:06, jiayl wrote:
> > 
> > 
> > It's for sending the cached updates to a webrtc-internals page if it is
opened
> > *after* the updates happened. In my next CL, the javascript will send a
> message
> > to chrome to get all cached updates.
> 
> i'm not sure i follow. what i mean is that this function (in the latest
> patchset) does work which gets thrown out if obserers_ is empty. what i'm
asking
> is why create the dictionaryvalue object and add stuff to it if it won't be
> used, instead of early existing here?

[jiayl, 2013-01-22 17:14:31]

Please see the new patch. Thanks!

On 2013/01/22 17:14:11, jiayl wrote:
> You are right that creating 'id' in RemovePeerConnection is unnecessary. I
moved
> the check back to the caller of SendUpdate to avoid the wasted work. Updating
> peer_connection_data_ is still needed for the reason I stated before.
> 
> On 2013/01/22 07:03:12, John Abd-El-Malek wrote:
> >
>
https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
> > File chrome/browser/media/chrome_webrtc_internals.cc (right):
> > 
> >
>
https://codereview.chromium.org/11876007/diff/42001/chrome/browser/media/chro...
> > chrome/browser/media/chrome_webrtc_internals.cc:31: if (observers_.size()) {
> > On 2013/01/18 22:59:06, jiayl wrote:
> > > 
> > > 
> > > It's for sending the cached updates to a webrtc-internals page if it is
> opened
> > > *after* the updates happened. In my next CL, the javascript will send a
> > message
> > > to chrome to get all cached updates.
> > 
> > i'm not sure i follow. what i mean is that this function (in the latest
> > patchset) does work which gets thrown out if obserers_ is empty. what i'm
> asking
> > is why create the dictionaryvalue object and add stuff to it if it won't be
> > used, instead of early existing here?

[jam, 2013-01-22 17:19:12]

lgtm

https://codereview.chromium.org/11876007/diff/53001/chrome/browser/media/chro...
File chrome/browser/media/chrome_webrtc_internals.cc (right):

https://codereview.chromium.org/11876007/diff/53001/chrome/browser/media/chro...
chrome/browser/media/chrome_webrtc_internals.cc:86: DCHECK(observers_.size() >
0);
nit: convention is to use empty() instead of size() when check if a container is
empty or not, so

DCHECK(!observers_.empty());

[jiayl, 2013-01-22 17:27:16]

Thanks!

observers_'s type is ObserverList, which does not have a "empty" method. That's
why I used "size".

On 2013/01/22 17:19:12, John Abd-El-Malek wrote:
> lgtm
> 
>
https://codereview.chromium.org/11876007/diff/53001/chrome/browser/media/chro...
> File chrome/browser/media/chrome_webrtc_internals.cc (right):
> 
>
https://codereview.chromium.org/11876007/diff/53001/chrome/browser/media/chro...
> chrome/browser/media/chrome_webrtc_internals.cc:86: DCHECK(observers_.size() >
> 0);
> nit: convention is to use empty() instead of size() when check if a container
is
> empty or not, so
> 
> DCHECK(!observers_.empty());

[commit-bot: I haz the power, 2013-01-22 17:27:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/53001

[commit-bot: I haz the power, 2013-01-22 17:28:00]

Failed to apply patch for chrome/chrome_browser.gypi:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file chrome/chrome_browser.gypi
  Hunk #1 FAILED at 1047.
  1 out of 1 hunk FAILED -- saving rejects to file
chrome/chrome_browser.gypi.rej

Patch:       chrome/chrome_browser.gypi
Index: chrome/chrome_browser.gypi
diff --git a/chrome/chrome_browser.gypi b/chrome/chrome_browser.gypi
index
bdae6fd717a6456c2291fbd27945da8fef8e1025..b2e92b9d486d9bbd3b079a15f32292d8fd13d03e
100644
--- a/chrome/chrome_browser.gypi
+++ b/chrome/chrome_browser.gypi
@@ -1047,6 +1047,8 @@
         'browser/media_gallery/scoped_mtp_device_map_entry.h',
         'browser/media_gallery/transient_device_ids.cc',
         'browser/media_gallery/transient_device_ids.h',
+        'browser/media/chrome_webrtc_internals.cc',
+        'browser/media/chrome_webrtc_internals.h',
         'browser/memory_details.cc',
         'browser/memory_details.h',
         'browser/memory_details_android.cc',

[jam, 2013-01-22 17:39:30]

https://codereview.chromium.org/11876007/diff/53001/chrome/browser/ui/webui/m...
File chrome/browser/ui/webui/media/webrtc_internals_ui.cc (right):

https://codereview.chromium.org/11876007/diff/53001/chrome/browser/ui/webui/m...
chrome/browser/ui/webui/media/webrtc_internals_ui.cc:42:
ChromeURLDataManager::AddDataSourceImpl(profile,
because of r177854, you'll need to change this line to
ChromeURLDataManager::AddWebUIDataSource(profile,                               
            CreateWebRTCInternalsHTMLSource());

[commit-bot: I haz the power, 2013-01-22 18:08:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/52002

[commit-bot: I haz the power, 2013-01-22 18:25:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/55003

[commit-bot: I haz the power, 2013-01-22 19:30:48]

Retried try job too often on linux_aura for step(s) content_browsertests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_aura...

[commit-bot: I haz the power, 2013-01-22 20:03:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/57034

[commit-bot: I haz the power, 2013-01-22 20:03:56]

Failed to apply patch for chrome/chrome_tests_unit.gypi:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file chrome/chrome_tests_unit.gypi
  Hunk #1 FAILED at 843.
  1 out of 1 hunk FAILED -- saving rejects to file
chrome/chrome_tests_unit.gypi.rej

Patch:       chrome/chrome_tests_unit.gypi
Index: chrome/chrome_tests_unit.gypi
diff --git a/chrome/chrome_tests_unit.gypi b/chrome/chrome_tests_unit.gypi
index
d9898d2d8f618e80e1f852a39ce783e59f295a1b..fd3923a4302857fda864cd77ac29f3688124bda1
100644
--- a/chrome/chrome_tests_unit.gypi
+++ b/chrome/chrome_tests_unit.gypi
@@ -843,6 +843,7 @@
         'browser/managed_mode/managed_mode_url_filter_unittest.cc',
         'browser/managed_mode/managed_user_service_unittest.cc',
         'browser/media/media_internals_unittest.cc',
+        'browser/media/chrome_webrtc_internals_unittest.cc',
         'browser/media_gallery/media_file_system_registry_unittest.cc',
         'browser/media_gallery/media_galleries_dialog_controller_mock.cc',
         'browser/media_gallery/media_galleries_dialog_controller_mock.h',

[commit-bot: I haz the power, 2013-01-22 20:11:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/65006

[commit-bot: I haz the power, 2013-01-22 21:21:56]

Retried try job too often on win_rel for step(s) browser_tests,
chrome_frame_net_tests, interactive_ui_tests, sync_integration_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-01-22 21:31:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/65006

[commit-bot: I haz the power, 2013-01-23 06:16:04]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/65006

[commit-bot: I haz the power, 2013-01-23 06:16:10]

Failed to apply patch for chrome/chrome_browser_ui.gypi:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file chrome/chrome_browser_ui.gypi
  Hunk #1 succeeded at 1928 (offset -2 lines).
  Hunk #2 FAILED at 2163.
  1 out of 2 hunks FAILED -- saving rejects to file
chrome/chrome_browser_ui.gypi.rej

Patch:       chrome/chrome_browser_ui.gypi
Index: chrome/chrome_browser_ui.gypi
diff --git a/chrome/chrome_browser_ui.gypi b/chrome/chrome_browser_ui.gypi
index
2b29a476a27f215be24a72ba5f87c596f28a55a7..9d0924ed8305f0ee90cf944c8a461e153d8f26e1
100644
--- a/chrome/chrome_browser_ui.gypi
+++ b/chrome/chrome_browser_ui.gypi
@@ -1930,6 +1930,10 @@
         'browser/ui/webui/media/media_internals_proxy.h',
         'browser/ui/webui/media/media_internals_ui.cc',
         'browser/ui/webui/media/media_internals_ui.h',
+        'browser/ui/webui/media/webrtc_internals_message_handler.cc',
+        'browser/ui/webui/media/webrtc_internals_message_handler.h',
+        'browser/ui/webui/media/webrtc_internals_ui.cc',
+        'browser/ui/webui/media/webrtc_internals_ui.h',
         'browser/ui/webui/metrics_handler.cc',
         'browser/ui/webui/metrics_handler.h',
         'browser/ui/webui/nacl_ui.cc',
@@ -2159,8 +2163,6 @@
         'browser/ui/webui/version_ui.h',
         'browser/ui/webui/web_ui_util.cc',
         'browser/ui/webui/web_ui_util.h',
-        'browser/ui/webui/webrtc_internals_ui.cc',
-        'browser/ui/webui/webrtc_internals_ui.h',
         'browser/ui/webui/welcome_ui_android.cc',
         'browser/ui/webui/welcome_ui_android.h',
         'browser/ui/window_sizer/window_sizer.cc',

[commit-bot: I haz the power, 2013-01-23 06:33:28]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/57036

[commit-bot: I haz the power, 2013-01-23 06:42:54]

Retried try job too often on mac for step(s) compile
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac&number...

[commit-bot: I haz the power, 2013-01-23 06:54:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/11876007/55009

[commit-bot: I haz the power, 2013-01-23 09:00:49]

Change committed as 178272