uim is an old IM which uses key snooper to listen to key events rather than
via filter key event API which should be called by applications. It's still
used by Debian 9.x, so, we still need to support this.
Unfortunately, we cannot detect if uim actually uses key snooper because it's
switch by build option of uim. Currently, Debian builds uim as using key
snooper. So, we should assume uim uses key snooper always. On the other
hand, somebody *might* use uim built as not using key snooper, so, let's
decide if uim uses key snooper with new pref,
"intl.ime.hack.uim.using_key_snooper", but its default should be true.
Note that ibus and Fcitx also have the mode to use key snooper (perhaps for
backward compatibility with uim). However, it's not enabled in default
settings and even if it's enabled, Firefox is in whitelist in the default
settings of them for stop using key snooper. Therefore, we don't need to
support key snooper mode for them unless we'll get some requests to
support their key snooping mode.
MozReview-Commit-ID: 6fTsfKrHzvo
CLAMP is unnecessary as the minimum acceptable value is 0, and
progressPercent is unsigned. CLAMP can trigger the following warning/error in some builds:
error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
For conforming UI Events spec, KeymapWrapper::InitKeyEvent() should initialize
mKeyCode and mKeyNameIndex with NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process if
given keyboard event has already been handled by IME.
For making it know if given keyboard event has been handled by IME, this patch
adds additional bool argument to it and its callers.
Note that this patch changes keyCode value and key value of "keydown" event if
it's fired before "compositionstart" since Chromium does so on Linux.
MozReview-Commit-ID: FC3tfyeeopU
This adds support for download progress reporting via the XApp
method currently used in the Cinnamon desktop, by establishing a new
X11 window property to be supported/read by the window manager.
See https://github.com/linuxmint/xapps/blob/master/libxapp/xapp-gtk-window.c,
as well as https://github.com/linuxmint/muffin/commit/39045da0ea06f
for more details.
The property-setting code lives in nsWindow - it's a small and stable
enough chunk that it made more sense to do this than actually depend on
another external library. As nsWindow is already using x11 calls, this
seemed the safest place for it, without affecting the build.
The TaskbarProgress instance is initialized via the DownloadsTaskbar
js module, and is handed a pointer to the current main window to call
SetProgress on. Most of the javascript side of this is in line with
how the other platforms are handled.
Without a supporting window manager/desktop environment (currently just
Cinnamon/Muffin 3.6,) the simplest way to observe working behavior is
by calling 'xprop -spy' on the browser window being testing and watching
for updates during a download.
The titlebar rendering on Linux/Gtk+ is recently enabled at Beta59 but with many bugs fixed at Nightly.
Let's disable this feature for Beta / Release 59 and ship it at Firefox 60 where majority of the issues are fixed.
MozReview-Commit-ID: FQL7tNhcvUG
The DispatchEvent can manipulate with the mRefPoint we're later using to check if the
double click happened on the titlebar. We need to save it for later check to avoid
unwanted restore/maximize event when mouse event occurs near top border of any widget.
Also don't handle doubleclick on titlebar when CSD is not enabled.
MozReview-Commit-ID: KjxM1EsT4Lg
We need to use scaling factor of the monitor on which application is actually positioned.
Previously we used ScreenHelperGTK::GetGTKMonitorScaleFactor() which use the first monitor.
This does not work on hidpi+normal dpi monitors setup.
The GetSystemFontInfo() cannot return scaled value of the font by default monitor
scale factor. We need to scale it in nsLookAndFeel::GetFontImpl
by aDevPixPerCSSPixel like implementation for Windows does.
We also need to check layout.css.devPixelsPerPx because we cannot
scale per monitor when this preference is set to positive number.
MozReview-Commit-ID: AwT2NvkEqvz
The drag area should process doubleclick event as request for restore/maximize
because otherwise there's no other option to do the action when Firefox
is drawing window decoration. We follow similar path as mac which handles this
in mouseUp event.
MozReview-Commit-ID: KpCnHTdteLr
We need to use scaling factor of the monitor on which application is actually positioned.
Previously we used ScreenHelperGTK::GetGTKMonitorScaleFactor() which use the first monitor.
This does not work on hidpi+normal dpi monitors setup.
The GetSystemFontInfo() cannot return scaled value of the font by default monitor
scale factor. We need to scale it in nsLookAndFeel::GetFontImpl
by aDevPixPerCSSPixel like implementation for Windows does.
We also need to check layout.css.devPixelsPerPx because we cannot
scale per monitor when this preference is set to positive number.
MozReview-Commit-ID: AwT2NvkEqvz
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
Some compositors such as GNOME mutter use heuristics to unredirect fullscreen
windows in an effort to reduce output latency. This works fine for applications
that take the proper steps to ensure all framebuffer updates happen in the
vblank interval. Since this is not currently the case for Firefox, bypassing
the compositor will lead to frame tearing.
Set _NET_WM_BYPASS_COMPOSITOR to 2 to opt out of fullscreen unredirection.
MozReview-Commit-ID: 1xW2VAnbiJw
Emulate what gtk+/gtkwindow.c gtk_window_present_with_time() does - use gdk_x11_display_get_user_time() on X11
and gtk_get_current_event_time() on Wayland to get event timestamp.
MozReview-Commit-ID: GEU6ZrQxq6v
nsWindow needs configuration change when rendering on Wayland:
- Always draw to mContainer on Wayland as we can't create custom subsurface for
mShell GdkWindow and listen events on mContainer then.
- GTK_WINDOW_TOPLEVEL can't be positioned on Wayland so create popup windows
as GTK_WINDOW_POPUP to control window position on Wayland.
- Create ePopupTypeMenu GdkWindow as GDK_WINDOW_TYPE_HINT_UTILITY instead of
GDK_WINDOW_TYPE_HINT_POPUP_MENU to create it as subsurface (Bug 1423598).
- Don't do pointer grab on Wayland (see Bug 1377084 for reference).
MozReview-Commit-ID: 6InzhTONtrD
- Rename X11CompositorWidget to GtkCompositorWidget to handle both X11 and Wayland backends.
- Rename X11CompositorWidgetInitData to GtkCompositorWidgetInitData
- Implement Wayland support at WindowSurfaceProvider, WindowSurfaceProvider::CreateWindowSurface()
is able to create WindowSurfaceWayland.
- Initialize Wayland surface provider at nsWindow::Create()
MozReview-Commit-ID: 1WvR9nWHa3L
To have any effect we need to call gdk_window_set_decorations() on top-level GdkWindow only.
When rendering to mContainer the mGdkWindow belongs to mContainer so we need to get the window
from mShell explicitly.
MozReview-Commit-ID: KLKlVJbgg3
When drawing to mContainer we still need to honor mShell as top-level window.
It means we have to listen property-notify-event there (as it's window specific),
get _NET_FRAME_EXTENTS here and use at nsWindow::SetWindowClass().
MozReview-Commit-ID: HYbNS0Lfyjy
Bug 1421974 introduced new mechanism to hide system titlebar by enabling client-side decorations for main Firefox window. It also causes a regression when the CSD window setup is enabled when system titlebar is hidden by window manager.
This patch fixes that and enables the CSD window setup only for case when it's actualy used.
MozReview-Commit-ID: AqfHR2bGr3K
Bug 1421974 introduced new mechanism to hide system titlebar by enabling client-side decorations for main Firefox window. It also causes a regression when the CSD window setup is enabled when system titlebar is hidden by window manager.
This patch fixes that and enables the CSD window setup only for case when it's actualy used.
MozReview-Commit-ID: 6OzoPyxlhCp
