When content is moved out of screen with -moz-transform, -moz-element fails

NEW
Unassigned

Status

()

Core
Layout
6 years ago
6 years ago

People

(Reporter: timdream, Unassigned)

Tracking

Trunk
Other
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

In Gaia, when attempt to use -moz-transform to move away iframes that is inactive, Task manager failed to show the screenshot of the iframe.

https://github.com/andreasgal/gaia/pull/579
This one is an interesting call.  The question boils down to where in the rendering pipeline -moz-element is ordered wrt transforms.  In this case we want to use the original element as a source for both a "transform effect" *and* a "-moz-element effect".  Rendering the *transformed* frame in -moz-element is counterintuitive, because the transform moves the element outside the bounds of the -moz-element target.

But I could certainly see cases in which *not* applying transforms to -moz-element content would be counterintuitive, like if you want to show a 3d effect inside -moz-element.  I guess this camp is winning in gecko.  Just want to be sure that that's intentional.
I don't think this was ever explicitly considered. I think rendering the pre-transform contents makes much more sense. Someone needs to fix this. It's not that hard, but we may need to add flags to nsDisplayList::BuildDisplayListForStackingContext and nsLayoutUtils::PaintFrame to ignore transforms.
If the source element had only a scale applied, wouldn't we want to take the transform into account when drawing it for its -moz-element consumer?

If so then I think the problem is that we are not taking into account transforms when determining the source rect to use for the -moz-element. If not, then comment 2. :)
(In reply to Timothy Nikkel (:tn) from comment #3)
> If the source element had only a scale applied, wouldn't we want to take the
> transform into account when drawing it for its -moz-element consumer?

I could go either way, but for the sake of simplicity, how about "no"? :-)
I'm not suggesting that we should special case scales or anything, I'm using that as an example to argue that we do want to take transform into account and the bug is that we use the wrong source rect for the moz-element.
I'm not sure exactly what you're proposing for "taking transforms into account when determining the source rect".
Created attachment 601825 [details]
testcase

If we scale an element by 2 and use it as a source for moz-element then we draw the top left quarter of the element (half the width and half the height) for the moz-element consumer. In this case taking transforms into account when determining the source rect would mean making the source rect twice as big. In the moz-element consumer the source image would be twice as big as currently.

If we ignored transforms we'd still draw the whole element but it would not be drawn twice as big as the untransformed version.
What if the transform is a skew or rotation? How would you determine the source rect then?
Transform the original source rect by the transform? You'll get empty parts where the frame isn't.

But I do see your point that this kind of falls apart when you consider skews or rotations.

So for reasonable cases, ie only translate and scale, the only difference between your approach and my idea is the default size of what gets painted for the moz-element consumer.
(In reply to Timothy Nikkel (:tn) from comment #9)
> Transform the original source rect by the transform? You'll get empty parts
> where the frame isn't.

Transform the border-rect and take its bounding-box? That actually makes sense. Rotations would actually be useful as well as scales.

ISTR a thread on public-fx or www-style about this recently... needs to be specced.
You need to log in before you can comment on or make changes to this bug.