Bug 1514156 expects that nsWindow::OnExposeEvent() is called after frame_callback_handler() called. But it did not happen during opening add-ons(gecko profiler). Then we need to trigger rendering directly from frame_callback_handler() call.
Differential Revision: https://phabricator.services.mozilla.com/D20272
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
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.
Differential Revision: https://phabricator.services.mozilla.com/D20748
--HG--
extra : moz-landing-system : lando
This patch enables the shape mask in CSD and Window manager decorations mode
when we're runnin on composited screen and mozilla.widget.use-argb-visuals is not set.
Also don't use shape mask with Wayland and GL backend. When shape mask is set,
advertise toplevel window transparency but don't advertise it
as alpha to GtkCompositorWidget.
Differential Revision: https://phabricator.services.mozilla.com/D20726
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
nsWaylandDisplay needs to be allocated for each calling thread(main thread, compositor thread and render thread)
Differential Revision: https://phabricator.services.mozilla.com/D20118
--HG--
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
When GDK_BACKEND is wayland, widget is not fully mapped during creating CompositorSession. Needs to create valid EGLSurface after widget is fully mapped.
Differential Revision: https://phabricator.services.mozilla.com/D18940
Recently we quit nsWindow::OnWindowStateEvent()/window_state_event handler when titlebar needs an update due to focus change.
That's incorrect as we need to process other information from the handler - maxminized/normal window state.
Differential Revision: https://phabricator.services.mozilla.com/D18681
--HG--
extra : moz-landing-system : lando
Unfortunately, we're not sure whether ibus always handles non-dead key events
asynchronously or synchoronously. Therefore, for safer fix, this patch makes
IMContextWrapper::OnKeyEvent() decide that with the result of
gtk_im_context_filter_keypress(). If active IME is ibus and it consumes non-
synthesized events on password fields, it adjusts probablyHandledAsynchronously
value.
So, this patch changes the behavior of only when:
- active IME is ibus.
- only when a password field or ime-mode:disabled field has focus.
- not in dead key sequence.
- and the key event is consumed by ibus but nothing happend.
This must be enough safe to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D18635
--HG--
extra : moz-landing-system : lando
Now, we believe that when `maybeHandledAsynchronously` is set to true,
ibus handles the event asynchronously in usual cases. However, the behavior
of ibus on password field is unclear. Currently, on Ubuntu 18.04,
Ubuntu 18.10 and Debian Cinnamon (9.6 / 3.2.7), ibus handles key events
asynchronously even in password fields even though I confirmed it was not
so at initial fix. So, it could be just my mistake, but we need to prepare
for both cases here for safer fix.
So, in the following patch, I need to add another variable for weaker
decision, and we treat `maybeHandledAsynchronously` stronger than its
nuance. Therefore, this patch renames it to `probablyHandledAsynchronously`.
Differential Revision: https://phabricator.services.mozilla.com/D18634
--HG--
extra : moz-landing-system : lando
When hardware acceleration is enabled, GLContextGLX::FindVisual() is used to choose visual. When widget does not request AlphaVisual, the FindVisual() always choose RGB(24bit) visual. It causes to loose alpha during readback.
Differential Revision: https://phabricator.services.mozilla.com/D18179
--HG--
extra : moz-landing-system : lando
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
Use only ':' separator instead of 'menu:' to place titlebar buttons as the menu may not be always present.
Differential Revision: https://phabricator.services.mozilla.com/D17480
--HG--
extra : moz-landing-system : lando
To support rounded corners of Gtk+ titlebar themes (Adwaita, Radiance..) in GNOME we need to use X shape mask
as fully transparent toplevel window causes various issues (like Bug 1516224).
We draw mShell as transparent and mContainer as non-transparent with shape mask applied. The shape mask
is generated only when titlebar rendering is enabled and it's generated from GtkHeaderBar Widget
to match the exact look.
We use existing mTransparencyBitmap for the shape mask where mTransparencyBitmapForTitlebar controls
whether it's a general shape mask or our specialised shape for titlebar only.
This is already enabled for GNOME environment by default. So there's a new preference
widget.default-hidden-titlebar added to easily disable it if any issue appears
during testing.
Differential Revision: https://phabricator.services.mozilla.com/D17283
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
Also add widget.allow-gtk-native-file-chooser preference value to force enable on all systems.
Differential Revision: https://phabricator.services.mozilla.com/D16184
--HG--
extra : moz-landing-system : lando
Some unusual keyboard layout may map a function key only with some
modifiers. For example, Hatchak keyboard layout maps Tab key to
"Digit3" key and Backspace key to Level3 Shift+"Digit3" key. So,
when Level3 Shift is active, the modifier state of the "Digit3" key
event shouldn't be ignored because computed keyCode value becomes
DOM_VK_TAB (9) rather than DOM_VK_BACK_SPACE (8).
This patch makes KeymapWrapper::ComputeDOMKeyCode() compute keyCode
value of non-printable key event with its modifier state first. If
it cannot map to a DOM keyCode value, then, it keeps ignoring the
modifier state for backward compatibility and making web apps be able
to identify the key as far as possible.
We haven't logged KeymapWrapper::HandleKeyPressEvent() nor
KeymapWrapper::HandleKeyReleaseEvent(). Therefore, this patch makes them
put their behavior into the log.
Additionally, KeymapWrapper::InitKeyEvent() does not log enough the result
of initialized WidgetkeyboardEvent. This patch makes it log more.
With those changes, we can get the log of:
- detail of dispatched keyboard events
- which key event didn't cause keyboard events
- which keyboard event was consumed
Note that the utility methods are copied from widget/windows. Perhaps,
we should create XP logging helper for keyboard/IME later.
Differential Revision: https://phabricator.services.mozilla.com/D15324
--HG--
extra : moz-landing-system : lando
Alex Gaynor
sotaro
Tarek Ziadé
Daniel Holbert
Martin Stransky
Dorel Luca
Mats Palmgren
Cosmin Sabou
Sylvestre Ledru
Emilio Cobos Álvarez
Kris Maglione
Csoregi Natalia
Masayuki Nakano
Tim Nguyen
Andreea Pavel
Dragana Damjanovic
Razvan Maries
Ehsan Akhgari
William G Hatch