1529707 - At startup: ###!!! ASSERTION: impossible to compute luminosity of a non-opaque color: 'NS_GET_A(aColor) == 255', file layout/base/nsCSSColorUtils.cpp, line 56

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[Daniel Holbert [:dholbert]]

I've been seeing this assertion several times in my debug build startup-spew today:

###!!! ASSERTION: impossible to compute luminosity of a non-opaque color: 'NS_GET_A(aColor) == 255', file layout/base/nsCSSColorUtils.cpp, line 56

It's one of the first few lines of logging for the parent process as well as for the first child process.

Here's the backtrace:

#0 0x00007f9293a0c75a in NS_GetLuminosity(unsigned int) (aColor=4277663477) at /scratch/work/builds/mozilla-central/mozilla/layout/base/nsCSSColorUtils.cpp:58
#1 0x00007f9293815e72 in nsLookAndFeel::GetIntImpl(mozilla::LookAndFeel::IntID, int&) (this=0x7f929bea4c00, aID=mozilla::LookAndFeel::eIntID_SystemUsesDarkTheme, aResult=@0x7ffcc6f8f0dc: 0)
at /scratch/work/builds/mozilla-central/mozilla/widget/gtk/nsLookAndFeel.cpp:716
#2 0x00007f9290465441 in mozilla::LookAndFeel::GetInt(mozilla::LookAndFeel::IntID, int) (aID=3338202136, aDefault=0) at ../dist/include/mozilla/LookAndFeel.h:634
#3 0x00007f9293989372 in nsMediaFeatures::InitSystemMetrics() () at /scratch/work/builds/mozilla-central/mozilla/layout/style/nsMediaFeatures.cpp:463
#4 0x00007f9293988e4f in Gecko_MediaFeatures_HasSystemMetric(mozilla::dom::Document const*, nsAtom*, bool) (aDocument=<optimized out>, aMetric=<optimized out>, aIsAccessibleFromContent=<optimized out>)
at /scratch/work/builds/mozilla-central/mozilla/layout/style/nsMediaFeatures.cpp:211
#5 0x00007f92969573af in style::gecko::media_features::eval_system_metric
(device=<optimized out>, query_value=<unknown type in /scratch/work/builds/mozilla-central/obj/dist/bin/libxul.so, CU 0x1e4d1e88, DIE 0x1e4d564f>, metric=..., accessible_from_content=16)
at servo/components/style/gecko/media_features.rs:485
#6 0x00007f9296c553fe in style::media_queries::media_list::MediaList::evaluate::{{closure}} (mq=0x7f927e281600) at servo/components/style/media_queries/media_list.rs:83
#7 0x00007f9296c54c24 in <core::slice::Iter<'a, T> as core::iter::iterator::Iterator>::try_fold (self=0x7ffcc6f8f200, init=<optimized out>, f=...)
at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/slice/mod.rs:2907
#8 0x00007f9296c54116 in core::iter::iterator::Iterator::any (self=0x7ffcc6f8ec18, f=...) at /rustc/9fda7c2237db910e41d6a712e9a2139b352e558b/src/libcore/iter/iterator.rs:1790
#9 0x00007f9296c55391 in style::media_queries::media_list::MediaList::evaluate (self=0x7f927e27d260, device=<optimized out>, quirks_mode=selectors::context::QuirksMode::NoQuirks)
at servo/components/style/media_queries/media_list.rs:78
#10 0x00007f9296bf1c08 in <style::stylesheets::rules_iterator::RulesIterator<'a, 'b, C> as core::iter::iterator::Iterator>::next (self=0x7ffcc6f8f2d0)
at servo/components/style/stylesheets/rules_iterator.rs:115
#11 0x00007f929675a6a8 in style::stylist::CascadeData::collect_applicable_media_query_results_into (device=<optimized out>, stylesheet=<optimized out>, guard=0x7ffcc6f91a58, results=0x7ffcc6f8f3f0)
at /scratch/work/builds/mozilla-central/mozilla/servo/components/style/stylist.rs:1874
#12 0x00007f929675adc1 in style::stylist::UserAgentCascadeDataCache::lookup
(self=<optimized out>, sheets=..., device=0x7ffcc6f8ec18, quirks_mode=selectors::context::QuirksMode::Quirks, guard=<optimized out>)
at /scratch/work/builds/mozilla-central/mozilla/servo/components/style/stylist.rs:99
#13 0x00007f929675a90f in style::stylist::DocumentCascadeData::rebuild (self=0x7f927e2d70c8, device=0x7f927e2d7008, quirks_mode=selectors::context::QuirksMode::Quirks, flusher=..., guards=0x7ffcc6f91a20)
at /scratch/work/builds/mozilla-central/mozilla/servo/components/style/stylist.rs:257
#14 0x00007f929675c4c8 in style::stylist::Stylist::flush (self=0x7f927e2d7008, guards=<optimized out>, document_element=<optimized out>, snapshots=<optimized out>)
at /scratch/work/builds/mozilla-central/mozilla/servo/components/style/stylist.rs:542
#15 0x00007f92967a2866 in style::gecko::data::PerDocumentStyleDataImpl::flush_stylesheets
(self=0x7ffcc6f8ec18, guard=<optimized out>, document_element=<unknown type in /scratch/work/builds/mozilla-central/obj/dist/bin/libxul.so, CU 0x1d89f3d3, DIE 0x1d8ba710>, snapshots=<unknown type in /scratch/work/builds/mozilla-central/obj/dist/bin/libxul.so, CU 0x1d89f3d3, DIE 0x1d8ba71f>) at /scratch/work/builds/mozilla-central/mozilla/servo/components/style/gecko/data.rs:182
#16 0x00007f929668d896 in Servo_StyleSet_FlushStyleSheets (raw_data=<optimized out>, doc_element=<optimized out>, snapshots=<optimized out>) at servo/ports/geckolib/glue.rs:1662
#17 0x00007f929396400f in mozilla::ServoStyleSet::UpdateStylist() (this=0x7f927e289b80) at /scratch/work/builds/mozilla-central/mozilla/layout/style/ServoStyleSet.cpp:1283
#18 0x00007f92939d47c2 in mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) (this=0x7f927e2d5000, aFlush=...)

I'm using the default "Yaru" theme, and I'm guessing that maybe the theme just recently started using a non-opaque color for some metric, and we're not expecting it...?

Comment 1

[Daniel Holbert [:dholbert]]

Ah, no, this is just a recent regression from bug 1525775.

That's where we added the problematic NS_GetLuminosity call, from our GTK nsLookAndFeel::GetIntImpl function:
https://hg.mozilla.org/mozilla-central/rev/738bb0805a9c#l1.13

Comment 2

[Daniel Holbert [:dholbert]]

The problematic color, for me, is the one for metric "nsLookAndFeel::eColorID_window", which is a query for the nscolor value mMozWindowBackground. It has numeric value 0xfef7f6f5 where 0xfe is the not-quite-opaque alpha value.

This variable (mMozWindowBackground) is set in nsLookAndFeel::EnsureInit, here:

905	  // Window colors
906	  style = GetStyleContext(MOZ_GTK_WINDOW);
907	  gtk_style_context_get_background_color(style, GTK_STATE_FLAG_NORMAL, &color);
908	  mMozWindowBackground = GDK_RGBA_TO_NS_RGBA(color);

The color variable there has type GdkRGBA, and its components are floating-point with these values:

{
  red = 0.96078431372549022, 
  green = 0.96470588235294119, 
  blue = 0.96862745098039216, 
  alpha = 0.999
}

Note that alpha is 0.999 there -- nearly opaque but not quite. :)

Comment 3

[Daniel Holbert [:dholbert]]

I think this corresponds to the following bit of my Yaru theming in /usr/share/themes/Yaru/gtk-3.0/gtk.css:

/***************
 * Base States *
 ***************/
.background {
  color: #3D3D3D;
  background-color: rgba(245, 246, 247, 0.999); }

So, these values (with non-1.0 alpha) really are indeed coming from my theme, AFAIK. So, we need to account for that possibility here.

Comment 4

[Daniel Holbert [:dholbert]]

I have no idea why themes would use transparent system colors (particularly nearly-opaque ones like 0.999), but I think our NS_GetLuminosity()-based judgement here (for dark-vs-light determination) is still basically legitimate as long as the colors are mostly-opaque.

(If they're not, then all bets are off, and we should just throw up our hands and avoid making a judgement.)

I've got a patch locally that treats colors with alpha-channel values above ~90% as being "opaque enough" for us to call NS_GetLuminosity on them. (I do this by doing fixup on the color before calling NS_GetLuminosity on it, so that NS_GetLuminosity can remain pure.)

I'll post it shortly.

Comment 5

[Karl Tomlinson (:karlt)]

The assertion comes from https://bugzilla.mozilla.org/show_bug.cgi?id=455217#c22

I don't think luminosity is useless with translucent colors. Often, the alpha value needs to be considered with it.

RelativeLuminanceUtils::Compute() ignores alpha, and should work fine here, if the preference is to keep the assertion.

Comment 6

[Karl Tomlinson (:karlt)]

https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/gfx/src/RelativeLuminanceUtils.h#19

Comment 7

[Daniel Holbert [:dholbert]]

Sure, we could use RelativeLuminanceUtils::Compute() too... That's probably simpler. I don't think we should care too much about behavior for themes with partially-transparent colors, since they're likely rare & pathological.

I'll post the patch I mentioned in comment 4 just for illustration/archival, but I think karlt's suggestion in comment 5 is probably simpler/saner (and there's likely no real-world impact either way).

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: patch option #1 (probably abandoned): nudge nearly-opaque colors to be fully-opaque before checking their luminosity

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: Bug 1529707: Use RelativeLuminanceUtils::Compute() to test for dark GTK themes (ignoring alpha channel). r?karlt

Previously we were using NS_GetLuminosity which asserts for non-opaque colors,
and my system theme happens to use a background color with alpha=0.999.

Luminosity judgements do get a bit more hand-wavy as colors get more
transparent, but it seems like we can still reasonably make an overall
"dark theme" judgement based on the RGB channels.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/244cd329c3bb
Use RelativeLuminanceUtils::Compute() to test for dark GTK themes (ignoring alpha channel). r=karlt

Comment 11

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/244cd329c3bb

Comment 12

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/244cd329c3bb