Open Bug 1710764 Opened 3 years ago Updated 3 months ago

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

Categories

(Core :: Graphics: WebRender, defect)

Firefox 90
defect

Tracking

()

People

(Reporter: mail, Unassigned, NeedInfo)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression)

Attachments

(5 files, 3 obsolete files)

Attached video 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.

Attached video Alternate demonstration

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

Summary: rotateX scales instead of rotating on hover when transition is set → `rotateX()` scales instead of rotating on hover when `transition` is set
Component: Untriaged → CSS Transitions and Animations
Product: Firefox → Core

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?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(hikezoe.birchill)
Attached file Improved demonstration HTML (obsolete) —

This is a slightly more pleasant demonstration page.

I can’t reproduce this problem in Firefox 88.

Attached file Further improved demonstration page (obsolete) —

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

Attachment #9221604 - Attachment is obsolete: true
Has Regression Range: --- → yes

Thanks Alice! <3

Component: CSS Transitions and Animations → Graphics: WebRender
Flags: needinfo?(hikezoe.birchill) → needinfo?(aosmond)

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.

Attached file Reverted demo (obsolete) —

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

Sorry.

Attachment #9221609 - Attachment is obsolete: true

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

Attachment #9221908 - Attachment is obsolete: true
Severity: -- → S3
Flags: needinfo?(dmalyshau)
No longer blocks: gfx-triage
Summary: `rotateX()` scales instead of rotating on hover when `transition` is set → CSS transform function rotateX() scales instead of rotating on hover when CSS property transition is set
See Also: → 1723427

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?

Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(dmalyshau)
Flags: needinfo?(aosmond)

This bug is still present as of Mozilla Firefox 110.0.1

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 ?

Flags: needinfo?(tnikkel)
Flags: needinfo?(nical.bugzilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: