Hi Soushi, what is the behavior is use-mode? Can you please check and update the bug? Thanks.

Thank Raj, although yes the behaviour is the same with user signed-in this impacts PS greater as the permission acceptance (seen in Permission_Screenshot...png) is necessary each time a PS is entered.

It appears setting default printer as a USB printer is not possible in any manner without user accepting the permission, which at least for PS I think we should bypass this requirement.

Sunil, fyi

Thanks for cc-ing me Raj.

If I'm understanding this right, flow is identical for both the user mode and in public session. However, not a great experience in PS mode since it needs to be done in every new session.

And this is specific to HP Print Extension for USB printer. Is that right?

Hi Drew, can this requirement be by-passed in PS for whitelisted extensions? Thanks.

Ivan, do you know what's happening here?

Yes in this scenario it's with the HP Print Extension for USB printer. 
We don't have a Ricoh printer to test the Ricoh extension that supports USB printing (ioofdkhojeeimmagbjbknkejkgbphdfl), but I'm suspecting we'll have the same issue.
Per #7, if it can indeed be by-passed for whitelisted extensions, that sounds like a solution here.

@isandrk, have you had a chance to have a look or feedback to c#9?

Good thing you pinged me. I'm not too familiar with the printing code, and there's a guy sitting close to Raj that worked a bit on it, so I'm hoping Raj can have a chat with him about this these days.

Adding @bblietz to this thread (person comment #11 is referring to i think).

Brian - In public sessions, for HP Print extension for USB printer, user needs to accept permission in each new session. we should allow the extension access to the printer without user intervention in public session. Any way to bypass this requirement?

Adding Brian (forgot in last comment)

Brian -- Pls refer to comment #12.

Adding Toni. He may have some inputs on PrintProvider. There may be some privacy implications with automatically allowing an extension to access printers. For the extensions that were explicitly whitelisted for PS, it should not be an issue I think.

Question for Graham - how big of an issue this is in the field? 

When it comes to USB printers supported by printer provider extension, there are two sets of printers surfaced in the print preview UI:

1. printers whose USB device the extension is allowed to access using USB API 

2. printers that satisfy the extension's "usb_printers" filter (which is in the extension's manifest), but whose USB device the extension is not allowed to access/enumerate using USB API.

The ones that seem to cause problems here are the print destination from set 2. - for those, we add provisional print destinations to the print preview UI - when the user selects one of those (and accepts the permission UI) the extension is granted access to the associated USB device, and then queried for the printer information.

One way to bypass the behaviour described here would be to automatically grant the print extension access to USB devices (for chrome.usb API) that match the filter in the extension's manifest under the "usb_printers" key (provisional destination will not be added for USB printers accessible by the extension using usb API), and maybe the default printer regex. 

Option 2 would be to update default destination selection to support provisional destinations. Though, we'd have to surface the same permission UI before fetching printer description from the extension (otherwise the extension will not be able to communicate with the printer), which is afaik needed to properly display printer capabilities for the selected printer. I think the tricky part here would be figuring out how to show the permission UI early enough.

For force-installed print extensions, why would we not just skip the permission request entirely (auto grant permissions)? What's the downside to that?

@isandrk, c#16 also makes sense IMO - what are your thoughts to skipping permission requests for force-installed extensions?

c#14, although the customers has explained it is not hugely impacting, it is a feature apparently offered and would enhance the customer experience for printing from within a public session.

@gbirtchnell, completely agree with #16.

@tbarzic: What do you think about this?

I think that sounds like a reasonable approach.

Is the plan to grant the permission when a printer is selected in the print UI (both in case when the printer is selected by a user, and when the printer is a printer that matches default printer policy)?

@tbarzic, that should work for me.

Sounds like we have a plan of record here - sending over to Raj to prioritize this against the other PS/kiosk work on our plate.

Any update on this?

Hi,

Please can you provide an update on this please.

Hi Steve, we will get back to you on this one. As this is a Pri-3 issue, we are not actively looking into it at this time. We are planning to address this in Q3. Feel free to ping me directly.

This permission issue has been causing our organization headaches for the past year. I've been patiently waiting, checking in on this page every couple months. Is there a way for me to force allow this permission on my end, or do we perhaps have an ETA on when this might be resolved? 

I believe this should be addressed with our upcoming changes in M70 - Ivan, can you confirm that this print provider can be installed in public sessions with your latest changes?

@atwilson: The printing extension can be installed as it's whitelisted, but the problem is the permission prompt which is shown in every PS session (since they are ephemeral by design) - this permission prompt is different from what we've done back in the days, it's in the printing code stack.  The changes we're making in M70 don't affect this problem as this behaviour is not specific to PS.

> yes the behaviour is the same with user signed-in this impacts PS greater as the permission acceptance (seen in Permission_Screenshot...png) is necessary each time a PS is entered.

> flow is identical for both the user mode and in public session. However, not a great experience in PS mode since it needs to be done in every new session.

OK, I think we should probably skip the permission prompt if a printer extension is force-installed. Understood that M70 changes don't impact this, but let's keep this on your plate as something to tackle in the future (not just for public sessions).

Roger!

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

This is still an issue that haunts me. All I want is to be able to set a default USB printer in the Chrome Management Console. The printer is recognized when "HP Print for Chrome" is force installed, but it ignores the Default Printer, matched by name option if it uses HP Print for Chrome to register with the OS. I assume because the permission pop-up, as seen in the third screenshot on above. I just tested, and it still looks the same as when this bug was first logged. 

isandrk@ is currently out for the holidays. I'll follow up in the new year.