1310611 - Erroneous transition when scale-transforming text with ellipsis

Status: VERIFIED WORKSFORME

(Core :: Graphics: Layers, defect, P3)

Description

[David [:Ceremony]]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20161016004034

Steps to reproduce:

Take a look at https://jsfiddle.net/kf0btc7s/
Hover over the text look at the ellipsis at the end of the text


Actual results:

It just looks wrong.


Expected results:

"..." should have the same colors as the text it precedes. Also, an element's ellipsis shouldn't be affected by the transition of another element, unless it causes that element to reflow.

Comment 1

[Tooru Fujisawa [:arai]]

Can you post a screenshot?

Comment 2

[Alice0775 White]

I can reproduce on Nightly52.0a1 Windows10 if Full/text zoom level > 150% or layout.css.devPixelsPerPx > 1.50.

Comment 3

[David [:Ceremony]]

Attachment: Animation of the issue

Here's a stopmotion recording of how ellipsis look and behave in ff

Comment 4

[Tooru Fujisawa [:arai]]

thanks
it might be something related to bug 1289722.

Comment 5

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=165c3fd176ec&tochange=d954ed24e795

Regression window with force enable direct2d1.1:
i.e, gfx.direct2d.use1_1;true
     gfx.content.azure.backends;direct2d1.1,direct2d,cairo
     gfx.canvas.azure.backends;direct2d1.1,direct2d,skia,cairo
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2badc0f1f829&tochange=8e28464849fa

Via local build:
Last Good: 20e97c8496e4	
First Bad: 7b9201731195	

Triggered by : 7b9201731195	Matt Woodrow — Bug 1046550 - Part 3: Use Direct2D 1.1 when preffed on. r=bas

Comment 6

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

Too late to fix in 50.1.0 release

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Maybe Thinker has some ideas otherwise?

Comment 8

[Thinker Li [:sinker]]

I can not reproduce this bug on Linux.  I will try to reproduce it with Windows.

Comment 9

[Thinker Li [:sinker]]

Attachment: single-file-test.html

Comment 10

[Thinker Li [:sinker]]

I look into the problem, and find some weird problems.
There is two paints in content process for each omta animation/transition, one is just before the start of the transition to trigger the animation at compositor, the other is just after the stop of the transition.  The problems,

 - the dump of surface of painted layer (MOZ_DUMP_PAINT) has no ellipses in for the paint before the transition.
   - it means some magic things happening between here and where uploading the texture.
 - I try to dump texture at compositor (MOZ_DUMP_COMPOSITOR_TEXTURES), it crash Firefox.
 - LayerScope does not show textures too.

I will go back this bug later.

Comment 11

[u459114]

(In reply to Thinker Li [:sinker] from comment #10)
> I look into the problem, and find some weird problems.
> There is two paints in content process for each omta animation/transition,
> one is just before the start of the transition to trigger the animation at
> compositor, the other is just after the stop of the transition.  The
> problems,
Hi Thinker,
Any idea where I can set breakpoint to dump these two drawing result in content process?

Comment 12

[Thinker Li [:sinker]]

(In reply to C.J. Ku[:cjku](UTC+8) from comment #11)
> (In reply to Thinker Li [:sinker] from comment #10)
> > I look into the problem, and find some weird problems.
> > There is two paints in content process for each omta animation/transition,
> > one is just before the start of the transition to trigger the animation at
> > compositor, the other is just after the stop of the transition.  The
> > problems,
> Hi Thinker,
> Any idea where I can set breakpoint to dump these two drawing result in
> content process?
You need to add a line in mozconfig

 ac_add_options --enable-dump-painting

And, set environment MOZ_DUMP_PAINT=1 before running firefox.
Then, you will see dumps of display items and layers in content processes.  It includes dumps of painted layers.  The dumps of surface of painted layer are in base64.  It would be easy to decode them with base64 decoder to png files.

Comment 13

[Gregory Pappas [:gregp]]

Reporter, are you still experiencing this issue?

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 15

[Gregory Pappas [:gregp]]

Unable to reproduce

Comment 16

[David [:Ceremony]]

Yeah, it's fixed now. Sorry, forgot to respond!

Comment 17

[Gregory Pappas [:gregp]]

Thanks for following up!!