bug 1328899 don't use GTK prelight and active state flags when drawing textfield-multiline background r=stransky+263117
authorKarl Tomlinson <karlt+@karlt.net>
Tue, 17 Jan 2017 14:48:55 +1300
changeset 374605 af6601db2875a82cbba7983858cea78455b24b74
parent 374604 7ccd359d1e5e1f64c668cd6ef41a17016fda74ec
child 374606 792c6f70dde581401b8afedd6e96bb4ad37f9655
push id6996
push userjlorenzo@mozilla.com
push dateMon, 06 Mar 2017 20:48:21 +0000
treeherdermozilla-beta@d89512dab048 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersstransky
bugs1328899, 263117
milestone53.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
bug 1328899 don't use GTK prelight and active state flags when drawing textfield-multiline background r=stransky+263117 This is consistent with GTK not setting these flags with GtkTextView and GtkScrolledWindow. The active flag was triggering @selected_bg_color with Ambiance. This patch almost reverts the state flags to the logic prior to cd7544affe40 but keeps the focused flag in the scrolled window. MozReview-Commit-ID: IVY1sI2Hllw
widget/gtk/gtk3drawing.cpp
--- a/widget/gtk/gtk3drawing.cpp
+++ b/widget/gtk/gtk3drawing.cpp
@@ -35,16 +35,27 @@ static gboolean is_initialized;
 
 static gint
 moz_gtk_get_tab_thickness(GtkStyleContext *style);
 
 static gint
 moz_gtk_menu_item_paint(WidgetNodeType widget, cairo_t *cr, GdkRectangle* rect,
                         GtkWidgetState* state, GtkTextDirection direction);
 
+// GetStateFlagsFromGtkWidgetState() can be safely used for the specific
+// GtkWidgets that set both prelight and active flags.  For other widgets,
+// either the GtkStateFlags or Gecko's GtkWidgetState need to be carefully
+// adjusted to match GTK behavior.  Although GTK sets insensitive and focus
+// flags in the generic GtkWidget base class, GTK adds prelight and active
+// flags only to widgets that are expected to demonstrate prelight or active
+// states.  This contrasts with HTML where any element may have :active and
+// :hover states, and so Gecko's GtkStateFlags do not necessarily map to GTK
+// flags.  Failure to restrict the flags in the same way as GTK can cause
+// generic CSS selectors from some themes to unintentionally match elements
+// that are not expected to change appearance on hover or mouse-down.
 static GtkStateFlags
 GetStateFlagsFromGtkWidgetState(GtkWidgetState* state)
 {
     GtkStateFlags stateFlags = GTK_STATE_FLAG_NORMAL;
 
     if (state->disabled)
         stateFlags = GTK_STATE_FLAG_INSENSITIVE;
     else {    
@@ -869,17 +880,26 @@ moz_gtk_entry_paint(cairo_t *cr, GdkRect
     return MOZ_GTK_SUCCESS;
 }
 
 static gint
 moz_gtk_text_view_paint(cairo_t *cr, GdkRectangle* aRect,
                         GtkWidgetState* state,
                         GtkTextDirection direction)
 {
-    GtkStateFlags state_flags = GetStateFlagsFromGtkWidgetState(state);
+    // GtkTextView and GtkScrolledWindow do not set active and prelight flags.
+    // The use of focus with MOZ_GTK_SCROLLED_WINDOW here is questionable
+    // because a parent widget will not have focus when its child GtkTextView
+    // has focus, but perhaps this may help identify a focused textarea with
+    // some themes as GtkTextView backgrounds do not typically render
+    // differently with focus.
+    GtkStateFlags state_flags =
+        state->disabled ? GTK_STATE_FLAG_INSENSITIVE :
+        state->focused ? GTK_STATE_FLAG_FOCUSED :
+        GTK_STATE_FLAG_NORMAL;
 
     GtkStyleContext* style_frame =
         ClaimStyleContext(MOZ_GTK_SCROLLED_WINDOW, direction, state_flags);
     gtk_render_frame(style_frame, cr,
                      aRect->x, aRect->y, aRect->width, aRect->height);
 
     GdkRectangle rect = *aRect;
     InsetByBorderPadding(&rect, style_frame);