List printers managed by extensions in print preview

List printers managed by extensions in print preview

The CL adds support for print destinations managed by extensions (using
chrome.printerProvider API) to print preview.
These destinations are added to local printers list with the icon set to
the extension icon, but that will probably be changed before the API
goes to stable.

Also, this does not implement print requests for these destinations, so
the 'Print' button is disabled for them.

BUG=408772
Committed: https://crrev.com/598c3e9b0e32c0e11debfa2d2da79586c5576a59
Cr-Commit-Position: refs/heads/master@{#314621}

[tbarzic, 2015-02-03 02:21:13]

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

[Vitaly Buka (NO REVIEWS), 2015-02-03 16:55:48]

lgtm

Aleksey, PTAL?

https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
File chrome/browser/ui/webui/print_preview/print_preview_handler.cc (right):

https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
chrome/browser/ui/webui/print_preview/print_preview_handler.cc:744: ok = ok &&
args->GetString(0, &extension_id);
bool ok = GetString(extension_id)
DCHECK(ok)

ok = GetString(printer_id)
DCHECK(ok)

https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
chrome/browser/ui/webui/print_preview/print_preview_handler.cc:1656:
base::StringValue(printer_id),
consider merging them here and use single string as ID on js side.

https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
File chrome/browser/ui/webui/print_preview/print_preview_handler.h (right):

https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
chrome/browser/ui/webui/print_preview/print_preview_handler.h:305: const
std::string& extension_id,
why do we need to have separate extension id and printer id here.
Can we just combine them on native layer and just have single string here?

[tbarzic, 2015-02-03 17:07:27]

https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
File chrome/browser/ui/webui/print_preview/print_preview_handler.cc (right):

https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
chrome/browser/ui/webui/print_preview/print_preview_handler.cc:1656:
base::StringValue(printer_id),
On 2015/02/03 16:55:48, Vitaly Buka wrote:
> consider merging them here and use single string as ID on js side.

I had a similar idea. The main reason these are merged to a single id on js side
is that extension id is needed to create initially (auto) selected destination
in case it's an extension destination. This means that webui layer would have to
know how to parse the extension id from the destination id saved in the app
state (and I'd rather have this logic both in natie and webui layer).

I guess this could be solved by adding extension id field to app state. wdyt?

[Vitaly Buka (NO REVIEWS), 2015-02-03 17:12:30]

I am more concerting about new filed extensionID in destination.
Why WebUI need extension ID?

On 2015/02/03 17:07:27, tbarzic wrote:
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> File chrome/browser/ui/webui/print_preview/print_preview_handler.cc (right):
> 
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> chrome/browser/ui/webui/print_preview/print_preview_handler.cc:1656:
> base::StringValue(printer_id),
> On 2015/02/03 16:55:48, Vitaly Buka wrote:
> > consider merging them here and use single string as ID on js side.
> 
> I had a similar idea. The main reason these are merged to a single id on js
side
> is that extension id is needed to create initially (auto) selected destination
> in case it's an extension destination. This means that webui layer would have
to
> know how to parse the extension id from the destination id saved in the app
> state (and I'd rather have this logic both in natie and webui layer).
> 
> I guess this could be solved by adding extension id field to app state. wdyt?

[Vitaly Buka (NO REVIEWS), 2015-02-03 17:13:46]

On 2015/02/03 17:12:30, Vitaly Buka wrote:
> I am more concerting about new filed extensionID in destination.
> Why WebUI need extension ID?
> 
> On 2015/02/03 17:07:27, tbarzic wrote:
> >
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> > File chrome/browser/ui/webui/print_preview/print_preview_handler.cc (right):
> > 
> >
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> > chrome/browser/ui/webui/print_preview/print_preview_handler.cc:1656:
> > base::StringValue(printer_id),
> > On 2015/02/03 16:55:48, Vitaly Buka wrote:
> > > consider merging them here and use single string as ID on js side.
> > 
> > I had a similar idea. The main reason these are merged to a single id on js
> side
> > is that extension id is needed to create initially (auto) selected
destination
> > in case it's an extension destination. This means that webui layer would
have
> to
> > know how to parse the extension id from the destination id saved in the app
> > state (and I'd rather have this logic both in natie and webui layer).
> > 
> > I guess this could be solved by adding extension id field to app state.
wdyt?

I see, for icon.

[tbarzic, 2015-02-03 17:16:33]

yeah, even if the exact UI changes, we'll probably still need a way to
attribute the printer to the extension (which will require extension id).

On Tue, Feb 3, 2015 at 9:13 AM, <vitalybuka@chromium.org> wrote:

> On 2015/02/03 17:12:30, Vitaly Buka wrote:
>
>> I am more concerting about new filed extensionID in destination.
>> Why WebUI need extension ID?
>>
>
>  On 2015/02/03 17:07:27, tbarzic wrote:
>> >
>>
>
> https://codereview.chromium.org/900503002/diff/1/chrome/
> browser/ui/webui/print_preview/print_preview_handler.cc
>
>> > File chrome/browser/ui/webui/print_preview/print_preview_handler.cc
>> (right):
>> >
>> >
>>
>
> https://codereview.chromium.org/900503002/diff/1/chrome/
> browser/ui/webui/print_preview/print_preview_handler.cc#newcode1656
>
>> > chrome/browser/ui/webui/print_preview/print_preview_handler.cc:1656:
>> > base::StringValue(printer_id),
>> > On 2015/02/03 16:55:48, Vitaly Buka wrote:
>> > > consider merging them here and use single string as ID on js side.
>> >
>> > I had a similar idea. The main reason these are merged to a single id
>> on js
>> side
>> > is that extension id is needed to create initially (auto) selected
>>
> destination
>
>> > in case it's an extension destination. This means that webui layer would
>>
> have
>
>> to
>> > know how to parse the extension id from the destination id saved in the
>> app
>> > state (and I'd rather have this logic both in natie and webui layer).
>> >
>> > I guess this could be solved by adding extension id field to app state.
>>
> wdyt?
>
> I see, for icon.
>
> https://codereview.chromium.org/900503002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Vitaly Buka (NO REVIEWS), 2015-02-03 17:16:43]

On 2015/02/03 17:13:46, Vitaly Buka wrote:
> On 2015/02/03 17:12:30, Vitaly Buka wrote:
> > I am more concerting about new filed extensionID in destination.
> > Why WebUI need extension ID?
> > 
> > On 2015/02/03 17:07:27, tbarzic wrote:
> > >
> >
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> > > File chrome/browser/ui/webui/print_preview/print_preview_handler.cc
(right):
> > > 
> > >
> >
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> > > chrome/browser/ui/webui/print_preview/print_preview_handler.cc:1656:
> > > base::StringValue(printer_id),
> > > On 2015/02/03 16:55:48, Vitaly Buka wrote:
> > > > consider merging them here and use single string as ID on js side.
> > > 
> > > I had a similar idea. The main reason these are merged to a single id on
js
> > side
> > > is that extension id is needed to create initially (auto) selected
> destination
> > > in case it's an extension destination. This means that webui layer would
> have
> > to
> > > know how to parse the extension id from the destination id saved in the
app
> > > state (and I'd rather have this logic both in natie and webui layer).
> > > 
> > > I guess this could be solved by adding extension id field to app state.
> wdyt?
> 
> I see, for icon.

So I'd pass combined string, and to WebUI and extracted ID only in icon code,
because we even not sure if this is going to be on UI.

[tbarzic, 2015-02-03 17:19:20]

On 2015/02/03 17:16:43, Vitaly Buka wrote:
> On 2015/02/03 17:13:46, Vitaly Buka wrote:
> > On 2015/02/03 17:12:30, Vitaly Buka wrote:
> > > I am more concerting about new filed extensionID in destination.
> > > Why WebUI need extension ID?
> > > 
> > > On 2015/02/03 17:07:27, tbarzic wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> > > > File chrome/browser/ui/webui/print_preview/print_preview_handler.cc
> (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> > > > chrome/browser/ui/webui/print_preview/print_preview_handler.cc:1656:
> > > > base::StringValue(printer_id),
> > > > On 2015/02/03 16:55:48, Vitaly Buka wrote:
> > > > > consider merging them here and use single string as ID on js side.
> > > > 
> > > > I had a similar idea. The main reason these are merged to a single id on
> js
> > > side
> > > > is that extension id is needed to create initially (auto) selected
> > destination
> > > > in case it's an extension destination. This means that webui layer would
> > have
> > > to
> > > > know how to parse the extension id from the destination id saved in the
> app
> > > > state (and I'd rather have this logic both in natie and webui layer).
> > > > 
> > > > I guess this could be solved by adding extension id field to app state.
> > wdyt?
> > 
> > I see, for icon.
> 
> So I'd pass combined string, and to WebUI and extracted ID only in icon code,
> because we even not sure if this is going to be on UI.

OK, fine by me (we can always revert back to this if it ends up making more
sense)

[Vitaly Buka (NO REVIEWS), 2015-02-03 17:20:59]

On 2015/02/03 17:19:20, tbarzic wrote:
> On 2015/02/03 17:16:43, Vitaly Buka wrote:
> > On 2015/02/03 17:13:46, Vitaly Buka wrote:
> > > On 2015/02/03 17:12:30, Vitaly Buka wrote:
> > > > I am more concerting about new filed extensionID in destination.
> > > > Why WebUI need extension ID?
> > > > 
> > > > On 2015/02/03 17:07:27, tbarzic wrote:
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> > > > > File chrome/browser/ui/webui/print_preview/print_preview_handler.cc
> > (right):
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/900503002/diff/1/chrome/browser/ui/webui/prin...
> > > > > chrome/browser/ui/webui/print_preview/print_preview_handler.cc:1656:
> > > > > base::StringValue(printer_id),
> > > > > On 2015/02/03 16:55:48, Vitaly Buka wrote:
> > > > > > consider merging them here and use single string as ID on js side.
> > > > > 
> > > > > I had a similar idea. The main reason these are merged to a single id
on
> > js
> > > > side
> > > > > is that extension id is needed to create initially (auto) selected
> > > destination
> > > > > in case it's an extension destination. This means that webui layer
would
> > > have
> > > > to
> > > > > know how to parse the extension id from the destination id saved in
the
> > app
> > > > > state (and I'd rather have this logic both in natie and webui layer).
> > > > > 
> > > > > I guess this could be solved by adding extension id field to app
state.
> > > wdyt?
> > > 
> > > I see, for icon.
> > 
> > So I'd pass combined string, and to WebUI and extracted ID only in icon
code,
> > because we even not sure if this is going to be on UI.
> 
> OK, fine by me (we can always revert back to this if it ends up making more
> sense)

Actually I am OK with current one. Maybe Alexey has strong opinion.

[Aleksey Shlyapnikov, 2015-02-03 20:18:24]

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/print_preview/data/destination_store.js (right):

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/destination_store.js:233:
DestinationStore.EXTENSION_SEARCH_DURATION_ = 2000;
Just 2 seconds?

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/print_preview/data/local_parsers.js (right):

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:87:
ExtensionDestinationParser.generateDestinationID = function(extensionID,
generateDestinationId

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:99:
ExtensionDestinationParser.parseDestinationID = function(destinationID) {
parseDestinationId

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:100: var splitID =
destinationID.split(ExtensionDestinationParser.ID_SEPARATOR_);
splitId

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:107: };
I've read your discussion about gluing/parsing the id in the js layer and I
think js layer should not care about it. It should be done in .cc, gluing them
on the way in (receiving printer list) and parsing on the way out (requesting
printer capabilities). Id must be unique, .cc layer ensures that by gluing
extid+printerid, js layer ensures uniqueness by adding printer origin.

Now, all you really need the extension id for is loading the last selected
printer, right? I think it's better to explicitly add the extension id to the
appsate.

Another idea worth considering is to store the entire destination object in
appsate instead of bunch of fields we extract from it now, but let's not get
into this topic in this cl.

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:125: extensionID:
destinationInfo.extensionId});
extensionId

Anyway, please change all ...ID identifiers to ...Id. I know we have such IDs in
the code, but I consider them legacy, will rename them one day and let's not add
more of those.

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/print_preview/native_layer.js (right):

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/native_layer.js:776: * @param {Object}
capabilities The reported printer capabilities.
!Object or can they be null?

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/native_layer.js:782: event.extensionID =
extensionId;
extensionId

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/native_layer.js:783: event.printerID =
printerId;
printerId

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/ui/webui/...
File chrome/browser/ui/webui/print_preview/print_preview_handler.cc (right):

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/print_preview/print_preview_handler.cc:728: // complete.
I'm fine with implementing it later. Just curious, are you planning to add a
token to the request to filter out obsolete results or counter on the js side to
wait for all outstanding requests to finish?

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/print_preview/print_preview_handler.cc:757:
base::DictionaryValue());
Empty capabilities are not valid. How do you plan to handle failure case? What
if that extension does not handle that printer anymore or just want to report a
problem?

[tbarzic, 2015-02-04 02:21:23]

Moved printer id marshaling to PrinterProviderAPI.

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/print_preview/data/destination_store.js (right):

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/destination_store.js:233:
DestinationStore.EXTENSION_SEARCH_DURATION_ = 2000;
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> Just 2 seconds?

I can increase the number a bit, but few seconds should be enough (we can
increase the timeout later if needed).

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/print_preview/data/local_parsers.js (right):

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:87:
ExtensionDestinationParser.generateDestinationID = function(extensionID,
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> generateDestinationId

removed

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:99:
ExtensionDestinationParser.parseDestinationID = function(destinationID) {
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> parseDestinationId

removed

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:100: var splitID =
destinationID.split(ExtensionDestinationParser.ID_SEPARATOR_);
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> splitId

removed

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:107: };
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> I've read your discussion about gluing/parsing the id in the js layer and I
> think js layer should not care about it. It should be done in .cc, gluing them
> on the way in (receiving printer list) and parsing on the way out (requesting
> printer capabilities). Id must be unique, .cc layer ensures that by gluing
> extid+printerid, js layer ensures uniqueness by adding printer origin.
> 
> Now, all you really need the extension id for is loading the last selected
> printer, right? I think it's better to explicitly add the extension id to the
> appsate.
> 
> Another idea worth considering is to store the entire destination object in
> appsate instead of bunch of fields we extract from it now, but let's not get
> into this topic in this cl.

OK sounds good; Done

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/local_parsers.js:125: extensionID:
destinationInfo.extensionId});
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> extensionId
> 
> Anyway, please change all ...ID identifiers to ...Id. I know we have such IDs
in
> the code, but I consider them legacy, will rename them one day and let's not
add
> more of those.

Done.

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/print_preview/native_layer.js (right):

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/native_layer.js:776: * @param {Object}
capabilities The reported printer capabilities.
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> !Object or can they be null?

Done.

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/native_layer.js:782: event.extensionID =
extensionId;
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> extensionId

removed

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/resources...
chrome/browser/resources/print_preview/native_layer.js:783: event.printerID =
printerId;
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> printerId

Done.

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/ui/webui/...
File chrome/browser/ui/webui/print_preview/print_preview_handler.cc (right):

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/print_preview/print_preview_handler.cc:728: // complete.
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> I'm fine with implementing it later. Just curious, are you planning to add a
> token to the request to filter out obsolete results or counter on the js side
to
> wait for all outstanding requests to finish?

Closer to former. I'll probably just end up invalidating weak ptr to which the
callback is bound (effectively filtering out obsolete results).

https://codereview.chromium.org/900503002/diff/20001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/print_preview/print_preview_handler.cc:757:
base::DictionaryValue());
On 2015/02/03 20:18:24, Aleksey Shlyapnikov wrote:
> Empty capabilities are not valid. How do you plan to handle failure case? What
> if that extension does not handle that printer anymore or just want to report
a
> problem?

Added error handling.

[Vitaly Buka (NO REVIEWS), 2015-02-04 02:54:45]

lgtm

https://codereview.chromium.org/900503002/diff/80001/chrome/browser/resources...
File chrome/browser/resources/print_preview/data/destination_store.js (right):

https://codereview.chromium.org/900503002/diff/80001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/destination_store.js:377:
this.appState_.selectedDestinationExtensionId) {
this should be impossible

[Aleksey Shlyapnikov, 2015-02-04 18:50:27]

lgtm

https://codereview.chromium.org/900503002/diff/80001/chrome/browser/resources...
File chrome/browser/resources/print_preview/data/destination.js (right):

https://codereview.chromium.org/900503002/diff/80001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/destination.js:361: *     for
extension managed printers.
Nit: It is always set, it's just set to '' for non-extension printers.

https://codereview.chromium.org/900503002/diff/80001/extensions/browser/api/p...
File extensions/browser/api/printer_provider/printer_provider_apitest.cc
(right):

https://codereview.chromium.org/900503002/diff/80001/extensions/browser/api/p...
extensions/browser/api/printer_provider/printer_provider_apitest.cc:271:
"\"id\":\"%s:printer1\","
I think %1$s refers to the first parameter, so you won't need to repeat it
twice.

[tbarzic, 2015-02-04 19:26:09]

New patchsets have been uploaded after l-g-t-m from
vitalybuka@chromium.org,alekseys@chromium.org

[tbarzic, 2015-02-04 19:27:41]

https://codereview.chromium.org/900503002/diff/80001/chrome/browser/resources...
File chrome/browser/resources/print_preview/data/destination.js (right):

https://codereview.chromium.org/900503002/diff/80001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/destination.js:361: *     for
extension managed printers.
On 2015/02/04 18:50:27, Aleksey Shlyapnikov wrote:
> Nit: It is always set, it's just set to '' for non-extension printers.

Done.

https://codereview.chromium.org/900503002/diff/80001/chrome/browser/resources...
File chrome/browser/resources/print_preview/data/destination_store.js (right):

https://codereview.chromium.org/900503002/diff/80001/chrome/browser/resources...
chrome/browser/resources/print_preview/data/destination_store.js:377:
this.appState_.selectedDestinationExtensionId) {
On 2015/02/04 02:54:45, Vitaly Buka wrote:
> this should be impossible

Done.

https://codereview.chromium.org/900503002/diff/80001/extensions/browser/api/p...
File extensions/browser/api/printer_provider/printer_provider_apitest.cc
(right):

https://codereview.chromium.org/900503002/diff/80001/extensions/browser/api/p...
extensions/browser/api/printer_provider/printer_provider_apitest.cc:271:
"\"id\":\"%s:printer1\","
On 2015/02/04 18:50:27, Aleksey Shlyapnikov wrote:
> I think %1$s refers to the first parameter, so you won't need to repeat it
> twice.

Done.

[tbarzic, 2015-02-04 19:27:48]

The CQ bit was checked by tbarzic@chromium.org

[commit-bot: I haz the power, 2015-02-04 19:29:12]

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

[commit-bot: I haz the power, 2015-02-04 20:16:23]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-02-04 20:17:41]

Patchset 6 (id:??) landed as
https://crrev.com/598c3e9b0e32c0e11debfa2d2da79586c5576a59
Cr-Commit-Position: refs/heads/master@{#314621}

[Nico, 2015-02-06 00:46:22]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2015-02-06 00:46:23]

https://codereview.chromium.org/900503002/diff/80001/extensions/browser/api/p...
File extensions/browser/api/printer_provider/printer_provider_apitest.cc
(right):

https://codereview.chromium.org/900503002/diff/80001/extensions/browser/api/p...
extensions/browser/api/printer_provider/printer_provider_apitest.cc:271:
"\"id\":\"%s:printer1\","
(fyi: https://codereview.chromium.org/902643002/ undoes this. strange
coincidence that this change happened on the same day i'm cq'ing my change, as
this feature has historically been used very rarely in the chrome codebase)