1521655 - [meta] Support client-side printing in Google Docs and GSuite (Google Workspace)

Status: NEW

(Core :: Printing: Setup, enhancement, P1)

Description

[Karl Dubost💡 :karlcow]

This is a bug reported on webcompat.com.
See https://webcompat.com/issues/22225

The reporter tried to print a document by clicking the print icon.

On Firefox it brings (on macos) The PDF save menu for printing.
On Chrome it directly open the document to be printed.

On Firefox, if you select File -> Print, you get the equivalent menu than Chrome.

Comment 1

[Mark Banner (:standard8)]

Interestingly on Firefox there's a network request for the PDF, whereas Chrome doesn't do any network request when you hit their print button.

Firefox still attempts to print the right thing when you do File -> Print though.

This makes me think there's some sort of API or something that docs is using. I realise it was mentioned that the user agent was changed to Chrome, but I wouldn't be surprised if they're doing API detection rather than user agent detection.

Moving across to Toolkit -> Printing to hopefully get some more experienced eyes on this.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

I believe the only way for content to request a print job for a document is to call window.print() on the window hosting the document.

Since Docs is probably generating a PDF on the server side and sending it back to the client, my hypothesis is that there's probably a hidden <iframe> hosting that PDF, and some script might be trying to call iframe.contentWindow.print() on it. I'm not 100% certain that we allow this - looking at nsGlobalWindowOuter::PrintOuter (which is what iframe.contentWindow.print() would resolve to), I see this code that checks to see if we're in a window that has dialogs enabled, and I think hidden iframes fail that check because of this code here.

My guess is that Docs is falling back when iframe.contentWindow.print() fails, and offering up the save dialog instead.

I think I'm actually inclined to move this over to Core :: DOM, since (if my guesses here are right) I think this is more about that check in nsGlobalWindowOuter::PrintOuter for dialog capabilities.

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thanks Mike for the details.
Hi Neha, this looks like at your team's wheelhouse. Can you help with it? Thanks

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Google Docs doesn't even call window.print when using FF.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

...and the reason is probably that FF throws an exception.
http://mozilla.pettay.fi/moztests/1.html is a testcase.

Comment 6

[Adam Stevenson [:adamopenweb]]

Safari and Edge are also downloading the PDF. Chrome and Opera are getting the print menu.

Comment 7

[Adam Stevenson [:adamopenweb]]

Started a conversation with Google about this on our gsuite mailing list, CC'd :smaug.

Comment 8

[Brendan Dahl [:bdahl]]

Was there any conclusion on the mailing list?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

We're missing some css print features, especially @page size.

Comment 10

[Sean Voisen (:svoisen)]

We have pretty insightful info from Google now based on the mailing list conversation on how to improve things here. Triaging to P3 with an intent to get this on our backlog sooner than later.

Comment 11

[Karl Dubost💡 :karlcow]

Attachment: print-menu-command-P

• Command P brings the print menu on macos + firefox 83.0a1 (2020-10-05) (64-bit)

But when selecting the print icon of the document, after a little while it proposes to save or open the file as pdf.

So this is not solved. But an interesting thing is that if I masquerade the user agent to be Chrome, the normal print menu is invoked. The rendering of the page is not finishing but at least it is calling the right thing.

So it seems there is a bit of user agent sniffing involved. It would be good to figure out why on the other hand the rendering is not fully completed or it does a Preview of the file and it crashes the tab.

Comment 12

[Karl Dubost💡 :karlcow]

Sean,

is there a meta bug for printing issues

Comment 13

[Sean Voisen (:svoisen)]

(In reply to Karl Dubost💡 :karlcow from comment #12)

Sean,

is there a meta bug for printing issues

We are having ongoing meetings with Google about supporting this. Unfortunately, it's not a simple matter of masquerading the UA as mentioned. We need to support @page { size } amongst other things to get client-side print support in Gsuite. But, this is our next big printing project once the new print UI work wraps up.

We don't have a single metabug for all printing improvements (other than fragmentation bugs), but we have been using the [print2020] whiteboard tag for tracking higher-priority print items.

Comment 14

[Sean Voisen (:svoisen)]

Turning this into a meta bug to track all of the G Suite client-side printing work.