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 completes the migration of code from the github branch to the graphics
project repo. At this point all webrender-related code should be disabled
unless --enable-webrender is provided in the mozconfig.
MozReview-Commit-ID: Dea8rxM6UPL
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
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
The same name is retained for moz_gtk_widget_paint(), which is now more
consistent.
MozReview-Commit-ID: 9RtW66JQVGX
--HG--
extra : rebase_source : 3067daa4e9347cf689e9dccbd7e07578b52cf59c
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
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
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
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
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
This follows the same approach of considering block flow for all widgets
(in addition to resizers) as done for other toolkits in
https://hg.mozilla.org/mozilla-central/rev/4a65cacf8a37#l3.10
MozReview-Commit-ID: Ca3SMs1k2Tj
--HG--
extra : rebase_source : 9845e676aa2db5eecd222b7e8a678b2aecca659e
This converts |nsITransferable.flavorsTransferableCanExport| and
|nsITransferable.flavorsTransferableCanImport| to return a |nsIArray|.
|nsIFormatConverter.getInputDataFlavors| and
|nsIFormatConverter.getOutputDataFlavors| are updated as well.
The Gtk 3.20 scrollbars has moved towards usual box model. The scrollbar,
trough,thumb and scrollbar button can now have margin, padding and border set,
different for each direction (ie. left, right, bottom, top). The scrollbar
metrics become ignored in Gtk 3.20 and later.
* Draw scrollbar element [for GTK 3.20+]
* The border for scrollbar, trough, thumb and scrollbar buttons is newly
calculated as margin+padding+border [for GTK 3.20+].
* The margin is subtracted for scrollbar, trough and sb buttons during paint
function [for GTK 3.6+]
* All scrollbar widget's borders transfered from
nsNativeThemeGTK::GetWidgetBorder to the moz_gtk_get_widget_border.
* Added helper function NativeThemeToGtkTheme for mapping mozilla's widget type
to the gtk widget type.
* Scrollbar troughs are now drawn even when there is not enough room for
the thumb [GTK 3.20+]
MozReview-Commit-ID: jd2q67gKM1
--HG--
extra : rebase_source : ecc8b85401845113d84c6c5a48219a0c3d4f8de3
Change only right arrows to left arrows when direction is RTL
MozReview-Commit-ID: 3mMCAGCIUYP
--HG--
extra : rebase_source : 54fb3bc6455f2117cb0ddae06c4f895f58204d0f
extra : amend_source : 1398b66e4184c71755801c94ecdc2c22ab961ec0
extra : histedit_source : c17fae6ae45191a685af4274d5a6789fb040d691
Using direction-changed signal, we detect keyboard change for bidi.
When system uses fcitx's IM and ibus's arabic keyboard layout, this signal might fire often when switching layout and gdk_keymap_get_direction might return invalid bidi information. But I think that this is rare issue. Most users don't use Firefox Arabic version (it means that bidi.browser.ui = true) with ibus Arabic layout and fcitx CJK IM. Since there is no GTK3 API to get current IM module, I cannot find workaround for this.
MozReview-Commit-ID: DL8uUXJFWYz
--HG--
extra : rebase_source : a93e8969b878d01048726e03b24f362ead7e2059
Using direction-changed signal, we detect keyboard change for bidi.
When system uses fcitx's IM and ibus's arabic keyboard layout, this signal might fire often when switing layout and gdk_keymap_get_direction might return invalid bidi infromation. But I think that this is rare issue. Most users don't use Firefox Arabic version (it means that bidi.browser.ui = true) with ibus arabic layout and fcitx CJK IM. Since there is no GTK3 API to get current IM module, I cannot find workaround for this.
MozReview-Commit-ID: DL8uUXJFWYz
--HG--
extra : rebase_source : 18b7d5c84f48acd62fa14e21a67b711106fb7d63
You know, when Korean IME commits string, then it sometimes set next preedit string. So reseting context causes that next preedit string is committed.
So we shouldn't reset IME context with preedit_end.
MozReview-Commit-ID: CZJJvYjcrKY
--HG--
extra : rebase_source : d7e2e80930355794a40466c68fe22e43e7164d72
This is important for RTL locales which are drawn with explicit direction but
measured with no direction.
MozReview-Commit-ID: C4k5vgpKggD
--HG--
extra : rebase_source : 6fc3c6dae296d8dabe189361481b12a17e75dcc6
Previously oldState differed from aStateFlags just because it contained
direction flags.
MozReview-Commit-ID: DuGpHdt9EuX
--HG--
extra : rebase_source : 05a06d130a51c7a1830804254ec87c6697ade4a8
ibus-pinyin has a bug. When application calls gtk_im_context_reset(), which means selection is changed in application, ibus-pinyin sents a set of composition signals with empty commit string. Therefore, selecting text causes removing it.
For preventing it but not breaking the other IMEs which use surrounding text, we should give up to call gtk_im_context_reset() if IME hasn't retrieved surrounding text after the last selection change. Not having retrieved surrounding text means that the IME doesn't have any cache of contents. Therefore, not calling gtk_im_context_reset() at selection change must be safe for such IMEs.
MozReview-Commit-ID: 5cbIZjpd7zN
--HG--
extra : rebase_source : 6010b3e055d66ebd2ed50f9b3ee8ff2330d3c6ab
This function is an infallible alternative to nsIURI::GetSpec(). It's useful
when it's appropriate to handle a GetSpec() failure with a failure string, e.g.
for log/warning/error messages. It allows code like this:
nsAutoCString spec;
uri->GetSpec(spec);
printf("uri: %s", spec.get());
to be changed to this:
printf("uri: %s", uri->GetSpecOrDefault().get());
This introduces a slight behavioural change. Previously, if GetSpec() failed,
an empty string would be used here. Now, "[nsIURI::GetSpec failed]" will be
produced instead. In most cases this failure string will make for a clearer
log/warning/error message than the empty string.
* * *
Bug 1297961 (part 1b) - More GetSpecOrDefault() additions. r=hurley.
I will fold this into part 1 before landing.
--HG--
extra : rebase_source : ddc19a5624354ac098be019ca13cc24b99b80ddc
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 : 1c42bb32a662f2659c934a245ecd0025045120a5
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 2a94a47f1e7fe986d1efc3854c72968a3e28e365
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 : f276e1629fcd0ffccb8c8dbec7bba6639a5ebd9f
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 : 82733f682c9e254e20354cc6908955a1e7485ee7
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : ccf64aaa9364d096e1f060ef77be7e8455b11e1f
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 : b8a0d9a49b31929dd06af9e61fc57f484af7671d
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : e98b7f9970a920c39e941bb531dfc098125913d1
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Its return value is only checked in one low-value assertion.
The patch also does the following.
- Removes the Android and GTK overloadings of EnableDragDrop(), which are
identical to the nsBaseWidget one.
- Streamlines the Windows implementation: fixes the indentation and takes
advantage of infallible |new|.
--HG--
extra : rebase_source : d090848cf5ea2e92c0188b07559c1e1f3899829f
The only implementation of SetSizeMode() that can fail is the nsCocoaWindow
one, on an Objective C exception, which is unlikely and can be swallowed.
This allows some nsGlobalWindow functions to become infallible as well.
--HG--
extra : rebase_source : 85d54185f63d2c138ee3f3e0e0bfe3b5e805a981
Nicholas Nethercote
Mozilla Graphics Team
Karl Tomlinson
Martin Stransky
Phil Ringnalda
Kan-Ru Chen
Thomas Wisniewski
Wes Kocher
Lee Salzman
Ryan VanderMeulen
Masatoshi Kimura
Jan Horak
Jonathan Watt
Kartikaya Gupta
Sylvestre Ledru
Ryan Hunt
Carsten "Tomcat" Book
Neil Deakin
Eric Rahm
Makoto Kato
Nicolas Silva
Markus Stange
Enes Goktas
David Anderson
Jonathan Kingston
Masayuki Nakano
Michael Layzell
Ryan Hunt
Botond Ballo
Milan Sreckovic
Olli Pettay