1305036 - text-overflow: ellipsis is painted as solid bar with skia backend (missing w/ some other backends), if an element with position:fixed and background-color is in DOM before

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect, P3)

Description

[fr33k4t3k]

Attachment: bugzilla.png

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

my basic code:

#fixed {
    position: fixed;
    top: 0;
    right: 0;
    width: 100px;
    height: 100px;
    background-color: green;
}
#overflow {
    text-overflow: ellipsis;
    white-space: nowrap;
    overflow: hidden;
    width: 100px;
}

<div id="fixed"></div>
<div id="overflow">abcdefghijklmnopqrstuvwxyz</div>


Actual results:

text gets cut, but no dots are displayed

Comment 1

[Loic]

Attachment: 1305036.html

Comment 2

[Mats Palmgren (inactive)]

The testcase works fine for me on Linux, in both v49 and Nightly.

Comment 3

[fr33k4t3k]

(In reply to Mats Palmgren (:mats) from comment #2)
> The testcase works fine for me on Linux, in both v49 and Nightly.
then it seems to be windows related; I tested on win10 with v48.0.0.2 and v50.0a2 and it doesn't work as expected.

Comment 4

[Daniel Holbert [:dholbert]]

I do see an issue on Linux, and I think it's a manifestation of the same underlying problem that's causing trouble on Windows.

Specifically, I see a soloid horizontal bar instead of an ellipsis.  Mozregression dates this to bug 1278957 (which switched us to using the skia backend on Linux).  I only see this horizontal-bar glitch with the specific conditions in this bug's testcase, too (position:fixed element, with background-color, in DOM before the ellipsis element).  If I vary any of those factors, I see a normal ellipsis.

So I suspect some version of this bug (no-ellipsis or bar-ellipsis) reproduces with an Azure backend of "direct2d1.1" (the preferred backend on windows) and skia (the new preferred backend on Linux), though not with cairo (the old preferred backend on Linux).  There might be another factor as well, if Mats really isn't seeing any issues on Linux, though.

Comment 5

[Mats Palmgren (inactive)]

Some kind of graphics / layers issue then?

Comment 6

[Loic]

I see the issue only with HWA disabled on Win 7.

Comment 7

[Loic]

Regression range on Windows:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=35046df9df1f&tochange=70a113676b21

I think it's due to bug 1148855.

Comment 8

[Mats Palmgren (inactive)]

FYI, the text-overflow display item class is here:
http://searchfox.org/mozilla-central/rev/c31ad35f39c6187b2e121aa6d3a39b7f67397010/layout/generic/TextOverflow.cpp#164

Comment 9

[Lee Salzman [:lsalzman]]

Markus, can you take a look if this is related to bug 1148855 as Loic thinks?

Though, I can't reproduce this one on Linux with Skia or Cairo content with Nightly.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 49.

Comment 11

[Markus Stange [:mstange]]

(In reply to Lee Salzman [:lsalzman] from comment #9)
> Markus, can you take a look if this is related to bug 1148855 as Loic thinks?

Yes, I think Loic is right. If I turn on layer borders, I can see that we create a separate layer for the ellipsis item now. We wouldn't have done that before bug 1148855.

(If the page were horizontally scrollable to the left, then the ellipsis could conceivably overlap with the fixed layer, and apparently it's above the fixed layer in z-order, so we need to pull it out into a separate layer.)

> Though, I can't reproduce this one on Linux with Skia or Cairo content with
> Nightly.

I can't reproduce it on Mac either.

Comment 12

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

While this is uncovered by the layerization change, it sounds like it is an underlying issue in graphics, only on some backends.  A good background task.

Comment 13

[Lee Salzman [:lsalzman]]

Attachment: implement nsDisplayTextOverflowMarker::GetComponentAlphaBounds to handle ellipsis with subpixel AA

We were trying to render the ellipsis with subpixel AA into a BGRA surface. So when composited, this just showed up as a black (or transparent) mess in the places that should have been anti-aliased. This was because nsDisplayTextOverflowMarker, which was doing the drawing, did not implement GetComponentAlphaBounds.

If subpixel AA was not enabled, everything would seem to work, and thus that was why it was not reproducible in some configurations.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9f6c73141311
implement nsDisplayTextOverflowMarker::GetComponentAlphaBounds to handle ellipsis with subpixel AA. r=mstange

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9f6c73141311

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Wontfix for 54, since we are building the release candidate today.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Given that ESR52 has a high number of Skia users, is this something we should consider backporting there?

Comment 18

[Lee Salzman [:lsalzman]]

Comment on attachment 8873600 [details] [diff] [review]
implement nsDisplayTextOverflowMarker::GetComponentAlphaBounds to handle ellipsis with subpixel AA

[Approval Request Comment]
User impact if declined: Ellipsis fail to show up with text-overflow.
Fix Landed on Version: 55
Risk to taking this patch (and alternatives if risky): none
String or UUID changes made by this patch: none

Comment 19

[Gerry Chang [:gchang]]

Comment on attachment 8873600 [details] [diff] [review]
implement nsDisplayTextOverflowMarker::GetComponentAlphaBounds to handle ellipsis with subpixel AA

Per comment #17, ESR52 has a high number of Skia users. Let's uplift it to ESR52.3.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/c42a348f2ed0