Any idea what might have provoked this late last week, Jonathan?

Bug 1272194 landed on inbound shortly before this started and the issue appears to be the scrollbar. Looks like a decent candidate to start with.

The background behind the scrollbar should not be black. That's a regression that happens with e10s only and this test is failing with e10s only. The test failures seem too consistent to be bug 1223198. Regression range for the black scrollbar background with 3.4 Ambiance confirms bug 1272194, thanks. 1463789193 ca3135fa04fc4df03bf91b1a88216729d16c9944 good 1463789318 53e791a65fa2be8a94fedb0a70d47cfa152ce2c8 bad

This is due to (<unknown>:16940): Gtk-CRITICAL **: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed #0 0x00007fc63dbf6764 in g_log () at /var/tmp/portage/dev-libs/glib-2.46.2-r3/work/glib-2.46.2/glib/gmessages.c:1115 #1 0x00007fc63baba7b7 in gtk_widget_get_style_context (widget=0x0) at gtkwidget.c:14107 #2 0x00007fc648e48023 in moz_gtk_scrollbar_trough_paint(WidgetNodeType, cairo_t*, GdkRectangle*, GtkWidgetState*, GtkScrollbarTrackFlags, GtkTextDirection) (widget=MOZ_GTK_SCROLLBAR_HORIZONTAL, cr=0x7fc5f7cd0000, rect=0x7fffbaf95970, state=0x7fffbaf95620, flags=MOZ_GTK_TRACK_OPAQUE, direction=GTK_TEXT_DIR_LTR) at /mnt/ssd1/karl/moz/dev/widget/gtk/gtk3drawing.cpp:1072 #3 0x00007fc648e4d1e0 in moz_gtk_widget_paint(WidgetNodeType, _cairo*, _cairo_rectangle_int*, GtkWidgetState*, int, GtkTextDirection) (widget=MOZ_GTK_SCROLLBAR_HORIZONTAL, cr=0x7fc5f7cd0000, rect=0x7fffbaf95970, state=0x7fffbaf95620, flags=1, direction=GTK_TEXT_DIR_LTR) at /mnt/ssd1/karl/moz/dev/widget/gtk/gtk3drawing.cpp:3126 ensure_window_widget() should have been added for the use of gProtoWindow when ensure_scrollbar_widget() was removed in https://hg.mozilla.org/mozilla-central/rev/827f631db4de#l3.142 but, in that revision, ensure_window_widget() was called earlier anyway via #0 0x00007f2f9bbbd8df in ensure_window_widget() () at /mnt/ssd1/karl/moz/dev/widget/gtk/gtk3drawing.cpp:117 #1 0x00007f2f9bbbe6ea in ensure_menu_popup_widget() () at /mnt/ssd1/karl/moz/dev/widget/gtk/gtk3drawing.cpp:534 #2 0x00007f2f9bbbe7c9 in ensure_image_menu_item_widget() () at /mnt/ssd1/karl/moz/dev/widget/gtk/gtk3drawing.cpp:560 #3 0x00007f2f9bbc4f61 in moz_gtk_images_in_menus() () at /mnt/ssd1/karl/moz/dev/widget/gtk/gtk3drawing.cpp:3133 #4 0x00007f2f9bbe22d2 in nsLookAndFeel::GetIntImpl(mozilla::LookAndFeel::IntID, int&) (this=0x7f2f8b98c3e0, aID=mozilla::LookAndFeel::eIntID_ImagesInMenus, aResult=@0x7ffe3553f314: 1) at /mnt/ssd1/karl/moz/dev/widget/gtk/nsLookAndFeel.cpp:787 #5 0x00007f2f9bb9859c in mozilla::LookAndFeel::GetInt(mozilla::LookAndFeel::IntID, int*) (aID=mozilla::LookAndFeel::eIntID_ImagesInMenus, aResult=0x7ffe3553f314) at /mnt/ssd1/karl/moz/dev/widget/nsXPLookAndFeel.cpp:912 #6 0x00007f2f983e983a in mozilla::LookAndFeel::GetInt(mozilla::LookAndFeel::IntID, int) (aID=mozilla::LookAndFeel::eIntID_ImagesInMenus, aDefault=0) at /mnt/sda11/karl/obj/dist/include/mozilla/LookAndFeel.h:561 #7 0x00007f2f9bd3ddb4 in InitSystemMetrics() () at /mnt/ssd1/karl/moz/dev/layout/style/nsCSSRuleProcessor.cpp:1103 #8 0x00007f2f9bd3e2b3 in nsCSSRuleProcessor::HasSystemMetric(nsIAtom*) (aMetric=0x7f2f86b2df40) at /mnt/ssd1/karl/moz/dev/layout/style/nsCSSRuleProcessor.cpp:1237 That chain was broken in https://hg.mozilla.org/mozilla-central/rev/764650604afd#l2.85

Review commit: https://reviewboard.mozilla.org/r/55660/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/55660/

Comment on attachment 8757119 [details] MozReview Request: bug 1274745 use ClaimStyleContext to ensure GtkWindow exists before using for scrollbar background r?stransky https://reviewboard.mozilla.org/r/55660/#review52410 Thanks for the patch, looks like my misake from the scrollbar patch.

https://reviewboard.mozilla.org/r/55660/#review52410 It was too easy to make such a mistake, but easy to fix. Having the getter also ensure, as in WidgetStyleCache, hopefully will mean we won't have to worry about this, thanks.