This patch changes it from |NS_IMETHOD| to |virtual void| because every
implementation of these functions always returns |NS_OK|.
--HG--
extra : rebase_source : 07ee29c514bf35b97d7195c53bb5b9220d1ef961
This patch changes them from |NS_IMETHOD| to |virtual void| because every
implementation of these functions always returns |NS_OK|.
--HG--
extra : rebase_source : 6207df5a46aeb6b8aaa0f697447a51bc6a6dc366
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from the android nsIWidget instance,
because it can use the nsBaseWidget one.
--HG--
extra : rebase_source : 0791d3cb05907d6b41879549b52f3a33018abf45
This patch removes its return value, because none of the call sites check it
except for one non-vital assertion.
--HG--
extra : rebase_source : 3471c4e22394b8a05c6708d0f8469686ffad9814
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : a1a04193bc3940f1468c7c235f6d6e0341d0f1c2
Specifically: OnDefaultButtonLoaded, AttachNativeKeyEvent, BeginMoveDrag,
BeginResizeDrag, GetAttention. These are all fallible functions whose result is
always checked.
The patch also moves some trivial function definitions from nsBaseWidget.cpp to
nsBaseWidget.h, and removes the android BeginResizeDrag() because it can
use the nsBaseWidget one.
--HG--
extra : rebase_source : ef32a41b547bcbc21f7df0043f683307470b136e
This adjustment is required for changes to MOZ_GTK_TEXT_VIEW in a6aabcb07a6e.
MOZ_GTK_TEXT_VIEW_TEXT now retrieves the equivalent node from WidgetStyleCache.
MozReview-Commit-ID: 2zfHCKMT0ov
--HG--
extra : rebase_source : 39edee068f44cf9d2f6cccffc89dcd7c2c2616d5
This makes balancing with gtk_style_context_restore()/ReleaseStyleContext()
unnecessary, and the style resolution cached in the style contexts is not
invalidated so frequently.
MozReview-Commit-ID: BKwyqoQsjv2
--HG--
extra : rebase_source : 2091fc84a9ecb8b55e7d3e36e72cbd03ea826ac8
This is necessary for GTK to match CSS rules against classes on ancestor nodes
of style contexts constructed from paths.
It can be tested with the following in ~/.config/gtk-3.0/gtk.css
tooltip.background label {padding: 100px;}
MozReview-Commit-ID: EUQ9ndeSl1Z
--HG--
extra : rebase_source : 95c267c5495791a40e755aacf14a80c750fbedd2
Some themes do not draw the "border" subnode, but instead draw a border on the
frame root node.
MozReview-Commit-ID: Fx67mQhhYmz
--HG--
extra : rebase_source : 150168171d521df2c603541e33b10ca287b26b43
The same name is retained for moz_gtk_widget_paint(), which is now more
consistent.
MozReview-Commit-ID: 9RtW66JQVGX
--HG--
extra : rebase_source : 3067daa4e9347cf689e9dccbd7e07578b52cf59c
In GTK 3.20, gtk_menu_item_draw() just draws the root widget gadget, depending
on the theme to style menu items with CSS name "separator" appropriately.
MozReview-Commit-ID: 6AIxPzFe0Rg
--HG--
extra : rebase_source : 58a1ab4c78d94cf186e923354332ecb30aa491f8
instead of using the context belonging to a widget.
Only the style context is cached, instead of the whole widget.
Using the style context from a widget meant that rendering displayed the
initial appearance of animations after state changes, but there was no
invalidation to trigger the final rendering in the animations.
Style contexts constructed from paths do not incorporate animations.
(See gtk_css_path_node_update_style() in GTK.) Therefore they provide the
appropriate rendering for Gecko's model, which is not expecting animations.
There is no mechanism available to display animations when using style
contexts constructed from paths, but the GtkWidget animation design is also
not suitable for rendering potentially multiple elements each in a different
state of their animation.
This contexts-from-paths approach can be extended also to other widget types,
but this is a smaller change intended for uplift to other branches to address
a regression in menuitem rendering.
MozReview-Commit-ID: EFV7swWQtm4
--HG--
extra : rebase_source : 689f7340007c889ce0eaeb3b4acd228d45ad0d6d
CreateStyleForWidget() then provides the same behavior with
g_style_context_save() as contexts from widget root style nodes.
MozReview-Commit-ID: 6lRCp3XOoRr
--HG--
extra : rebase_source : ad161eef11e0dc70c8a487c204f109eceac3b1c4
This is necessary to switch from caching GtkWidgets to caching
GtkStyleContexts only.
MozReview-Commit-ID: 6Rwinr4AY8l
--HG--
extra : rebase_source : 930a501b3ecd5f124631e3f96fd6ca7611d078ff
The GtkContainer border-width property defaults to zero. It is not influenced
by theme CSS. While theme engines can theoretically modify default values for
properties of any class, I don't think that is something that needs to be
supported.
Removing this code is necessary to switch from caching GtkWidgets to caching
GtkStyleContexts only.
MozReview-Commit-ID: IxgM8qjfK3a
--HG--
extra : rebase_source : c5c94c19227d7e7d31c4a094bb4fb68f094ddb50
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
Tooltip widget is made in GTK3 as following tree:
* Tooltip window
* Horizontal Box
* Icon (not supported by Firefox)
* Label
Each element can be fully styled by CSS of GTK theme so we have to draw all
elements with appropriate offset and full box model.
MozReview-Commit-ID: E9yYd5UWBu4
--HG--
extra : amend_source : 99539e914e8d3fa07f6bed8a315e40c7d593f277
This was needed in GTK2 to get the style of the widget, but styles are almost
independent of widgets with GTK3, where realizing is not necessary to get the
style context.
MozReview-Commit-ID: GtL2FLDl9uA
--HG--
extra : rebase_source : 926e6b7fee9a15fe5c86be7327c60b146db11316
