Changing background color makes text semi transparent.

VERIFIED FIXED in Firefox 37

Status

()

Core
Graphics
--
major
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: avada, Assigned: tnikkel)

Tracking

({regression})

Trunk
mozilla39
All
Windows 8.1
regression
Points:
---

Firefox Tracking Flags

(firefox35 unaffected, firefox36+ unaffected, firefox37+ fixed, firefox38+ fixed, firefox39 verified)

Details

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Created attachment 8566093 [details]
Image illustrating the bug.

I've been noticing this since autumn. It used to work properly before.
I have this in a stylish script:
#bookmarksPanel, #history-panel, #sidebar, #sidebar-header, #sidebar-box
{
  /*background-color: transparent !important;*/
  background-color:  rgba(255,255,255,0.2) !important;
}
I only change the background color, but for some reason the text gets semi-transparent, by the looks of it.

Beta and stable seem to be unaffected so far.
(Reporter)

Comment 1

3 years ago
Created attachment 8566097 [details]
normal appearance (black text)
(Reporter)

Comment 2

3 years ago
Previously I reported it to the stylish dev. But it's apparently not a stylish bug:
https://github.com/JasonBarnabe/stylish/issues/210
> I've been noticing this since autumn.

Would you be willing to bisect on nightlies to see when the problem appeared for you?
Flags: needinfo?(dqeswn)
(Reporter)

Comment 4

3 years ago
If I must. Do nightlies even go back that far?
Flags: needinfo?(dqeswn)
Very much so, yes.  The tinderbox on-checkin builds go back a few months; we have nightlies for years back.

I'd offer to do it myself, but there's really not enough information in comment 0 for me to be able to reproduce the bug.  :(
(Reporter)

Comment 6

3 years ago
Okay, so I tried nightlies:

Last good:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/10/2014-10-01-03-02-05-mozilla-central/

First bad:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/10/2014-10-02-03-02-02-mozilla-central/

Specifically I tried these builds:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/10/2014-10-01-03-02-05-mozilla-central/firefox-35.0a1.en-US.win64-x86_64.installer.exe

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/10/2014-10-02-03-02-02-mozilla-central/firefox-35.0a1.en-US.win64-x86_64.installer.exe
Thank you for doing that!

That first build is from rev 14665b1de5ee, the second is from rev 2399d1ae89e9, so the changes between those nightlies are: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=14665b1de5ee&tochange=2399d1ae89e9

The most likely thing in there is bug 902952.  Could you try setting the "gfx.direct2d.use1_1" preference to false in about:config and changing the "gfx.content.azure.backends" preference to "direct2d,cairo" to see if that's the problem?  Might require a restart...
(Reporter)

Comment 8

3 years ago
It appears to fix the issue.
[Tracking Requested - why for this release]: Rendering regression

Great, thanks!

Bas, can you please take a look at this?
Blocks: 902952
Status: UNCONFIRMED → NEW
tracking-firefox36: --- → ?
tracking-firefox37: --- → ?
Component: CSS Parsing and Computation → Graphics
Ever confirmed: true
Flags: needinfo?(bas)
Keywords: regression
[Tracking Requested - why for this release]:
tracking-firefox38: --- → ?
We disabled D2D 1.1 in 36 in beta 9. I don't think the current beta is affected anymore.
However, shipping D2D 1.1 in 37 is part of our objective for this release. Tracking it for 37.
status-firefox35: --- → unaffected
status-firefox36: --- → unaffected
status-firefox37: --- → affected
status-firefox38: --- → affected
tracking-firefox36: ? → +
tracking-firefox37: ? → +
tracking-firefox38: ? → +
(In reply to Boris Zbarsky [:bz] from comment #10)
> [Tracking Requested - why for this release]:

I wonder if this is another layout bug with layout incorrectly determining the transparency of the text background as in bug 1102896.
Flags: needinfo?(bas)
Depends on: 1102896
This is not actionable until bug 1102896 is fixed?  Once it is, is there anything left in this bug?
(Assignee)

Comment 14

3 years ago
Created attachment 8568831 [details] [diff] [review]
patch

The tree body item doesn't report any component alpha bounds but I guess it draws any containing text with default settings (it doesn't seem to disable it anywhere) and that means subpixel AA.

I just made it report it's whole bounds a component alpha, which is a little overkill, we could do much better but that would require looking at the tree structure pieces. And we also have to support disabled component alpha.
Assignee: nobody → tnikkel
Attachment #8568831 - Flags: review?(roc)
(Assignee)

Comment 15

3 years ago
Bug 1102896 doesn't seem to be related.
No longer depends on: 1102896
Attachment #8568831 - Flags: review?(roc) → review+
(Assignee)

Comment 16

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/af1e21dc0e01
https://hg.mozilla.org/mozilla-central/rev/af1e21dc0e01
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Uplift perhaps? :)
Flags: needinfo?(tnikkel)
(Assignee)

Comment 19

3 years ago
Comment on attachment 8568831 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: bug 902952
[User impact if declined]: text in xul tree elements not over opaque pixels will like translucent or disappear
[Describe test coverage new/current, TreeHerder]: nope
[Risks and why]: should be pretty low risk
[String/UUID change made/needed]: none
Flags: needinfo?(tnikkel)
Attachment #8568831 - Flags: approval-mozilla-beta?
Attachment #8568831 - Flags: approval-mozilla-aurora?
(In reply to Timothy Nikkel (:tn) from comment #19)
> [Describe test coverage new/current, TreeHerder]: nope

Given that we have no test coverage, can you please verify on m-c before uplift?
Flags: needinfo?(tnikkel)
(Assignee)

Comment 21

3 years ago
I checked on my machine on m-c and it was fixed, but that doesn't really add much new information since I also checked that it fixed the bug when I made the patch.
Flags: needinfo?(tnikkel)
(In reply to Timothy Nikkel (:tn) from comment #21)
> I checked on my machine on m-c and it was fixed, but that doesn't really add
> much new information since I also checked that it fixed the bug when I made
> the patch.

Thanks Timothy.

Avada - As the reporter, if you have time, can you please confirm that you can no longer reproduce this issue in the latest Nightly build?
Flags: needinfo?(dqeswn)
Comment on attachment 8568831 [details] [diff] [review]
patch

Tested on m-c. Let's get this into Beta 2. Beta+ Aurora+
Attachment #8568831 - Flags: approval-mozilla-beta?
Attachment #8568831 - Flags: approval-mozilla-beta+
Attachment #8568831 - Flags: approval-mozilla-aurora?
Attachment #8568831 - Flags: approval-mozilla-aurora+
(Reporter)

Comment 24

3 years ago
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #22)
> (In reply to Timothy Nikkel (:tn) from comment #21)
> > I checked on my machine on m-c and it was fixed, but that doesn't really add
> > much new information since I also checked that it fixed the bug when I made
> > the patch.
> 
> Thanks Timothy.
> 
> Avada - As the reporter, if you have time, can you please confirm that you
> can no longer reproduce this issue in the latest Nightly build?

It looks okay now with d2d 1.1 on.
Flags: needinfo?(dqeswn)
Thanks Avada. Marking 39 as verified.
Status: RESOLVED → VERIFIED
status-firefox39: fixed → verified
https://hg.mozilla.org/releases/mozilla-aurora/rev/5a6ad0eb4437
status-firefox38: affected → fixed
https://hg.mozilla.org/releases/mozilla-beta/rev/a12ea2668d1c
status-firefox37: affected → fixed
You need to log in before you can comment on or make changes to this bug.