789122 - Google Presentations are Clipped (zoom-related)

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Alon Zakai (:azakai)]

Go to https://docs.google.com/presentation/pub?id=1pnBo1CB6VQRZ9grQVSkhapbF3Ppug7-Zw_1kkzH1QOk&start=false&loop=false&delayms=3000 , then in 16+, the view is clipped - some of the contents on the right and bottom are missing. This is not broken in 15.

The issue seems to have something to do with zoom. Doing control-plus expands the area drawn, so if you do control-plus enough it is no longer clipped. When zooming, the text is not zoomed in or out, just the clipped area is changed.

Comment 1

[Alon Zakai (:azakai)]

This is a regression that begins in 16.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Alon, are you willing to find a regression range?

Comment 3

[Alon Zakai (:azakai)]

Sure, I'm on it.

Comment 4

[Alon Zakai (:azakai)]

Bisected to bug 773450.

When I began bisection I was puzzled by the fact that while 16, 17 and 18 are affected, when m-c branched for 16 it was still unbroken, so I ended up bisecting the nightly changesets of 17. Turns out the regression landed during 17, but was uplifted into 16.

Comment 5

[Jonathan Watt [:jwatt]]

Attachment: reduced testcase

I kinda think that what we do now is correct.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Jonathan Watt [:jwatt] from comment #5)
> Created attachment 659218 [details]
> reduced testcase
> 
> I kinda think that what we do now is correct.

So is this something that still needs tracking then?

Comment 7

[Alon Zakai (:azakai)]

From the user's perspective this is a regression, it used to work in Firefox and it does work in Chrome.

jwatt, is this a case of a website relying on buggy behavior that we have since fixed? If so we should reach out to them.

Comment 8

[Jonathan Watt [:jwatt]]

The issue is that they're relying on clipPath clipping on an outer-<svg>. How that works isn't officially spec'ed anywhere, since the coordinate space that the clip path is in is defined in terms of the clipPathUnits attribute, and that attribute is specified in terms of coordinate spaces that only exist for descendants of an outer-<svg>[1]. outer-<svg> elements themselves are laid out as a CSS box, not using SVG coordinate system layout.

Our old behavior for clipPath clipping of outer-<svg> was not by design either, didn't really make much sense, and would be hard to use. And it conflicts with how we apply clipPath clipping to other elements that are laid out using the CSS box model.

Another thing is that using a clipPath is a really nonsensical way of trying to achieve what the Google Presentation code is trying to achieve. The code is trying to clip to the viewBox rect of the outer-<svg> rather than to the SVG viewport it establishes; but to do that all they would need to do is wrap all the children of the outer-<svg> in another <svg> without giving it any attributes. That extra wrapper <svg> would default to a width/height of 100%, giving the exact clipping they're trying to achieve in a much simpler way. It would be great if we could get them to change to doing that.

1) http://www.w3.org/TR/SVG11/masking.html#ClipPathElement

Comment 9

[Boris Zbarsky [:bzbarsky]]

I sent some mail; we'll see what the Google folks say.

This is a problem on Beta, yes?  Depending on the timeframe on the Google side, is there anything that's safe for Beta we can do on our side?

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking for Beta until we hear back re: comment #9 to make a final decision here. Should this move to tech evangelism?

Comment 12

[Alex Keybl [:akeybl]]

We've heard back from Google - a fix should be pushed in 2/3 weeks. Given that, no need to track for release of FF16 and up.

Comment 13

[Jonathan Watt [:jwatt]]

Given that we've seen no other significant breakage on the Web, I'm going to close this as WONTFIX as per comment 5 and comment 8.

Comment 14

[Jonathan Watt [:jwatt]]

INVALID, rather.