1900073 - Images don't get filters applied in Google Docs (using native gsuite printing)

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Be using a Google account that's opted in to the "native" print flow (which requires manual action from some Google folks for now), or using UA spoofing to pretend you're Chrome.
2. Load this doc:
   https://docs.google.com/document/d/1sKpkspPHBjeCVMrjqkNZoi6WSShu9jO2pSDsJhtHnds/edit
3. Ctrl+P
   (Hopefully this triggers a print-preview popup. If it doesn't, go back to step 1.)
4. Click through Firefox's print UI to choose the "Save to PDF" print target (or any color printer).
5. Look at the print-preview rendering. If you like, proceed and save-as-PDF.

ACTUAL RESULTS:
All the images look the same; the filters don't show up on the images, in print-preview and print output (to PDF).

EXPECTED RESULTS.
The images should have the filters applied.

Note: the filters here come from Google Docs' "Image Options" button that appears at the top when you have an image selected and provides various methods of filtering/recoloring the image.

Comment 1

[Daniel Holbert [:dholbert]]

The Google folks who discovered this suspect that CanvasRenderingContext2d:filter is not being correctly honored, when rendering images to the mozPrintCallback-provided rendering context.

Comment 2

[Jonathan Watt [:jwatt]]

Attachment: Extracted testcase with six SVG filter, and one CSS filtered icon for comparison at center bottom

Comment 3

[Jonathan Watt [:jwatt]]

Even just in an HTML document (no printing required), these SVG filters are not applying to <canvas>. (The CSS filter applies fine.)

Comment 4

[Jonathan Watt [:jwatt]]

Attachment: Simplified testcase using feBlur - this works fine

So this simple SVG feBlur testcase works. So I'm guessing that we're handling the Google Docs SVG filters differently to Chrome (different coordinate system handling, or something?).

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #3)

Even just in an HTML document (no printing required), these SVG filters are not applying to <canvas>. (The CSS filter applies fine.)

This one actually doesn't work in Chrome, either; Chrome matches us on this testcase. (None of the Firefox icons look filtered in Chrome, except for the reference one at the bottom center.)

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase demonstrating filters working on regular canvas

per matrix chat with jwatt, his earlier attachment 9405124 [details] had a typo in the ID references. I've fixed that here, and it works as-expected (the image draws filtered to the canvas in Firefox and Chrome [and it shows up in print-preview as well]).

Here's the fixed testcase for reference.

Something must be failing in a mozPrintCallback specific way or further down the line here.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: testcase demonstrating filters working in mozPrintCalback

Here's a simple mozPrintCallback testcase using SVG filters applied to an image that's drawn using mozPrintCallback (using an SVG filter taken from jwatt's testcase, which I believe is taken from the Google Docs testcase).

This works properly; the filter shows up in print-preview (and print) just fine.

So: we don't yet have a reduced testcase to replicate the thing that's not working with Google Docs here, but the good news is that it looks like the-thing-they're-trying-to-do does work in some cases at least.

Comment 8

[Daniel Holbert [:dholbert]]

Here's a simpler Google Docs testcase, with just a single image, with just an opacity-reducing filter on it (which doesn't work in print-preview/print, per this bug):
https://docs.google.com/document/d/1OjK4sJ-tVLwZmX-mqROpzGn_fx-OzZekQncWe-QZdeI/edit

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: just like testcase 2, but now with the filter being display:none

jwatt figured out that the SVG filters in Google Docs are inside of a display:none wrapper element, and that's what prevents them from working here.

Here's a variant of testcase 2 where I made that change. (I also added a button where you can just directly draw to the canvas on-screen instead of needing to bother with printing.)

This version does trigger the issue. You can use Chrome as a reference case by just clicking the button there (though obviously mozPrintCallback doesn't exist there, so the canvas won't automagically populate on print.)

Firefox doesn't honor the filter here; Chrome does.

Comment 10

[Jonathan Watt [:jwatt]]

Yeah, more specifically, the file 403442919-KixCss_ltr.css contains this:

@media print {
  #docs-editor-container.docs-ui-unprintable, .docs-ui-unprintable {
    display: none !important;
  }
}

And the SVG filters that are being referenced are contained within the following child of the body element:

<div id="docs-editor-container" aria-hidden="true" class="docs-ui-unprintable">

So all the SVG filters are contained within a display:none tree, and we're running into our longstanding issue, bug 376027, where SVG effects that don't have layout frames (that are display:none) can't be referenced by other content.

Hopefully the Gsuite team are ammeanable to moving the SVG content outside of the display:none elements, because we probably won't have a fix for bug 376027 in the timescale that we're hoping for native Gsuite printing to be released. Hopefully that shouldn't be a big ask(?) since putting all the SVG content in an SVG <defs> element and giving the <svg> element a width/height of zero and taking it out of flow with position:absolute should be just as effective as making it display:none.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #10)

Hopefully the Gsuite team are ammeanable to moving the SVG content outside of the display:none elements, because we probably won't have a fix for bug 376027 in the timescale that we're hoping for native Gsuite printing to be released.

Update on this: the Google Docs folks were able to apply a version of this workaround, so I think we can consider this bug WFM, with bug 376027 remaining open to track the underlying Gecko bug on our side here.