Add onGetUsbPrinterInfoRequested event to printerProvider API.

Add onGetUsbPrinterInfoRequested event to printerProvider API.

This event allows the system to request a printerProvider for information
about a USB printer. This can be used when the app has recently been given
permission to access the device, after the printerProvider has already
provided an regular printer enumeration through onGetUsbPrintersRequested.

BUG=468955
Committed: https://crrev.com/7840286891fbebe83603cc1c73e210c886ea1a76
Cr-Commit-Position: refs/heads/master@{#332452}

[Reilly Grant (use Gerrit), 2015-05-20 22:52:10]

reillyg@chromium.org changed reviewers:
+ asvitkine@chromium.org, vitalybuka@chromium.org

[Reilly Grant (use Gerrit), 2015-05-20 22:53:05]

reillyg@chromium.org changed reviewers:
+ kalman@chromium.org

[Reilly Grant (use Gerrit), 2015-05-21 00:00:52]

Patchset #1 (id:1) has been deleted

[Reilly Grant (use Gerrit), 2015-05-21 00:01:52]

Patchset #1 (id:1) has been deleted

[Reilly Grant (use Gerrit), 2015-05-21 00:28:31]

Vitaly, please take a look at the bulk of this patch.

Alexei, histograms please.

Ben, the //extensions/common and //extensions/renderer bits.

[Vitaly Buka (NO REVIEWS), 2015-05-21 00:38:01]

vitalybuka@chromium.org changed reviewers:
+ tbarzic@chromium.org

[Vitaly Buka (NO REVIEWS), 2015-05-21 00:38:01]

vitalybuka@chromium.org changed reviewers:
+ tbarzic@chromium.org

[Vitaly Buka (NO REVIEWS), 2015-05-21 00:38:02]

+tbarzic

Hi Reilly, I think this patch deserve to be split in two parts:
1. Extension API
2. Preview intergration

[Vitaly Buka (NO REVIEWS), 2015-05-21 00:38:02]

+tbarzic

Hi Reilly, I think this patch deserve to be split in two parts:
1. Extension API
2. Preview intergration

[Reilly Grant (use Gerrit), 2015-05-21 00:51:19]

On 2015/05/21 00:38:02, Vitaly Buka wrote:
> +tbarzic
> 
> Hi Reilly, I think this patch deserve to be split in two parts:
> 1. Extension API
> 2. Preview intergration

Done. This patch is now only the extension API part.

[Vitaly Buka (NO REVIEWS), 2015-05-21 00:52:02]

https://codereview.chromium.org/1148383002/diff/20001/extensions/common/api/p...
File extensions/common/api/printer_provider.idl (right):

https://codereview.chromium.org/1148383002/diff/20001/extensions/common/api/p...
extensions/common/api/printer_provider.idl:86: // undefined that indicates that
the application has determined that the
Looks like this even should be in chrome.usb

Idea was to have printerProvider independent form printer implementation.

[Vitaly Buka (NO REVIEWS), 2015-05-21 00:54:43]

https://codereview.chromium.org/1148383002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/print_preview/data/destination_store.js (right):

https://codereview.chromium.org/1148383002/diff/40001/chrome/browser/resource...
chrome/browser/resources/print_preview/data/destination_store.js:1013: var
filteredPrinters = event.printers.filter(function(printer) {
this piece for another CL?

[Reilly Grant (use Gerrit), 2015-05-21 00:58:22]

https://codereview.chromium.org/1148383002/diff/20001/extensions/common/api/p...
File extensions/common/api/printer_provider.idl (right):

https://codereview.chromium.org/1148383002/diff/20001/extensions/common/api/p...
extensions/common/api/printer_provider.idl:86: // undefined that indicates that
the application has determined that the
On 2015/05/21 00:52:02, Vitaly Buka wrote:
> Looks like this even should be in chrome.usb
> 
> Idea was to have printerProvider independent form printer implementation.

I could add this event to chrome.usb but I would no longer want it to provide a
PrinterInfoCallback. Instead I would add a printerAdded function to
chrome.printerProvider so that providers could add printers to the print preview
dialog outside the context of an enumeration. This would also be useful for when
a printer is connected after the print dialog is opened. What do you think?

[Reilly Grant (use Gerrit), 2015-05-21 00:59:55]

https://codereview.chromium.org/1148383002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/print_preview/data/destination_store.js (right):

https://codereview.chromium.org/1148383002/diff/40001/chrome/browser/resource...
chrome/browser/resources/print_preview/data/destination_store.js:1013: var
filteredPrinters = event.printers.filter(function(printer) {
On 2015/05/21 00:54:43, Vitaly Buka wrote:
> this piece for another CL?

This piece keeps the changes in this CL from having a visible effect until the
WebUI is ready to handle the new entries. The USB printer list is inserted by
the printProvider API layer, not the preview integration layer.

[Vitaly Buka (NO REVIEWS), 2015-05-21 01:52:14]

> I could add this event to chrome.usb but I would no longer want it to provide
a
> PrinterInfoCallback. Instead I would add a printerAdded function to
yes, you will just need to redefine something like PrinterInfo on usb side.
It's a simple structure.

> chrome.printerProvider so that providers could add printers to the print
preview
> dialog outside the context of an enumeration. This would also be useful for
when
> a printer is connected after the print dialog is opened. What do you think?

No any other sources support adding printers after print preview is opened.
Seems cleaner APIs more useful.

Ben, do you have opinion on this?

[Reilly Grant (use Gerrit), 2015-05-21 02:38:36]

On 2015/05/21 01:52:14, Vitaly Buka wrote:
> > I could add this event to chrome.usb but I would no longer want it to
provide
> a
> > PrinterInfoCallback. Instead I would add a printerAdded function to
> yes, you will just need to redefine something like PrinterInfo on usb side.
> It's a simple structure.
> 
> > chrome.printerProvider so that providers could add printers to the print
> preview
> > dialog outside the context of an enumeration. This would also be useful for
> when
> > a printer is connected after the print dialog is opened. What do you think?
> 
> No any other sources support adding printers after print preview is opened.
> Seems cleaner APIs more useful.
> 
> Ben, do you have opinion on this?

If I'm going to have to have the usb API reference the printerProvider API or
vis a versa I'd rather keep this in the printerProvider API. usb is more
generic, no reason to mention printers there. The whole point of this project is
to provide a good integration experience for USB printer providers.

[Vitaly Buka (NO REVIEWS), 2015-05-21 05:32:21]

>> to provide a good integration experience for USB printer providers.
Actually it was for legacy network printers first, USB was added later. Priority
may change again.
API is public. If someone writes extension without requesting usb in manifest,
onUsbAccessGranted is irrelevant.

Another concern is that USB enumeration does not belong to extension API.
Here browser triggers onGetPrintersRequested, extension puts some printers
there, and then implementation
magically extends the list with USB printers. Seems unnecessary.

List of USB printers is needed by PrintPreview only. List has nothing to do with
API.
So better to have that code around print preview. Maybe in
ExtensionPrinterHandler, we can't go closer. 
ExtensionPrinterHandler will enumerate USB printers and show them in UI.
When printer is selected, proper security dialog will be shown and extension
whitelisted for the selected device.

onUsbAccessGranted can be renamed and extended to onGetUsbCapabilityRequested.
Then ExtensionPrinterHandler will trigger
onGetUsbCapabilityRequested(usb.Device device, ....), similar to
onGetCapabilityRequested.
Same for printing: onUsbPrintRequested(usb.Device device, ....)

onGetUsbCapabilityRequested and onUsbPrintRequested looks more obvious than
onUsbAccessGranted.

[Reilly Grant (use Gerrit), 2015-05-22 21:06:36]

On 2015/05/21 05:32:21, Vitaly Buka wrote:
> >> to provide a good integration experience for USB printer providers.
> Actually it was for legacy network printers first, USB was added later.
Priority
> may change again.
> API is public. If someone writes extension without requesting usb in manifest,
> onUsbAccessGranted is irrelevant.
> 
> Another concern is that USB enumeration does not belong to extension API.
> Here browser triggers onGetPrintersRequested, extension puts some printers
> there, and then implementation
> magically extends the list with USB printers. Seems unnecessary.
> 
> List of USB printers is needed by PrintPreview only. List has nothing to do
with
> API.
> So better to have that code around print preview. Maybe in
> ExtensionPrinterHandler, we can't go closer. 
> ExtensionPrinterHandler will enumerate USB printers and show them in UI.
> When printer is selected, proper security dialog will be shown and extension
> whitelisted for the selected device.

Sounds good. I'll separate USB device enumeration into a separate call from the
WebUI.

> onUsbAccessGranted can be renamed and extended to onGetUsbCapabilityRequested.
> Then ExtensionPrinterHandler will trigger
> onGetUsbCapabilityRequested(usb.Device device, ....), similar to
> onGetCapabilityRequested.
> Same for printing: onUsbPrintRequested(usb.Device device, ....)
> 
> onGetUsbCapabilityRequested and onUsbPrintRequested looks more obvious than
> onUsbAccessGranted.

The reason I chose to go with a single new USB related function was so that
PrintPreview could get a normal printer ID and follow the existing path from
then on. Without that a USB printer wouldn't have its description field
populated and its entry would be forever limited to what Chrome can read about
the device on its own (without device-specific knowledge that the printProvider
app has).

[Vitaly Buka (NO REVIEWS), 2015-05-22 21:48:52]

> The reason I chose to go with a single new USB related function was so that
> PrintPreview could get a normal printer ID and follow the existing path from
> then on. Without that a USB printer wouldn't have its description field
> populated and its entry would be forever limited to what Chrome can read about
> the device on its own (without device-specific knowledge that the
printProvider
> app has).

I see, so you expect to have printer details from extension

Then maybe: onUsbAccessGranted -> onGetUsbPrinterInfo
because primary goal is not to notify extension about permissions, but to make
Extension to call callback with PrinterInfo

I am not sure which one is better:
1. PrinterInfo with optional usb id
with events:
onGetCapabilityRequested
onPrintRequested 
onGetUsbPrinterInfo

or

2. PrinterInfo without optional usb id
with events:
onGetCapabilityRequested
onPrintRequested 
onGetUsbPrinterInfo
onGetUsbCapabilityRequested
onPrintUsbRequested 

I like API in No.2, but No.1 has smaller implementation.

[tbarzic, 2015-05-22 22:13:34]

On 2015/05/22 21:48:52, Vitaly Buka wrote:
> > The reason I chose to go with a single new USB related function was so that
> > PrintPreview could get a normal printer ID and follow the existing path from
> > then on. Without that a USB printer wouldn't have its description field
> > populated and its entry would be forever limited to what Chrome can read
about
> > the device on its own (without device-specific knowledge that the
> printProvider
> > app has).
> 
> I see, so you expect to have printer details from extension
> 
> Then maybe: onUsbAccessGranted -> onGetUsbPrinterInfo
> because primary goal is not to notify extension about permissions, but to make
> Extension to call callback with PrinterInfo
> 
> I am not sure which one is better:
> 1. PrinterInfo with optional usb id
> with events:
> onGetCapabilityRequested
> onPrintRequested 
> onGetUsbPrinterInfo
> 
> or
> 
> 2. PrinterInfo without optional usb id
> with events:
> onGetCapabilityRequested
> onPrintRequested 
> onGetUsbPrinterInfo
> onGetUsbCapabilityRequested
> onPrintUsbRequested 
> 
> I like API in No.2, but No.1 has smaller implementation.

I wonder if we could avoid adding USB id to PrinterInfo. Afaik, the main usage
of this property would be to make sure intersection of sets of printers returned
by extension and those added by enumerating USB devices is empty. Could we
instead just filter out extensions that have access to a printer in
PrinterProviderAPIImpl::OnUsbDevicesEnumerated?

[Reilly Grant (use Gerrit), 2015-05-22 22:16:31]

On 2015/05/22 22:13:34, tbarzic wrote:
> On 2015/05/22 21:48:52, Vitaly Buka wrote:
> > > The reason I chose to go with a single new USB related function was so
that
> > > PrintPreview could get a normal printer ID and follow the existing path
from
> > > then on. Without that a USB printer wouldn't have its description field
> > > populated and its entry would be forever limited to what Chrome can read
> about
> > > the device on its own (without device-specific knowledge that the
> > printProvider
> > > app has).
> > 
> > I see, so you expect to have printer details from extension
> > 
> > Then maybe: onUsbAccessGranted -> onGetUsbPrinterInfo
> > because primary goal is not to notify extension about permissions, but to
make
> > Extension to call callback with PrinterInfo
> > 
> > I am not sure which one is better:
> > 1. PrinterInfo with optional usb id
> > with events:
> > onGetCapabilityRequested
> > onPrintRequested 
> > onGetUsbPrinterInfo
> > 
> > or
> > 
> > 2. PrinterInfo without optional usb id
> > with events:
> > onGetCapabilityRequested
> > onPrintRequested 
> > onGetUsbPrinterInfo
> > onGetUsbCapabilityRequested
> > onPrintUsbRequested 
> > 
> > I like API in No.2, but No.1 has smaller implementation.
> 
> I wonder if we could avoid adding USB id to PrinterInfo. Afaik, the main usage
> of this property would be to make sure intersection of sets of printers
returned
> by extension and those added by enumerating USB devices is empty. Could we
> instead just filter out extensions that have access to a printer in
> PrinterProviderAPIImpl::OnUsbDevicesEnumerated?

Yes, I'll work this into the next version of the patches which will start with
API No.1 above because as Vitaly said it has a much smaller implementation.

[Alexei Svitkine (slow), 2015-05-25 15:24:12]

histograms.xml lgtm, did not look at anything else

[Reilly Grant (use Gerrit), 2015-05-26 23:17:55]

Okay, this patch now only contains the permission granting portion of the
feature.

[tbarzic, 2015-05-27 00:11:03]

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
File extensions/browser/api/printer_provider/printer_provider_api.cc (right):

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
extensions/browser/api/printer_provider/printer_provider_api.cc:721:
pending_usb_printer_info_requests_[extension->id()].Complete(request_id,
Can you reuse code from PrinterProviderAPIImpl::OnGetPrintersResult for
generating DictValue from printer_info (to set extension id, name, generate
right printer id)

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
File extensions/browser/api/printer_provider/printer_provider_api.h (right):

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
extensions/browser/api/printer_provider/printer_provider_api.h:88: // Notifies
the given extension that it has been granted access to the given
Comment is unfinished

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
File extensions/browser/api/printer_provider/printer_provider_apitest.cc
(right):

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
extensions/browser/api/printer_provider/printer_provider_apitest.cc:845: }
can you add a test case for when the extension doesn't have onUsbAccessGranted
event listener

https://codereview.chromium.org/1148383002/diff/60001/extensions/test/data/ap...
File extensions/test/data/api_test/printer_provider/usb_printers/test.js
(right):

https://codereview.chromium.org/1148383002/diff/60001/extensions/test/data/ap...
extensions/test/data/api_test/printer_provider/usb_printers/test.js:33: 'id':
'granted-' + device.device,
generally, destinations for a printer returned by onGetPrintersRequested and
onUsbAccessGranted should have the same id, so I'd use the same id here also.

[Reilly Grant (use Gerrit), 2015-05-28 21:04:11]

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
File extensions/browser/api/printer_provider/printer_provider_api.cc (right):

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
extensions/browser/api/printer_provider/printer_provider_api.cc:721:
pending_usb_printer_info_requests_[extension->id()].Complete(request_id,
On 2015/05/27 00:11:03, tbarzic wrote:
> Can you reuse code from PrinterProviderAPIImpl::OnGetPrintersResult for
> generating DictValue from printer_info (to set extension id, name, generate
> right printer id)

Done.

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
File extensions/browser/api/printer_provider/printer_provider_api.h (right):

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
extensions/browser/api/printer_provider/printer_provider_api.h:88: // Notifies
the given extension that it has been granted access to the given
On 2015/05/27 00:11:03, tbarzic wrote:
> Comment is unfinished

Done.

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
File extensions/browser/api/printer_provider/printer_provider_apitest.cc
(right):

https://codereview.chromium.org/1148383002/diff/60001/extensions/browser/api/...
extensions/browser/api/printer_provider/printer_provider_apitest.cc:845: }
On 2015/05/27 00:11:03, tbarzic wrote:
> can you add a test case for when the extension doesn't have onUsbAccessGranted
> event listener

Done.

https://codereview.chromium.org/1148383002/diff/60001/extensions/test/data/ap...
File extensions/test/data/api_test/printer_provider/usb_printers/test.js
(right):

https://codereview.chromium.org/1148383002/diff/60001/extensions/test/data/ap...
extensions/test/data/api_test/printer_provider/usb_printers/test.js:33: 'id':
'granted-' + device.device,
On 2015/05/27 00:11:03, tbarzic wrote:
> generally, destinations for a printer returned by onGetPrintersRequested and
> onUsbAccessGranted should have the same id, so I'd use the same id here also.

Done.

[Vitaly Buka (NO REVIEWS), 2015-05-28 21:51:28]

lgtm

lgtm

https://codereview.chromium.org/1148383002/diff/100001/extensions/browser/api...
File extensions/browser/api/printer_provider/printer_provider_api.cc (right):

https://codereview.chromium.org/1148383002/diff/100001/extensions/browser/api...
extensions/browser/api/printer_provider/printer_provider_api.cc:480: if (it ==
pending_requests_.end()) {
{} here is inconsistent with the rest of file

same for other files

[Vitaly Buka (NO REVIEWS), 2015-05-28 21:51:28]

lgtm

https://codereview.chromium.org/1148383002/diff/100001/extensions/browser/api...
File extensions/browser/api/printer_provider/printer_provider_api.cc (right):

https://codereview.chromium.org/1148383002/diff/100001/extensions/browser/api...
extensions/browser/api/printer_provider/printer_provider_api.cc:480: if (it ==
pending_requests_.end()) {
{} here is inconsistent with the rest of file

same for other files

[tbarzic, 2015-05-28 22:20:50]

https://codereview.chromium.org/1148383002/diff/120001/chrome/browser/ui/webu...
File chrome/browser/ui/webui/print_preview/extension_printer_handler_unittest.cc
(right):

https://codereview.chromium.org/1148383002/diff/120001/chrome/browser/ui/webu...
chrome/browser/ui/webui/print_preview/extension_printer_handler_unittest.cc:304:
NOTREACHED();
s/NOTREACHED()/ADD_FAILURE() << "Not reached"/

(I usually try to avoid CHECKS in unittests)

https://codereview.chromium.org/1148383002/diff/120001/extensions/common/api/...
File extensions/common/api/printer_provider.idl (right):

https://codereview.chromium.org/1148383002/diff/120001/extensions/common/api/...
extensions/common/api/printer_provider.idl:79: // that may be a printer.
Add a note that the extension should not rely on this event being fired more
than once per device (and, if the device is supported, should include this
printer in the list returned by onGetPrintersRequested)

[Reilly Grant (use Gerrit), 2015-05-28 22:38:58]

https://codereview.chromium.org/1148383002/diff/120001/chrome/browser/ui/webu...
File chrome/browser/ui/webui/print_preview/extension_printer_handler_unittest.cc
(right):

https://codereview.chromium.org/1148383002/diff/120001/chrome/browser/ui/webu...
chrome/browser/ui/webui/print_preview/extension_printer_handler_unittest.cc:304:
NOTREACHED();
On 2015/05/28 22:20:50, tbarzic wrote:
> s/NOTREACHED()/ADD_FAILURE() << "Not reached"/
> 
> (I usually try to avoid CHECKS in unittests)

Done.

https://codereview.chromium.org/1148383002/diff/120001/extensions/common/api/...
File extensions/common/api/printer_provider.idl (right):

https://codereview.chromium.org/1148383002/diff/120001/extensions/common/api/...
extensions/common/api/printer_provider.idl:79: // that may be a printer.
On 2015/05/28 22:20:50, tbarzic wrote:
> Add a note that the extension should not rely on this event being fired more
> than once per device (and, if the device is supported, should include this
> printer in the list returned by onGetPrintersRequested)

Done.

[tbarzic, 2015-05-28 22:42:23]

lgtm

https://codereview.chromium.org/1148383002/diff/160001/extensions/common/api/...
File extensions/common/api/printer_provider.idl (right):

https://codereview.chromium.org/1148383002/diff/160001/extensions/common/api/...
extensions/common/api/printer_provider.idl:81: // should be returned in the
onGetPrintersRequested event.
$(ref:onGetPrintersRequested)

[Reilly Grant (use Gerrit), 2015-05-28 22:47:01]

https://codereview.chromium.org/1148383002/diff/160001/extensions/common/api/...
File extensions/common/api/printer_provider.idl (right):

https://codereview.chromium.org/1148383002/diff/160001/extensions/common/api/...
extensions/common/api/printer_provider.idl:81: // should be returned in the
onGetPrintersRequested event.
On 2015/05/28 22:42:22, tbarzic wrote:
> $(ref:onGetPrintersRequested)

Done.

[not at google - send to devlin, 2015-06-01 18:30:00]

lgtm

[Reilly Grant (use Gerrit), 2015-06-01 19:21:59]

The CQ bit was checked by reillyg@chromium.org

[Reilly Grant (use Gerrit), 2015-06-01 19:22:00]

The patchset sent to the CQ was uploaded after l-g-t-m from
asvitkine@chromium.org, vitalybuka@chromium.org, tbarzic@chromium.org
Link to the patchset: https://codereview.chromium.org/1148383002/#ps200001
(title: "Rebased.")

[commit-bot: I haz the power, 2015-06-01 19:28:09]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1148383002/200001

[commit-bot: I haz the power, 2015-06-01 20:32:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-01 20:32:15]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Reilly Grant (use Gerrit), 2015-06-01 20:58:10]

The CQ bit was checked by reillyg@chromium.org

[Reilly Grant (use Gerrit), 2015-06-01 20:58:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
vitalybuka@chromium.org, asvitkine@chromium.org, tbarzic@chromium.org,
kalman@chromium.org
Link to the patchset: https://codereview.chromium.org/1148383002/#ps220001
(title: "Fix Windows build.")

[commit-bot: I haz the power, 2015-06-01 21:00:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1148383002/220001

[commit-bot: I haz the power, 2015-06-01 21:07:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-01 21:07:38]

Try jobs failed on following builders:
  linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)

[Reilly Grant (use Gerrit), 2015-06-01 21:51:09]

The CQ bit was checked by reillyg@chromium.org

[Reilly Grant (use Gerrit), 2015-06-01 21:51:10]

The patchset sent to the CQ was uploaded after l-g-t-m from
vitalybuka@chromium.org, asvitkine@chromium.org, tbarzic@chromium.org,
kalman@chromium.org
Link to the patchset: https://codereview.chromium.org/1148383002/#ps190015
(title: "Rebased.")

[commit-bot: I haz the power, 2015-06-01 23:35:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1148383002/190015

[Reilly Grant (use Gerrit), 2015-06-02 00:04:09]

The CQ bit was unchecked by reillyg@chromium.org

[Reilly Grant (use Gerrit), 2015-06-02 18:17:39]

The CQ bit was checked by reillyg@chromium.org

[Reilly Grant (use Gerrit), 2015-06-02 18:17:40]

The patchset sent to the CQ was uploaded after l-g-t-m from
vitalybuka@chromium.org, asvitkine@chromium.org, tbarzic@chromium.org,
kalman@chromium.org
Link to the patchset: https://codereview.chromium.org/1148383002/#ps290001
(title: "Rebased.")

[commit-bot: I haz the power, 2015-06-02 18:19:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1148383002/290001

[commit-bot: I haz the power, 2015-06-02 19:52:36]

Committed patchset #15 (id:290001)

[commit-bot: I haz the power, 2015-06-02 19:53:44]

Patchset 15 (id:??) landed as
https://crrev.com/7840286891fbebe83603cc1c73e210c886ea1a76
Cr-Commit-Position: refs/heads/master@{#332452}