1836315 - Google drawings fails to render certain parts of diagram at docs.google.com

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[Bobby Holley (:bholley)]

Testcase: https://docs.google.com/drawings/d/1uqo6SYi8t05nQa9jCfzlRBBbANJsvcr6lfOPQVfcIcU/edit

Firefox fails to render some parts. Will attach screenshots.

Comment 1

[Bobby Holley (:bholley)]

Attachment: Screenshot-Firefox.png

Comment 2

[Bobby Holley (:bholley)]

Attachment: Screenshot-Chrome.png

Comment 3

[Raul Bucata]

Verified this issue and I was able to reproduce it on Firefox versions 122, 123 and 124. The values are not rendered.

Tested with:

Browser / Version: Firefox Release 122.0(64-bit)/ Firefox Nightly 124.0a1 (2024-01-27) (64-bit) , Firefox Beta 123.0b3 (64-bit
Operating System: Windows 10 PRO x64

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (partially reduced)

Here's a partly-reduced testcase.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 in Firefox (top) vs Chrome (bottom), scrolled down-and-to-the-right slightly, showing the missing content as red boxes

Comment 6

[Daniel Holbert [:dholbert]]

ni=me to reduce/poke further

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (more reduced)

Here's a more-reduced testcase. On my system, Firefox Nightly cuts off the text here in the middle of the lowercase alphabet, clipping the m character.

Given the giant coordinates/scale-factors involved here (particularly the x-coordinate of the transform matrix), I suspect the issue here is just that we're running up against the limits of our numeric representation for some part of the rendering here.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 3

I simplified the nested transforms a bit in this version.

This seems to specifically be an issue when I "stack" transforms that partly cancel each other out, in nested g elements. This end up making us clip too aggressively.

This affects text as well as other elements, e.g. rect as shown here.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 4

Comment 10

[Daniel Holbert [:dholbert]]

Likely related to bug 1752828 which is a dupe of bug 1544413.

Comment 11

[Daniel Holbert [:dholbert]]

Removing webcompat:needs-diagnosis since this is essentially already diagnosed as a version of bug 1544413.

Comment 12

[Thomas Wisniewski [:twisniewski]]

There doesn't seem to be any kind of webcompat intervention we can ship here, so I'm removing needs-sitepatch.

Comment 13

[Glenn Watson [:gw]]

I did some investigation of the test case in comment 9. Confirmed that the visible_rect that gets passed through to the WR blob rendering interfaces is incorrect, resulting in the blob being clipped on the right.

Tracing back in a debugger, the incorrect values used to derive visible_rect come from information stored on the wrapping frame. Both the rects at [1] and [2] have the incorrect value.

From the layout debugger, the frame tree dump of the (slightly adjusted locally) test case is shown below. The value of the width in the SVGOuterFrame looks correct (72960 / 60 = 1216 pixels). However the values in the SVGG elements appear to have extremely large values for ink-overflow rects etc.

I suspect we have an accuracy conversion issue somewhere around there either in the layout / display-list code / webrender display-list conversion code. Emilio, Tim, does that sound likely to be causing the problem? Have we run in to similar accuracy issues here / any ideas what we could do to handle this better?

Frame tree in app units:
docshell=0x7fe13cd24590 
Viewport(-1)@7fe11d845020 [view=7fe11d816d60] (x=0, y=0, w=61440, h=40680)[cs=7fe11d836c08][:-moz-viewport] <
  ScrollContainer(html)(-1)@7fe11d845190 parent=7fe11d845020 (x=0, y=0, w=61440, h=40680) [content=7fe11d204080][cs=7fe11d836308][:-moz-viewport-scroll] <
    ScrollbarFrame(scrollbar)(-1)@7fe11d845428 parent=7fe11d845190 next=7fe11d845698 (x=0, y=39960, w=61440, h=720) [content=7fe11d204380][cs=7fe11d8f3b08] <
      SliderFrame(slider)(-1)@7fe11d845528 parent=7fe11d845428 (x=0, y=0, w=61440, h=720) [content=7fe11d204500][cs=7fe11d8f2808] <
        Frame(thumb)(0)@7fe11d845620 parent=7fe11d845528 (x=0, y=0, w=49380, h=720) [content=7fe11d2060c0][cs=7fe11d8f3c08]
      >
    >
    ScrollbarFrame(scrollbar)(-1)@7fe11d845698 parent=7fe11d845190 next=7fe11d845908 (x=0, y=0, w=0, h=0) [content=7fe11d204400][cs=7fe11d8f3508] <
      SliderFrame(slider)(-1)@7fe11d845798 parent=7fe11d845698 (x=0, y=0, w=0, h=0) [content=7fe11d204580][cs=7fe11d8f3d08] <
        Frame(thumb)(0)@7fe11d845890 parent=7fe11d845798 (x=0, y=0, w=0, h=2400) [content=7fe11d206160][cs=7fe11d8f2408]
      >
    >
    Frame(scrollcorner)(-1)@7fe11d845908 parent=7fe11d845190 next=7fe11d8450d0 (x=61440, y=40680, w=0, h=0) [content=7fe11d204480][cs=7fe11d837508]
    Canvas(html)(-1)@7fe11d8450d0 parent=7fe11d845190 (x=0, y=0, w=61440, h=40680) ink-overflow=(x=0, y=0, w=73440, h=40680) scr-overflow=(x=0, y=0, w=73440, h=40680) [content=7fe11d204080][cs=7fe11d837d08][:-moz-scrolled-canvas] <
      Block(html)(-1)@7fe11d845980 parent=7fe11d8450d0 (x=0, y=0, w=61440, h=26205) ink-overflow=(x=0, y=0, w=73440, h=26205) scr-overflow=(x=0, y=0, w=73440, h=26205) [content=7fe11d204080][displayport][cs=7fe11d837008] <
        line@7fe11d845b00 count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none bm=480 (x=480, y=480, w=60480, h=25245) ink-overflow=(x=480, y=480, w=72960, h=25245) scr-overflow=(x=480, y=480, w=72960, h=25245) <
          Block(body)(2)@7fe11d845a40 parent=7fe11d845980 (x=480, y=480, w=60480, h=25245) ink-overflow=(x=0, y=0, w=72960, h=25245) scr-overflow=(x=0, y=0, w=72960, h=25245) [content=7fe11d204300][cs=7fe11d836708] <
            line@7fe11d845ec0 count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,no-break,clear-before:none,clear-after:none (x=0, y=0, w=72960, h=25245) <
              SVGOuterSVG(svg)(1)@7fe11d845b50 parent=7fe11d845a40 (x=0, y=0, w=72960, h=24960) [content=7fe11d208030][cs=7fe11d85f408] <
                SVGOuterSVGAnonChild(svg)(1)@7fe11d845c18 parent=7fe11d845b50 (x=0, y=0, w=0, h=0) ink-overflow=(x=0, y=0, w=53688, h=24960) scr-overflow=(x=0, y=0, w=53688, h=24960) transformed [content=7fe11d208030][cs=7fe11d85ff08][:-moz-svg-outer-svg-anon-child] <
                  SVGG(g)(1)@7fe11d845cd0 parent=7fe11d845c18 (x=0, y=0, w=0, h=0) ink-overflow=(x=0, y=0, w=53688, h=24960) scr-overflow=(x=0, y=0, w=53688, h=24960) pre-transform-ink-overflow=(x=0, y=0, w=536870912, h=249600000) pre-transform-scr-overflow=(x=0, y=0, w=536870912, h=249600000) transformed [content=7fe11d209040][cs=7fe11d85f208] <
                    SVGG(g)(1)@7fe11d845d88 parent=7fe11d845cd0 (x=0, y=0, w=0, h=0) ink-overflow=(x=0, y=0, w=536870912, h=249600000) scr-overflow=(x=0, y=0, w=536870912, h=249600000) pre-transform-ink-overflow=(x=0, y=0, w=182400, h=62400) pre-transform-scr-overflow=(x=0, y=0, w=182400, h=62400) transformed [content=7fe11d209120][cs=7fe11d85fa08] <
                      SVGGeometry(rect)(1)@7fe11d845e40 parent=7fe11d845d88 (x=0, y=0, w=182400, h=62400) [content=7fe11d20a080][cs=7fe11d860108]
                    >
                  >
                >
              >
            >
          >
        >
      >
    >
  >
>

[1] https://searchfox.org/firefox-main/source/gfx/layers/wr/WebRenderCommandBuilder.cpp#1644
[2] https://searchfox.org/firefox-main/source/gfx/layers/wr/WebRenderCommandBuilder.cpp#1660

Comment 14

[Timothy Nikkel (:tnikkel)]

SVGG(g)(1)@7fe11d845d88 ink-overflow=(x=0, y=0, w=536870912, h=249600000) 
  SVGGeometry(rect)(1)@7fe11d845e40  (x=0, y=0, w=182400, h=62400)

The SVGG(g) has the 4000 scale transform, so we try to store 182400*4000 = 729600000, we hit here

https://searchfox.org/firefox-main/rev/ff87356d65bc2e9e7349ac3a24276696434f27fc/layout/base/nsLayoutUtils.cpp#1855

where we limit rects to be inside (-nscoord_max/2, nscoord_max/2), and nscoord_max is 2^30 = 1 billion. So that's why we chop off part of the frame. We could store the proper size in this testcase if we are more careful about the intermediate computations, but then we could just 2x this testcase and fail again.

Not sure what to do, this is pretty deeply baked in to layout.

Comment 15

[Timothy Nikkel (:tnikkel)]

Although a different underlying issue, bug 1978729 is similar in that it also comes from a google property, is svg, and scales down a large inner thing.

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Thanks for digging Tim... I think if we can get an improvement here it'd be nice still tho...

Comment 17

[Glenn Watson [:gw]]

So it looks like we can make a fix for this specific issue (comment 14) in layout code, due to the numbers involved, but that the fundamental problem will remain if the numbers are a bit bigger. Doesn't sound like we have any good ideas / solutions for that. dholbert, any thoughts or opinions - perhaps we get the fix for this issue in, close this and revisit if it pops up again on other real world content?

Comment 18

[Timothy Nikkel (:tnikkel)]

I'll do the smaller fix I mentioned in comment 14 in another bug since it doesn't fix the issue here, just bumps up the threshold to hit it.

Comment 19

[Daniel Holbert [:dholbert]]

Thanks for investigating, Glenn and tnikkel!

(In reply to Timothy Nikkel (:tnikkel) from comment #14)

where we limit rects to be inside (-nscoord_max/2, nscoord_max/2)

Hmm, that's unfortunate (given that the rect in this case has an arbitrary scale factor, which happens to ultimately be irrelevant since there's a scale factor on an ancestor that almost entirely counteracts it).

Comparing other engines here:

• Chrome seems to be able to handle arbitrarily large scale factors here; maybe they combine the stack of transforms before forcing themselves to establish a clipping rect, or something? They can handle a version of testcase 4 with these much-more-substantial transforms:

  <g transform="scale(0.000000000000000000000000001)">
    <g transform="scale(400000000000000000000000000)">

• Safari can't handle transforms that large^, but they can handle transforms that are 100x more extreme than we can. They handle this just fine in a variant of testcase 4: [EDIT: hmm, this worked in a standalone testcase, but Safari shows some missing content for this part of testcase 5/6; so maybe they're not quite so much more robust than we are]

  <g transform="scale(0.000001)">
    <g transform="scale(400000)">

...but that's about as far as they can go. If I push it a bit further with a 2x downscale/upscale then they don't render the blue rect at all:

  <g transform="scale(0.0000005)">
    <g transform="scale(800000)">

Comment 20

[Daniel Holbert [:dholbert]]

Attachment: testcase 5: using progressively more extreme scales to probe the boundaries of different engines

Comment 21

[Daniel Holbert [:dholbert]]

Attachment: testcase 6 (like 5 but with bigger SVG and no viewBox downscaling

Comment 22

[Daniel Holbert [:dholbert]]

Having said all that, I tend to think we can consider this affects:few rather than affects:some.

Looking a bit more at the details on the original testcase to see why it might be tripping these extreme values, it looks like the canvas here is set up to be 500 inches by 500 inches (visible in the Google Docs File|PageSetup which you can access in an editable copy of the read-only drawing in testcase 0, which you can create using File|Make a Copy on that read-only drawing).

The standard page-sizes that Google Drawings offers are all <= 10in wide and tall. Google does also offer Custom page setup, which lets you use arbitrarily large values like 500in x 500in as in this testcase. I suspect we can safely assume that not many users are manually adjusting their Google Drawing to get a with page size that large, though; hence I'm reclassifying as "affects:few".

Also: even though Chrome supports impressively large upscale/downscale pairings in my testcase in comment 19, they do top out on Google Drawings and stop drawing the text, in a similar way that we do, if I scale up this drawing by only about 50x, to 25000 x 25000 inches.

Comment 23

[Timothy Nikkel (:tnikkel)]

Bug 1994934 completes my needinfo so clearing.