1280060 - Graphical glitches when hiding a transformed HTML element under Linux

Status: RESOLVED DUPLICATE of bug 1265605

(Core :: Graphics: Layers, defect)

Description

[Silvère Lestang]

Attachment: bug graphical glitches Firefox47.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160606113944

Steps to reproduce:

Got to https://jsfiddle.net/6fhc9gtt/1/ with Linux version of Firefox 47.
Hover the Lorem ipsum: a tooltip appear. Wait a little or modify the JavaScript code (I don't know why this is required) then hover the paragraph again.

The bug seems to appear when a div that have CSS transformation applied (I try both translate and rotate) is hidden by some JavaScript with opacity set to 0 or display: none.


Actual results:

Some graphical glitches appear. Some parts of the tooltip aren't properly clean when it get hidden.


Expected results:

No previous part of the tooltip should stay on screen.

I can reproduce this bug with FF 47 from tarball and Ubuntu package.
I can reproduce this bug with FF 48.0b1 from tarball.
I cannot reproduce this bug with FF 47 under Windows and FF 50a1 under Linux.

Comment 1

[Loic]

Does it happen with previous versions of Firefox?

Comment 2

[Silvère Lestang]

I try to reproduce the bug with Firefox 46 without any success.

I thing the bug appear in FF 47 because we have an webapp that we use every day at work with a view that have tooltip everywhere and we only see this bug for the first time this weekend. I did try to rollback to the previous version of our webapp and it didn't change anything.

Comment 3

[Loic]

FF47 is the 1st version with XRender disabled by default. Could you set back XRender to true and test (about:config > gfx.xrender.enabled=true, then restart FF).

Comment 4

[Alice0775 White]

I can reproduce the problem on Firefox47 and 48.0b1 with/without gfx.xrender.enabled.

But, I cannot on Aurora49.0a2, Bightly50.0a1

Comment 5

[Alice0775 White]

And I can also reproduce problem on 48.0b1 on windows10 with HWA off and e10s off.

Comment 6

[Alice0775 White]

Fixed window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8fa8077e9c5f8610cf55f084930b8650b3710b1f&tochange=246fdb220ef355bffd166aee2d53e8fbff5dfa56

Seems fixed by Bug 1258904

Comment 7

[Gérard Talbot]

(In reply to Silvère Lestang from comment #0)

> Steps to reproduce:
> 
> Got to https://jsfiddle.net/6fhc9gtt/1/ with Linux version of Firefox 47.
> Hover the Lorem ipsum: a tooltip appear. Wait a little or modify the
> JavaScript code (I don't know why this is required) 

Click "External Resources 1" link, then click "jquery-3.0.0.min.js". jsfiddle.net will, by default, embed the javascript jquery-3.0.0.min.js library which has a 86341 (!) bytes filesize. So, in my opinion, the wait is for letting the browser load and parse such big file... just to make your 10 (!) lines of javascript work. In my opinion, this (jquery-3.0.0.min.js) is pure non-sensical abuse of the user's system resources.

> then hover the paragraph
> again.
> 
> The bug seems to appear when a div that have CSS transformation applied (I
> try both translate and rotate) is hidden by some JavaScript with opacity set
> to 0 or display: none.
> 
> 
> Actual results:
> 
> Some graphical glitches appear. Some parts of the tooltip aren't properly
> clean when it get hidden.

I use Linux Kubuntu 14.04.04 LTS, KDE 4.13.3, Linux 3.13.0-88-generic x86_64 with Firefox 47 buildID=20160606114208 and I see the red "Tooltip" completely but erratically (because I have to have the mouse cursor move all the time; that is a requirement from your javascript). I have experienced the display problem you mentioned (residual painting of "Tooltip") twice so far. In my experience, this is related to the graphic card not being able to draw, repaint, refresh the div#content fast enough.

> Expected results:
> 
> No previous part of the tooltip should stay on screen.

Your script (are you the author of that script?) is somewhat strange, odd. You require a mousemove event (which requires a lot of CPU and videocard on top of everything else) in order to trigger a transform translate function. 
1-
What is your script suppose to do (expected results) if the mouse stops moving? 
2-
Why should a tooltip only be viewable or readable when the mouse is moving and not when the mouse cursor stopped?
3-
In my opinion, I would say you require a lot of user system resources (CPU, RAM, videocard) ... just to show a tooltip...  For starters, it's possible to create a DHTML tooltip using CSS only and with no javascript.

Comment 8

[Silvère Lestang]

I confirm that I can reproduce the bug with gfx.xrender.enabled=true on FF47.

Alice White, so the bug will be fix in FF49 but not 48?
Firefox 49 is scheduled to be release on the 2016-09-13, in 3 months. Is there any way that the bug get fixed sooner?

It's quite annoying for our use case as we trigger the bug very easily on our main page and the majority of our customers use Firefox.

Gérard, I write this jsfidlle to have a minimal use case to reproduce the bug and I try to do it the fastest way I can with my knowledge. It's obviously not optimize and it is far from being similar to the code that we have on our webapp (and jQuery is clearly overkill for just 2 selectors and 3 events). But for reproducing the bug, it works.

Comment 9

[Alice0775 White]

First, clould you test with [1]Aurora49.0a2 and [2]Nightly50.0a1?

[1] https://www.mozilla.org/en-US/firefox/developer/
[2] https://nightly.mozilla.org/

And also test with [3]Beta48.0b1

[3]https://www.mozilla.org/en-US/firefox/channel/

Comment 10

[Silvère Lestang]

I try:
49.0a2 (2016-06-13) => no bug
50.0a1              => crash at startup
50a1                => no bug
48.0b1              => bug

Comment 11

[Alice0775 White]

(In reply to Silvère Lestang from comment #8)

> Firefox 49 is scheduled to be release on the 2016-09-13, in 3 months. Is
> there any way that the bug get fixed sooner?
> 

Maybe not. It is too late to fix the non-critical bug on beta cycle(i.e., 48).

Comment 12

[Alice0775 White]

:hiro, what do you think comment#8 and comment#11?

Comment 13

[Hiroyuki Ikezoe (:hiro)]

If we/someone can provide an automation test for this issue,  I think I can uplift a fix with the test.  The changeset which fixed this issue is pretty small.  It's exactly https://hg.mozilla.org/integration/mozilla-inbound/rev/05cb31c61bf2 .

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

OK, so this is fixed, and we're discussing the uplift strategy.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Marking a duplicate of bug 1265605.
If someone writes an automation test for this issue, I will uplift a fix with the test.  Unfortunately I don't take time to write it in near future.

Thanks.

Comment 16

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

I do not consider this issue severe enough to include in a dot release, this is now a wontfix for Fx47.