Closed Bug 1511878 Opened 6 years ago Closed 6 years ago

CSS GrayText computes to black on macOS 10.14

Categories

(Core :: Widget: Cocoa, defect, P1)

Product:
Core
Component:
Widget: Cocoa
Version:
63 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla66
Tracking Flags:
Tracking Status
firefox64 --- wontfix
firefox65 --- verified
firefox66 --- verified

People

(Reporter: gregorydkraus, Assigned: spohl)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

graytext_2cases.html
(deleted), text/html
Details
Patch
(deleted), patch
mstange
: review+
RyanVM
: approval-mozilla-beta+
Details | Diff | Splinter Review
Attached file graytext_2cases.html (deleted) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: Open the attached file graytext_2cases.html. The expanded select list has the first item disabled, but it is still black, not gray. Actual results: The first option, which is disabled, is black, not gray in the expanded select list Expected results: The disabled item should have been gray in the expanded list. Chrome has the same problem, but Safari does not. It only appears to impact OS X, and maybe only 10.14. Windows browsers are not impacted.
Neil, do you know if this is working like that on OSX only by design?
Component: CSS Parsing and Computation → Layout: Form Controls
Flags: needinfo?(enndeakin)
I don't see any issue in 10.13 -- the disabled option looks grey. Perhaps this is a native theme issue in 10.14 only?
Flags: needinfo?(enndeakin)
This isn't restricted to text list. The following also reproduces the issue: data:text/html,<p style="color: GrayText;">This text should be grey</p> Curious that it works in the combobox. Maybe that's because the combobox dropdown renders in the parent process?
Status: UNCONFIRMED → NEW
Component: Layout: Form Controls → CSS Parsing and Computation
Ever confirmed: true
Priority: -- → P2
Summary: CSS graytext gets rendered as (0,0,0) in expanded select list → CSS GrayText computes to black on macOS 10.14
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Priority: P2 → P1
Attached patch Patch (deleted) — — Splinter Review

This turns out to be due to a change in the way this system color is specified by the OS:

On 10.13, this appears to be: { R:0.5 G:0.5 B:0.5 A:1 }
On 10.14, this appears to be: { R:0 G:0 B:0 A:0.247... }

In other words, 10.14 uses the alpha channel to create a grey that is lighter than what we have on 10.13. I have confirmed that by using an nscolor that takes the alpha channel into account, we exactly match the color in Safari on 10.14.

Attachment #9036375 - Flags: review?(mstange)
Comment on attachment 9036375 [details] [diff] [review] Patch Review of attachment 9036375 [details] [diff] [review]: ----------------------------------------------------------------- Thanks! If we add more callers of this type, it might make sense to have two functions, GetRGBColorFromNSColor and GetRGBAColorFromNSColor, but for now it doesn't seem needed.
Attachment #9036375 - Flags: review?(mstange) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/62f90a1062e5d87c38c5431c17af6fbdd8c7b059 Bug 1511878: Start respecting the alpha channel for disabled control text color on macOS to accommodate the way this system color is declared by the OS on macOS 10.14+. r=mstange

https://hg.mozilla.org/mozilla-central/rev/62f90a1062e5

Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox66: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

This affects the Firefox UI in various places. Can we get this uplifted?

Blocks: mojave
status-firefox64: --- → wontfix
status-firefox65: --- → affected
Flags: needinfo?(spohl.mozilla.bugs)

Comment on attachment 9036375 [details] [diff] [review]
Patch

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: macOS 10.14+

User impact if declined: Various instances of text that is supposed to appear grey will appear black on 10.14. This affects the Firefox UI as well as web content.

Is this code covered by automated tests?: No

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: No

If yes, steps to reproduce:

List of other uplifts needed: none

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): This is a tiny change to the way we generate the color for disabled text by newly respecting the alpha channel along with the existing RGB values.

String changes made/needed: none

Flags: needinfo?(spohl.mozilla.bugs)
Attachment #9036375 - Flags: approval-mozilla-beta?

Comment on attachment 9036375 [details] [diff] [review]
Patch

[Triage Comment]
Fixes a bug causing grey text to appear black instead on macOS 10.14. Approved for 65.0b12.

Attachment #9036375 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Depends on: 1520522
Flags: qe-verify+

Hello all,

Manage to reproduce the issue on FF Nightly 65.a1(BuildID:20181203214946) on macOS 10.14 (Mojave)

Confirming this issue as verified fixed on the latest FF Nightly 66.0a1(BuildID:20190117215514) and 65.0b12(BuildID:20190117232427) on macOS 10.14 (Mojave).

Status: RESOLVED → VERIFIED
status-firefox65: fixed → verified
status-firefox66: fixed → verified
Flags: qe-verify+
Regressions: 1620048
Regressions: 1628528
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: