Grace, could you please help triage this issue ?

+ alekseys who I believe added default printer selection policy
+ thestig

Can confirm this behavior with some additional information:

The Default Printer setting will apply if it is set to a Native ChromeOS Printer.  It will NOT apply if it is set to a Google Cloud Print connected printer.

I'm moving this to a stable blocker since we're in the middle of beta.  Let's identify the proper eng owner and escalate.  Thanks

M63 stable updates are done..fix should target M64

Does anyone know when this regressed?

The Cloud Print and Native Printer lists were merged recently but it sounds like this but predates that change.  I can take a look.

I can confirm it's still a bug in 65.

It seems to work in 62 so it may have broken in 63

Not in Chromium anymore, reassigning. As far as I remember, this scenario was tested and worked fine back when we added this feature.

I think skau@ is more actively looking at this. Did it breakt between M62 an M63?

r505446 and r506282 are the possible candidates.

- |kPrintPreviewDefaultDestinationSelectionRules| is used in chrome/browser/ui/webui/print_preview/print_preview_handler.cc
- git log 62.0.3202.0..63.0.3239.0 chrome/browser/ui/webui/print_preview/print_preview_handler.cc comes back with 13 changes. Of those, the candidates touched printer destination logic.

On Linux, in PrintPreviewHandler::SendInitialSettings(), I hard coded a rule for a printer named fooprinter. In a new profile, fooprinter comes up as the default.

"{ "kind": "local", "idPattern": "arnold" }"

Maybe if I can figure out what's special about a public session in ChromeOS, I can debug this on Linux.

So is this only happening when the default is set to a cloud printer?

For cloud print to work, doesn't that require a user account to send cloud print jobs? In public sessions, is there a logged in user? https://support.google.com/chrome/a/answer/3017014 says "... for which users don't need to sign in."

For ChromeOS we do something weird for Cloud Print printers.  We authenticate to Cloud Print using the device id.  In cPanel, one can associate Cloud Print printers to devices.

If I had to guess at the root cause, selectDefaultDestination_()[1] is probably called before Cloud Print printers are loaded and we get the selectPdfDestination fallback.

[1] https://codesearch.chromium.org/chromium/src/chrome/browser/resources/print_preview/data/destination_store.js?rcl=7f962d1f920030fa101325bef67fa88bf5cc6833&l=800

I am seeing this in my environment in chrome user settings also. 

In case somebody needs to try to repro, here's what I did to check.

To repro you'll have to do the following:
1. Setup a GSuite Domain
2. Enroll a Chromebook in that domain
3. Go to device settings and add Cloud Print printers to the organization the Chromebook is associated with
4. Go to the Public Sessions settings for that organization and set the default printer pattern
5. Start a public session on the chromebook
6. Use Chromebook and try to print something.

If you want to verify on Linux, I think you could replace rules_str[1] with what you want and you should get the same selection behavior.

[1] https://codesearch.chromium.org/chromium/src/chrome/browser/ui/webui/print_preview/print_preview_handler.cc?rcl=74baec06194cc7ae19210fe46fd6b3df30617180&l=958

I see this is assigned to me now.  Is rbpotter@ around?  I'll have to dig around a bit to figure out how the sequencing has changed for loading printers from various sources.

I can take this if you want, but currently don't have a setup for building/testing on Chromebooks and following all the steps in comment 20, so if we can't reproduce this on Linux (or Windows) it will probably take a while to get to a point where I can test the issue and figure out what is going on.

RE: selectDefaultDestination_(), this gets called if fetching the default printer fails or after a timeout of 15 seconds.

I'll take a look at it Monday and ping you if I get lost then :)

I'll muck around with my Linux build and config to see if I can reproduce this there for a cloud printer. Is yes, then we can skip setting up a GSuite Domain.

skau: Monday is MLK in the US, BTW.

Tried a few different things on Linux:
1) Overrode rules_str to select a cloud printer that was available on the profile I was using, preview dialog correctly selected the printer. 
2) Set the DefaultPrinterSelection policy on Linux (it is available on Win/Linux/Mac also) to select a cloud printer. I tried a couple of different name patterns that corresponded to different available cloud printers, and both were successful.
Since the policy is still working correctly on Linux for cloud printers, I suspect this is related to the different flow for cloud printers on Chrome OS somehow.

One note, if there is a valid recent destination it would be selected over the policy default destination. However, if I understand correctly, in a public session the user is not logged in, so presumably there would be no recent destinations stored and this would not apply.

I have a domain configured, so now I need to get a Chromebook and see if I can enroll it in dev mode. I have a feeling we won't be able to replicate this on bug on Linux unless we can somehow access printers of "DEVICE" type instead of "CLOUD" type. BTW, r195371 added support for "DEVICE" type.

skau: I think I got everything set up to reproduce / bisect / fix the bug here. So you can punt on the bug if you don't have time to work on it.

+mzheng: Are you responsible for public session + printing QA? Can you confirm whether this scenario is covered by QA?
+binzhao: FYI

thestig: I have a few other issues I'm trying to resolve right now if you have the bandwidth to take a look.

For enterprise testing, the policy download looks correct from CPanel to device (verify on chrome://policy).
Test case: 
https://testtracker.googleplex.com/testplans/testcase/detail/168609?id=411&revision=80
 
CC Katherine on client side testing.     

I haven't tracked this down because R63-10032.0.0 with Chrome 63.0.3239.0 doesn't repro the bug for me. I will try some later builds to see if I can repro the bug and bisect.

I tried with R64 and can't reproduce this either. The few times I thought I reproduced the bug, it turns out my Chromebook was not on the network. Thus it could not get the cloud printer list. So to rule that out, I've been navigating to google.com first to make sure the network connection is up.

skau: Can you reproduce this more consistently?

I can reproduce it pretty consistently.  I'm using a Chromebook Flip so it could be considerably slower than what you're using.  It's also ARM (but that shouldn't matter).

I believe you may need to have native printers configured as well?  In which case, I probably broke it ...

I'll have more time to look at it next week if you want to kick it back.

I can repro in 63.0.3239.140. It works ok on 62.0.3202.101. The device is minnie. 
 

My device is a link. If I enroll my Chromebook into one of your domains, would I have a public session set up with the native printer? If so, ping me offline with the credentials to enroll into your domain and I can keep looking.

I was able to repro this in M64 beta for enterprise client side testing. The default printer pattern is configured, but it's shown as "Save as PDF".

Chrome: 64.0.3282.101
Chrome OS: 10176.54.0
Device: Kevin

Please find logs attached.

It works correctly in M62 (9901.79.0/62.0.3202.101).

Deleted: debug-logs_20180118-202620.tgz 126 KB

debug-logs_20180118-202620.tgz 126 KB Download

I enrolled my device into skau's test domain, and now I can reproduce the bug and bisect.

In r503557, the CL changed fetchMatchingDestination_() in chrome/browser/resources/print_preview/data/destination_store.js to take action only on the first successful destination origin match. With the configuration in the test domain, all 4 if / else-if clauses match.

r505446 further changed the code, so simply changing "else if" conditionals back to "if" isn't going to work. Still shouldn't be too hard to fix.

BTW, using test ChromeOS images, I bisected to R63-9953.0.0 (63.0.3218.0) good / R63-9964.0.0 (63.0.3222.0) bad. In that range, there were only 2 changed to chrome/browser/resources/print_preview.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb1110e7c8f311ebe28560be3d2a7d577f76d210

commit fb1110e7c8f311ebe28560be3d2a7d577f76d210
Author: rbpotter <rbpotter@chromium.org>
Date: Tue Jan 23 18:37:03 2018

Print Preview: Fix destination auto select for ChromeOS

Bug:  801181 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I1d5bb284b8e9f4b80b73317c61d5d61522c29a64
Reviewed-on: https://chromium-review.googlesource.com/879246
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531286}
[modify] https://crrev.com/fb1110e7c8f311ebe28560be3d2a7d577f76d210/chrome/browser/resources/print_preview/data/destination_match.js
[modify] https://crrev.com/fb1110e7c8f311ebe28560be3d2a7d577f76d210/chrome/browser/resources/print_preview/data/destination_store.js
[modify] https://crrev.com/fb1110e7c8f311ebe28560be3d2a7d577f76d210/chrome/test/data/webui/print_preview/native_layer_stub.js
[modify] https://crrev.com/fb1110e7c8f311ebe28560be3d2a7d577f76d210/chrome/test/data/webui/print_preview/print_preview_tests.js

Is https://chromium-review.googlesource.com/879246 expected to be the fix for this bug?   

Merged / Tested / Verified?

This should be fixed on ToT/Canary (see comment 42). Can someone who can reproduce this bug please verify that it is working so that we can request a merge if needed? Unfortunately it looks like this has not landed in Dev yet.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.

Looks like ChromeOS canary hasn't bumped chrome to 66.0.3330.0.  I'll verify once we get an image that includes the change.

Still waiting to get a Chrome uprev.  I'll check back in tomorrow.

We're going to Stable with M-64 today.  Since it's marked Fixed, it's not on the blocker list - despite that the fix is not in M-64.  If this is actually a stable blocker for M-64, please raise the alarm asap!

The NextAction date has arrived: 2018-02-02

I've verified the fix in 66.0.3341.0 (canary) on a kefka.

Too late for M64 but should probably merge this to M65 if possible.

This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/70e7b2ee99a9561bdc9536020ce3c5544ca10197

commit 70e7b2ee99a9561bdc9536020ce3c5544ca10197
Author: rbpotter <rbpotter@chromium.org>
Date: Tue Feb 13 01:26:54 2018

Print Preview: Fix destination auto select for ChromeOS (M65)

Bug:  801181 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I1d5bb284b8e9f4b80b73317c61d5d61522c29a64
Reviewed-on: https://chromium-review.googlesource.com/879246
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#531286}(cherry picked from commit fb1110e7c8f311ebe28560be3d2a7d577f76d210)
TBR: thestig@chromium.org, dpapad@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/914596
Reviewed-by: Rebekah Potter <rbpotter@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#440}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/70e7b2ee99a9561bdc9536020ce3c5544ca10197/chrome/browser/resources/print_preview/data/destination_match.js
[modify] https://crrev.com/70e7b2ee99a9561bdc9536020ce3c5544ca10197/chrome/browser/resources/print_preview/data/destination_store.js
[modify] https://crrev.com/70e7b2ee99a9561bdc9536020ce3c5544ca10197/chrome/test/data/webui/print_preview/native_layer_stub.js
[modify] https://crrev.com/70e7b2ee99a9561bdc9536020ce3c5544ca10197/chrome/test/data/webui/print_preview/print_preview_tests.js

Pending Verification on M65

Verified fixed, if the default printer pattern is configured it's shown correctly in Public Session. Verified in M-65 and M-66 as well.

Chrome OS: 10323.51.0
Chrome: 65.0.3325.120
Device: Robo360

Chrome OS: 10452.2.0
Chrome: 66.0.3359.10
Device: Santa

Thanks for verifying the fix. Has anyone looked into updating the Enterprise QA checklist to cover this scenario?