Add hooks to content to request permission to connect to the PPAPI broker.

Add hooks to content to request permission to connect to the PPAPI broker.


BUG=142639
TEST=browser_tests:PPAPITest.Broker


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=152991

[Bernhard Bauer, 2012-08-08 21:01:40]

Please review.

[Bernhard Bauer, 2012-08-09 19:14:04]

Ping?

[ddorwin, 2012-08-12 22:51:16]

I have general concerns about the robustness of the implementation. I'm happy to
discuss offline.
I stopped reviewing in detail about halfway through since the code may change.

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/browser.cc
File chrome/browser/ui/browser.cc (right):

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/browser.c...
chrome/browser/ui/browser.cc:964: // TODO(bauerb): Request permission.
FYI, should automatically return false in certain cases. This is briefly
mentioned in the bug.

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/views/ext...
File chrome/browser/ui/views/external_tab_container_win.cc (right):

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/views/ext...
chrome/browser/ui/views/external_tab_container_win.cc:830: void
ExternalTabContainerWin::RequestPpapiBrokerPermission(
Why does this need to be overridden?

http://codereview.chromium.org/10854040/diff/2022/content/browser/web_content...
File content/browser/web_contents/web_contents_impl.h (right):

http://codereview.chromium.org/10854040/diff/2022/content/browser/web_content...
content/browser/web_contents/web_contents_impl.h:473: // Callback function when
requesting permission to access the PPAPI broker.
Maybe explain the meaning of |result|. Or use an enum instead of a bool.

http://codereview.chromium.org/10854040/diff/2022/content/common/view_messages.h
File content/common/view_messages.h (right):

http://codereview.chromium.org/10854040/diff/2022/content/common/view_message...
content/common/view_messages.h:1837: //The browser will respond with
ViewMsg_PpapiBrokerPermissionResult.
missing space after //

http://codereview.chromium.org/10854040/diff/2022/content/public/browser/web_...
File content/public/browser/web_contents_delegate.h (right):

http://codereview.chromium.org/10854040/diff/2022/content/public/browser/web_...
content/public/browser/web_contents_delegate.h:426: // should be called with the
result.
s/should/will/

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_broker_impl.cc (right):

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_broker_impl.cc:191: LOG_IF(ERROR, !weak_ptr) <<
"Client has gone away";
Seems more like a warning.

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_broker_impl.cc:192: LOG_IF(ERROR,
!i->second.authorized) << "Client is waiting for permission";
Is this really an error that should always be logged?

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_broker_impl.cc:193: if (!i->second.authorized) {
Is the renderer process responsible for enforcing the result? It seems the
browser should be - otherwise, a compromised renderer can allow the broker
regardless of the user's choice.
I think to fully secure this, the browser must create the socket pair (currently
in  PepperBrokerImpl::ConnectPluginToBroker) and pass it back (i.e. via
OnBrokerPermissionResult()).

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_broker_impl.h (right):

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_broker_impl.h:77: bool authorized;
is_authorized

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_plugin_delegate_impl.cc (right):

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:416: new
ViewHostMsg_OpenChannelToPpapiBroker(render_view_->routing_id(),
Ideally, this would cause the user prompt. Instantiating the broker process and
providing a channel to it is the most important thing security-wise. After that,
a compromised renderer can bypass the checks for individual instances. IIRC, we
might need to eliminate this channel and send all traffic for all connects
through the browser.

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:808: new
ViewHostMsg_RequestPpapiBrokerPermission(
Ideally, this would instantiate the broker if necessary and create the
broker-instance pipe. This would enforce user permissions.
Also, since the path below can be faked, combining this with the current
ViewHostMsg_OpenChannelToPpapiBroker functionality in the browser would ensure
that the real path being instantiated is shown.

http://codereview.chromium.org/10854040/diff/2022/webkit/plugins/ppapi/ppb_br...
File webkit/plugins/ppapi/ppb_broker_impl.h (right):

http://codereview.chromium.org/10854040/diff/2022/webkit/plugins/ppapi/ppb_br...
webkit/plugins/ppapi/ppb_broker_impl.h:39: // Returns the URL of the document
this plug-in runs in. This is necessary to
This can also be faked in a compromised renderer.

[Bernhard Bauer, 2012-08-13 09:02:11]

See my comment about the security implications in pepper_broker_impl.cc below.
Justin, feel free to weigh in.

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/browser.cc
File chrome/browser/ui/browser.cc (right):

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/browser.c...
chrome/browser/ui/browser.cc:964: // TODO(bauerb): Request permission.
On 2012/08/12 22:51:16, ddorwin wrote:
> FYI, should automatically return false in certain cases. This is briefly
> mentioned in the bug.

Do you know what these cases are? FYI, the actual infobar is in
http://codereview.chromium.org/10826164/ and returns false in the following
cases:
* WebContentsDelegate is NULL
* WebContentsDelegate is not a Browser or ExternalTabContainer
* WebContents is not associated with a TabContents.

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/views/ext...
File chrome/browser/ui/views/external_tab_container_win.cc (right):

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/views/ext...
chrome/browser/ui/views/external_tab_container_win.cc:830: void
ExternalTabContainerWin::RequestPpapiBrokerPermission(
On 2012/08/12 22:51:16, ddorwin wrote:
> Why does this need to be overridden?

The default implementation immediately returns false, to catch all the cases
where we don't have UI to show an infobar. We override this in cases where we do
show the infobar (Browser and ExternalTabContainerWin).

http://codereview.chromium.org/10854040/diff/2022/content/browser/web_content...
File content/browser/web_contents/web_contents_impl.h (right):

http://codereview.chromium.org/10854040/diff/2022/content/browser/web_content...
content/browser/web_contents/web_contents_impl.h:473: // Callback function when
requesting permission to access the PPAPI broker.
On 2012/08/12 22:51:16, ddorwin wrote:
> Maybe explain the meaning of |result|. Or use an enum instead of a bool.

Done.

http://codereview.chromium.org/10854040/diff/2022/content/common/view_messages.h
File content/common/view_messages.h (right):

http://codereview.chromium.org/10854040/diff/2022/content/common/view_message...
content/common/view_messages.h:1837: //The browser will respond with
ViewMsg_PpapiBrokerPermissionResult.
On 2012/08/12 22:51:16, ddorwin wrote:
> missing space after //

Done.

http://codereview.chromium.org/10854040/diff/2022/content/public/browser/web_...
File content/public/browser/web_contents_delegate.h (right):

http://codereview.chromium.org/10854040/diff/2022/content/public/browser/web_...
content/public/browser/web_contents_delegate.h:426: // should be called with the
result.
On 2012/08/12 22:51:16, ddorwin wrote:
> s/should/will/

Hm. I read the comments in this file as notes for an implementor of this
interface, which would make "should" more appropriate?

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_broker_impl.cc (right):

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_broker_impl.cc:191: LOG_IF(ERROR, !weak_ptr) <<
"Client has gone away";
On 2012/08/12 22:51:16, ddorwin wrote:
> Seems more like a warning.

Oops, that was for debugging. Removed.

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_broker_impl.cc:193: if (!i->second.authorized) {
On 2012/08/12 22:51:16, ddorwin wrote:
> Is the renderer process responsible for enforcing the result? It seems the
> browser should be - otherwise, a compromised renderer can allow the broker
> regardless of the user's choice.

Yeah, I talked about this with Justin. AFAIU, a compromised renderer could
always lie about its URL to bypass the content settings, so I'm not sure how
much we would gain from having the decision in the browser. In the light of
that, we decided to do the simpler thing and keep the decision in the renderer.
For other plug-in blocking mechanisms (content settings, outdated and infobarred
plug-ins) we also make the final decision in the renderer instead of the
browser.

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_broker_impl.h (right):

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_broker_impl.h:77: bool authorized;
On 2012/08/12 22:51:16, ddorwin wrote:
> is_authorized

Done.

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_plugin_delegate_impl.cc (right):

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:416: new
ViewHostMsg_OpenChannelToPpapiBroker(render_view_->routing_id(),
On 2012/08/12 22:51:16, ddorwin wrote:
> Ideally, this would cause the user prompt. Instantiating the broker process
and
> providing a channel to it is the most important thing security-wise. After
that,
> a compromised renderer can bypass the checks for individual instances. IIRC,
we
> might need to eliminate this channel and send all traffic for all connects
> through the browser.

I guess that would mean using a new channel for every broker connection (like we
do for NPAPI plug-in channels) instead of using a single broker channel for the
PluginModule?

[ddorwin, 2012-08-13 22:27:03]

I'll defer to Justin on the renderer vs. browser issue. This is at least an
improvement.

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/browser.cc
File chrome/browser/ui/browser.cc (right):

http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/browser.c...
chrome/browser/ui/browser.cc:964: // TODO(bauerb): Request permission.
On 2012/08/13 09:02:11, Bernhard Bauer wrote:
> On 2012/08/12 22:51:16, ddorwin wrote:
> > FYI, should automatically return false in certain cases. This is briefly
> > mentioned in the bug.
> 
> Do you know what these cases are? FYI, the actual infobar is in
> http://codereview.chromium.org/10826164/ and returns false in the following
> cases:
> * WebContentsDelegate is NULL
> * WebContentsDelegate is not a Browser or ExternalTabContainer
> * WebContents is not associated with a TabContents. 

As discussed offline.

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
File content/renderer/pepper/pepper_plugin_delegate_impl.cc (right):

http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:416: new
ViewHostMsg_OpenChannelToPpapiBroker(render_view_->routing_id(),
On 2012/08/13 09:02:12, Bernhard Bauer wrote:
> On 2012/08/12 22:51:16, ddorwin wrote:
> > Ideally, this would cause the user prompt. Instantiating the broker process
> and
> > providing a channel to it is the most important thing security-wise. After
> that,
> > a compromised renderer can bypass the checks for individual instances. IIRC,
> we
> > might need to eliminate this channel and send all traffic for all connects
> > through the browser.
> 
> I guess that would mean using a new channel for every broker connection (like
we
> do for NPAPI plug-in channels) instead of using a single broker channel for
the
> PluginModule?

You would need to somehow be able to refcount the uses of the broker. This could
be accomplished with a channel, though I don't think it would be used for
anything since the pipe would be returned at the same time.

http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
File content/renderer/pepper/pepper_broker_impl.cc (right):

http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
content/renderer/pepper/pepper_broker_impl.cc:252: PP_ERROR_ABORTED);
The code this function replaces had two different values. Maybe the function
should be parameterized with a PP_Error.

http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
File content/renderer/pepper/pepper_broker_impl.h (right):

http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
content/renderer/pepper/pepper_broker_impl.h:59: // Called to balance out
Disconnect() calls.
It also adds it to pending_connects_. The name seems misleading. Maybe
AddPendingConnect() would be better.

[Bernhard Bauer, 2012-08-13 22:42:13]

http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
File content/renderer/pepper/pepper_broker_impl.cc (right):

http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
content/renderer/pepper/pepper_broker_impl.cc:252: PP_ERROR_ABORTED);
On 2012/08/13 22:27:04, ddorwin wrote:
> The code this function replaces had two different values. Maybe the function
> should be parameterized with a PP_Error.

Done.

http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
File content/renderer/pepper/pepper_broker_impl.h (right):

http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
content/renderer/pepper/pepper_broker_impl.h:59: // Called to balance out
Disconnect() calls.
On 2012/08/13 22:27:04, ddorwin wrote:
> It also adds it to pending_connects_. The name seems misleading. Maybe
> AddPendingConnect() would be better.

Done.

[ddorwin, 2012-08-13 23:34:06]

Thanks. LGTM for me, but you'll need a Pepper team review.
Please make sure to address the cases we discussed in an appropriate CL.

[jschuh, 2012-08-13 23:35:21]

On 2012/08/13 22:27:03, ddorwin wrote:
> I'll defer to Justin on the renderer vs. browser issue. This is at least an
> improvement.

Yeah, we want to get this in quickly for a few reasons, and at the moment
there's no way to enforce anything better in the browser (as Bernhard noted).
We'll need to revisit this if and when we get site isolation.


> http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/browser.cc
> File chrome/browser/ui/browser.cc (right):
> 
>
http://codereview.chromium.org/10854040/diff/2022/chrome/browser/ui/browser.c...
> chrome/browser/ui/browser.cc:964: // TODO(bauerb): Request permission.
> On 2012/08/13 09:02:11, Bernhard Bauer wrote:
> > On 2012/08/12 22:51:16, ddorwin wrote:
> > > FYI, should automatically return false in certain cases. This is briefly
> > > mentioned in the bug.
> > 
> > Do you know what these cases are? FYI, the actual infobar is in
> > http://codereview.chromium.org/10826164/ and returns false in the following
> > cases:
> > * WebContentsDelegate is NULL
> > * WebContentsDelegate is not a Browser or ExternalTabContainer
> > * WebContents is not associated with a TabContents. 
> 
> As discussed offline.
> 
>
http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
> File content/renderer/pepper/pepper_plugin_delegate_impl.cc (right):
> 
>
http://codereview.chromium.org/10854040/diff/2022/content/renderer/pepper/pep...
> content/renderer/pepper/pepper_plugin_delegate_impl.cc:416: new
> ViewHostMsg_OpenChannelToPpapiBroker(render_view_->routing_id(),
> On 2012/08/13 09:02:12, Bernhard Bauer wrote:
> > On 2012/08/12 22:51:16, ddorwin wrote:
> > > Ideally, this would cause the user prompt. Instantiating the broker
process
> > and
> > > providing a channel to it is the most important thing security-wise. After
> > that,
> > > a compromised renderer can bypass the checks for individual instances.
IIRC,
> > we
> > > might need to eliminate this channel and send all traffic for all connects
> > > through the browser.
> > 
> > I guess that would mean using a new channel for every broker connection
(like
> we
> > do for NPAPI plug-in channels) instead of using a single broker channel for
> the
> > PluginModule?
> 
> You would need to somehow be able to refcount the uses of the broker. This
could
> be accomplished with a channel, though I don't think it would be used for
> anything since the pipe would be returned at the same time.
> 
>
http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
> File content/renderer/pepper/pepper_broker_impl.cc (right):
> 
>
http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
> content/renderer/pepper/pepper_broker_impl.cc:252: PP_ERROR_ABORTED);
> The code this function replaces had two different values. Maybe the function
> should be parameterized with a PP_Error.
> 
>
http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
> File content/renderer/pepper/pepper_broker_impl.h (right):
> 
>
http://codereview.chromium.org/10854040/diff/40/content/renderer/pepper/peppe...
> content/renderer/pepper/pepper_broker_impl.h:59: // Called to balance out
> Disconnect() calls.
> It also adds it to pending_connects_. The name seems misleading. Maybe
> AddPendingConnect() would be better.

[Bernhard Bauer, 2012-08-14 07:25:31]

On 2012/08/13 23:34:06, ddorwin wrote:
> Thanks. LGTM for me, but you'll need a Pepper team review.

Brett, can you take a look? Thanks!

[Bernhard Bauer, 2012-08-15 20:00:09]

Brett, ping? :)

[brettw, 2012-08-20 05:29:47]

http://codereview.chromium.org/10854040/diff/15001/chrome/browser/ui/browser.cc
File chrome/browser/ui/browser.cc (right):

http://codereview.chromium.org/10854040/diff/15001/chrome/browser/ui/browser....
chrome/browser/ui/browser.cc:1710: void Browser::RequestPpapiBrokerPermission(
You should be able to do this without touching Browser by using
TabContentsObserver. See hung_plugin_tab_helper.h

http://codereview.chromium.org/10854040/diff/15001/content/browser/web_conten...
File content/browser/web_contents/web_contents_impl.cc (right):

http://codereview.chromium.org/10854040/diff/15001/content/browser/web_conten...
content/browser/web_contents/web_contents_impl.cc:2237:
base::Bind(&WebContentsImpl::OnPpapiBrokerPermissionResult,
I don't really understand how the memory management for this works.

http://codereview.chromium.org/10854040/diff/15001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_broker_impl.cc (right):

http://codereview.chromium.org/10854040/diff/15001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_broker_impl.cc:245: void
PepperBrokerImpl::ReportFailureToClients(int error_code) {
I didn't really look at the code in this file, I'm assuming Justin or David did.

http://codereview.chromium.org/10854040/diff/15001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_plugin_delegate_impl.cc (right):

http://codereview.chromium.org/10854040/diff/15001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:852:
webkit::ppapi::ResourceHelper::GetPluginModule(client);
You may want to null check this. Could the plugin be unloaded by the time the
response is received from the browser?

[Bernhard Bauer, 2012-08-20 14:43:20]

https://chromiumcodereview.appspot.com/10854040/diff/15001/chrome/browser/ui/...
File chrome/browser/ui/browser.cc (right):

https://chromiumcodereview.appspot.com/10854040/diff/15001/chrome/browser/ui/...
chrome/browser/ui/browser.cc:1710: void Browser::RequestPpapiBrokerPermission(
On 2012/08/20 05:29:47, brettw wrote:
> You should be able to do this without touching Browser by using
> TabContentsObserver. See hung_plugin_tab_helper.h

I was under the impression that WebContentsObserver is only used for
notifications, not for decisions? Specifically, what would happen if more than
one WebContentsObserver would implement this method and both would call the
callback?

https://chromiumcodereview.appspot.com/10854040/diff/15001/content/browser/we...
File content/browser/web_contents/web_contents_impl.cc (right):

https://chromiumcodereview.appspot.com/10854040/diff/15001/content/browser/we...
content/browser/web_contents/web_contents_impl.cc:2237:
base::Bind(&WebContentsImpl::OnPpapiBrokerPermissionResult,
On 2012/08/20 05:29:47, brettw wrote:
> I don't really understand how the memory management for this works.

The infobar is owned by the InfobarTabHelper, which has the same lifetime as the
WebContentsImpl.

https://chromiumcodereview.appspot.com/10854040/diff/15001/content/renderer/p...
File content/renderer/pepper/pepper_plugin_delegate_impl.cc (right):

https://chromiumcodereview.appspot.com/10854040/diff/15001/content/renderer/p...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:852:
webkit::ppapi::ResourceHelper::GetPluginModule(client);
On 2012/08/20 05:29:47, brettw wrote:
> You may want to null check this. Could the plugin be unloaded by the time the
> response is received from the browser?

Done. Presumably the client would have gone away at this point, but it doesn't
hurt to check.

[brettw, 2012-08-20 23:36:25]

https://chromiumcodereview.appspot.com/10854040/diff/15001/chrome/browser/ui/...
File chrome/browser/ui/browser.cc (right):

https://chromiumcodereview.appspot.com/10854040/diff/15001/chrome/browser/ui/...
chrome/browser/ui/browser.cc:1710: void Browser::RequestPpapiBrokerPermission(
No, the observes "do stuff" as well. If there were two handlers of this, they
would get different copies of the callback, which would be OK, and they could
both show infobars and potentially notify the RenderView. I think this should
all be OK.

If you register two guys as handling this and get two infobars, well, you got
what you wanted!

[Bernhard Bauer, 2012-08-21 11:50:12]

https://chromiumcodereview.appspot.com/10854040/diff/15001/chrome/browser/ui/...
File chrome/browser/ui/browser.cc (right):

https://chromiumcodereview.appspot.com/10854040/diff/15001/chrome/browser/ui/...
chrome/browser/ui/browser.cc:1710: void Browser::RequestPpapiBrokerPermission(
On 2012/08/20 23:36:25, brettw wrote:
> No, the observes "do stuff" as well. If there were two handlers of this, they
> would get different copies of the callback, which would be OK, and they could
> both show infobars and potentially notify the RenderView. I think this should
> all be OK.
> 
> If you register two guys as handling this and get two infobars, well, you got
> what you wanted!

Done.

[brettw, 2012-08-22 22:37:30]

lgtm

https://chromiumcodereview.appspot.com/10854040/diff/9034/content/browser/web...
File content/browser/web_contents/web_contents_impl.h (right):

https://chromiumcodereview.appspot.com/10854040/diff/9034/content/browser/web...
content/browser/web_contents/web_contents_impl.h:492: // |result| is true iff
permission was granted.
"iff" -> "if". I think "iff" doesn't add anything in code comments and just
makes it less natural to read.

[Bernhard Bauer, 2012-08-23 09:37:41]

https://chromiumcodereview.appspot.com/10854040/diff/9034/content/browser/web...
File content/browser/web_contents/web_contents_impl.h (right):

https://chromiumcodereview.appspot.com/10854040/diff/9034/content/browser/web...
content/browser/web_contents/web_contents_impl.h:492: // |result| is true iff
permission was granted.
On 2012/08/22 22:37:31, brettw wrote:
> "iff" -> "if". I think "iff" doesn't add anything in code comments and just
> makes it less natural to read.

Done.

[commit-bot: I haz the power, 2012-08-23 09:38:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bauerb@chromium.org/10854040/19002

[commit-bot: I haz the power, 2012-08-23 10:20:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bauerb@chromium.org/10854040/21004

[commit-bot: I haz the power, 2012-08-23 14:40:52]

Change committed as 152991