1710764 - CSS transform function rotateX() scales instead of rotating on hover when CSS property transition is set

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Anselm Schüler]

Attachment: 2021-05-12_02-30-36.mkv

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

→ Write an HTML file containing an image to be transformed
→ Write a style for that image to be transformed with rotateX when hovered
→ Write a nonzero transition property into the style of the image

For instance:

<style>
    img {
        transition: 511ms;
    }

    img:hover {
        transform: rotateX(27deg);
    }
</style>
<img src="https://interactive-examples.mdn.mozilla.net/media/examples/firefox-logo.svg">

Actual results:

While or after hovering, the image sometimes switched to merely being scaled down by an amount such that the height of the displayed image matched the intended height after the rotation

Expected results:

The image should’ve been rotated along the X axis and displayed squashed or in perspective.

Comment 1

[Anselm Schüler]

Attachment: Demonstration with perspective

Comment 2

[Anselm Schüler]

Attachment: Alternate demonstration

Comment 3

[Anselm Schüler]

Note: This does not occur when an additional perspective() transformation is applied after the rotateX().

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Reporter's testcase

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Firefox 68 worked fine. Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=598d441e4ebaa93ab098d266035a396057c82129&tochange=6cbf1430a66ef5aa5f066ed77677f47ea44fc0e1. I don't see any immediately-suspicious changes there though. Maybe bug 1581113?

Comment 6

[Anselm Schüler]

Attachment: Improved demonstration HTML

This is a slightly more pleasant demonstration page.

Comment 7

[Anselm Schüler]

I can’t reproduce this problem in Firefox 88.

Comment 8

[Anselm Schüler]

Attachment: Further improved demonstration page

This page also demonstrates the effect that perspective has on the effect.

Comment 9

[Alice0775 White]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

Firefox 68 worked fine. Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=598d441e4ebaa93ab098d266035a396057c82129&tochange=6cbf1430a66ef5aa5f066ed77677f47ea44fc0e1. I don't see any immediately-suspicious changes there though. Maybe bug 1581113?

Regression window(Enabled WebRender):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a8b8823a6b72114f4150fbcd2ab0728b833b6a04&tochange=ef5f9e04f04b648bdee5517bcbf71895acf2314e

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Thanks Alice! <3

Comment 11

[Anselm Schüler]

I do not know if this is still relevant, but I can reproduce this on FF 88.0.1 on Windows, but not on Linux.

Comment 12

[Anselm Schüler]

Attachment: Reverted demo

Actually, that one didn’t actually work. Reverting back to this version.

Sorry.

Comment 13

[Anselm Schüler]

Attachment: Fixed reverted demo page

Sorry that I’m spending so much effort on this demo page. That was a defective version just now.

Comment 14

[Dzmitry Malyshau [:kvark]]

I took 2 WR captures - with and without rotation. All the way from WR to the screen is done correctly, as expected. But the source image is different - smaller.

Some gists from the capture.
scene:

     Image((
      common: (
       clip_rect: (
        min: (0, 0),
        max: (720, 743.125),
       ),
       clip_id: Clip(0, (1, 11)),
       spatial_id: (5, (1, 11)),
       flags: (
        bits: 1,
       ),
      ),
      bounds: (
       min: (0, 0),
       max: (720, 743.125),
      ),
      image_key: ((7), 7),
      image_rendering: Auto,
      alpha_type: PremultipliedAlpha,
      color: (
       r: 1,
       g: 1,
       b: 1,
       a: 1,
      ),
     )),// [22]

plain-resources:

  ((7), 7): (
   data: "externals/65",
   descriptor: (
    format: BGRA8,
    size: (720, 609),
    stride: Some(2880),
    offset: 0,
    flags: (
     bits: 0,
    ),
   ),
   tiling: None,
   generation: (0),
  ),

external_resources:

  (
   short_path: "externals/65",
   descriptor: (
    format: BGRA8,
    size: (720, 609),
    stride: Some(2880),
    offset: 0,
    flags: (
     bits: 0,
    ),
   ),
   external: (
    id: (51539607561),
    channel_index: 0,
    image_type: Buffer,
   ),
  ),// [64]

TL;DR: this image is a blob, rasterized by gecko every frame. This shouldn't be happening.
Nicolas, would this be related to the fact it's an SVG image? Could some Gecko logic decide to apply transformations to SVG before turning it into pixels?

Comment 15

[Anselm Schüler]

This bug is still present as of Mozilla Firefox 110.0.1

Comment 16

[Mayank Bansal]

This appears to be fixed in the latest Nightly.
Regression range:
Bug 1804872. Handle cases where a scale animation is being run on the compositor when choosing the size to get a decoded image at. r=aosmond

The transform on the stacking context helper has the current scale, not the largest scale of the animation. The scale on the stack context helper holds this value thanks to the logic in ChooseScale.

Before webrender we would just look at the current matrix on the gfx context so it would have final size to draw at for the animation.

I have a fix that also fixes the blob recordings/image region case but it is a little more invasive so I want to land this first. The 3rd reftest will ensure that we can't turn on blob recording without fixing that case.

Differential Revision: https://phabricator.services.mozilla.com/D175627

@ :tnikkel - should this be marked as a dupe of bug 1804872 ?