1014230 - XUL <image> with layer="true" and "transform: [whatever]" is not painted

Status: NEW

(Core :: Layout, defect)

Comment 1

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: Test case.7z

Hi Jared,

I have created a test case based on your summary but I could not reproduce the issue on latest Firefox (44.0.2) release and latest Nightly (47.0a1) build (see attachments). The image was correctly painted. I'm not sure if the test case includes everything that you described or maybe I did not completely understand this issue.  

Firefox: 47.0a1, Build ID: 20160215030213
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Firefox: 44.0.2, Build ID: 20160210153822
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0

Can you please look over the test case and tell me if it's right? Or please provide another test case so we could reproduce the issue.

Thanks,
Cosmin.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

This test case does not show the issue. This is an issue that is shown in the Firefox UI, not webpages.

To reproduce, use DOM Inspector and select the Downloads button <image> child.
Set [layer="true"] on the <xul:image>
Add a style attribute and set `transform: rotate(10deg);` as a style on the <image> element.

ER:
The download arrow should be rotated 10 degrees.

AR:
The download arrow disappears.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Thanks, Jared. I can reproduce with this XUL testcase. (You have to save it locally and add about:config pref "dom.allow_XUL_XBL_for_file = true" to view it.)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reference case 1

Here's the reference case, with layer="true" removed. This makes the image show up.

Comment 5

[Daniel Holbert [:dholbert]]

mozregression shows this goes back to this range in 2013:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=250bb14d76d4&tochange=99479edbee2a
...which includes bug 882384 -- and that's where we added support for layer="true" in the first place:
http://hg.mozilla.org/mozilla-central/rev/be686cc8419a#l2.32

So, looks like this has been a problem with |layer="true"| since it was added.

Comment 6

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Removing the testcase-wanted keyword since it was added in Comment 3 .

Comment 7

[Matt Woodrow (:mattwoodrow)]

Sorry about the slow reply.

Why do you want to use layer="true" here?

In general, trying to override the layerization heuristics isn't a good idea.

Content with an animated transform will already get a layer for the duration of the animation.

If the content is particularly slow to paint, then we can end up losing some frames at the start of the animation while we redraw that content in it's own layer. If that really is an issue (and it shouldn't be for something simple like an image), you can use will-change:transform to signal that you plan on animating the transfom in the future, and we should allocate it's own layer to begin with.

I'd much rather try eliminate our usage of the 'layer' attribute than fix bugs with it.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #7)
> Why do you want to use layer="true" here?
> [...]
> I'd much rather try eliminate our usage of the 'layer' attribute than fix
> bugs with it.

(I believe this question is for Jared, who filed this bug & presumably was intending to use this in UI somewhere.)

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #7)
> Sorry about the slow reply.
> 
> Why do you want to use layer="true" here?
> 
> In general, trying to override the layerization heuristics isn't a good idea.
> 
> Content with an animated transform will already get a layer for the duration
> of the animation.
> 
> If the content is particularly slow to paint, then we can end up losing some
> frames at the start of the animation while we redraw that content in it's
> own layer. If that really is an issue (and it shouldn't be for something
> simple like an image), you can use will-change:transform to signal that you
> plan on animating the transfom in the future, and we should allocate it's
> own layer to begin with.
> 
> I'd much rather try eliminate our usage of the 'layer' attribute than fix
> bugs with it.

Matt, this came up due to the conversation at https://bugzilla.mozilla.org/show_bug.cgi?id=759252#c36.