Open
Bug 1917688
Opened 1 year ago
Updated 1 year ago
[meta] Support client-side printing in Google Slides
Categories
(Core :: Printing: Setup, enhancement)
Core
Printing: Setup
Tracking
()
NEW
People
(Reporter: dholbert, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: meta)
[Spinning this off for followup work from bug 1521655, for one part of gsuite / Google Workspace where our printing behavior hasn't yet changed]
STR:
- Visit some Google Slides presentation, e.g. this one I just created:
https://docs.google.com/presentation/d/1kVjcMffbgARYzPLEpcdiK7CqrjKIdtNZF0nSRGUD5H4/edit - Try to print, using Ctrl+P (or Cmd+P on macOS), or using the in-page "File" menu, "Print" menu-item.
ACTUAL RESULTS:
For now, Google Slides handles this operation by generating a PDF and opening it in a new tab (which can then be printed if the user does Ctrl+P again).
EXPECTED RESULTS:
Browser's own native print dialog should appear (this is what happens in Chrome).
We should check in with the Google Workspace folks to see what (if any) features/bugs they might be blocked on from us to get this enabled.
| Reporter | ||
Updated•1 year ago
|
Type: defect → enhancement
| Reporter | ||
Comment 1•1 year ago
|
||
I discussed this a bit with a contact from Google over email. Summing that up, the situation right now is as follows:
- Google Slides client-side printing works in Chrome by generating a server-side PDF, and then loading that PDF in a hidden iframe (as a blob URI), and then invoking
window.print()on that iframe's window object from the outer document when the iframe is loaded. - Google folks observed that they don't have visibility into PDFs-loaded-in-iframes (see bug 1376151 comment 2 for more on this); it's cross-origin.
- However, Google folks should still be able to observe the load event and fire window.print when that happens, as of bug 1618553.
So I think this should be workable.
You need to log in
before you can comment on or make changes to this bug.
Description
•