Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
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
--HG--
extra : rebase_source : 5b956a6abd7d215b06ebcd8c56e34c038d012940
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
--HG--
extra : rebase_source : bf0680e33fd5a5b6c931b5260430fdd3fd995769
When we perform copy -> paste in one Firefox process on Wayland we're locked because Wayland clipboard paste
operation just reads data from filedescriptor and does not run main event loop.
A solution is to use Gtk+ shortcut here, when clipboard selection owner is the same as data receiver.
Gtk+ then does not go through X11/Wayland but calls clipboard data getter callback directly,
which we can use on Wayland because it also does not main event loop and the operation
stays synchronous.
MozReview-Commit-ID: G8myCBUSzxb
--HG--
extra : rebase_source : 34cb3095be4b2f00d19c589dc5f676b1b895eb15
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
--HG--
extra : rebase_source : 77c4ae490413057d8d9dadf9b155c86ddbbcb4b5
Also comment existing entries at nsWindow::GetCSDSupportLevel().
MozReview-Commit-ID: 1YzZhv7WrQj
--HG--
extra : rebase_source : c1dd1a3452e13e2479afee3c34d396757dae4cfd
Render titlebar button icons as a part of -moz-window-button-* appearence. It allows us to
theme the icons accordingly. We add a GtkImage widget to header bar buttons as Gtk+ does and
store icon pixel data there and render it at moz_gtk_header_bar_button_paint() as a part
of the buttons. It means that the toolbar buttons are not containers and
moz_gtk_get_widget_border() returns zero border for them.
Also implement GetToolbarButtonMetrics() per button.
MozReview-Commit-ID: gkAu3VmE3q
--HG--
extra : rebase_source : d1df34537901342969d1e33524b414a2786df541
Titlebar button on Gtk+ >= 3.20 can have defined its size as min-width and min-height
and can leave CSS styles border/padding empty. To render the button icon at center we need to
calculate button widget border from gap between icon and button.
This is done by GetToolbarButtonMetrics() which also stores final values to
ToolbarButtonGTKMetrics cache.
MozReview-Commit-ID: 5sMJATWHUNX
--HG--
extra : rebase_source : b0bda7c78106088a819b98c197cbb0cd099e47df
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.
MozReview-Commit-ID: 1dVYOe48tPJ
--HG--
extra : rebase_source : af804d3104da91be459b219b261949d84b4f7c26
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.
MozReview-Commit-ID: 5okD8vUu9UK
--HG--
extra : rebase_source : 39f3dec4acd434501860a8b716a42c45aadf3b61
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
--HG--
extra : rebase_source : db2f3ac03ae4ec9f9c1655cf682bff60a96dd3da
Firefox in Flatpak sandboxed environment does not get the list
of installed applications on the system because application should
know about the environment as little as possible. Introducing
nsFlatpakHandlerApp which forwards requests for opening downloaded files
to the system by utilizing gtk_show_uri fuction.
This changeset also removes nsIGIOMimeApp::Launch method from the interface
because it can be fully replaced with LaunchWithUri from nsIHandlerApp
interface.
The TMPDIR where files are downloaded when user choose to open them
needs to be accessible from sandbox and host. The default settings
TMPDIR=/tmp is accessible only to the sandbox.
To workaround for is to set TMPDIR environment variable to
$XDG_CACHE_HOME/tmp before executing Firefox.
MozReview-Commit-ID: CSBv0QcETpd
--HG--
extra : rebase_source : 8155c33fa9c402d2668bdfb07094ba6758fe6203
We don't add build-time dependency on Wayland libraries; that allows Wayland enabled Firefox
builds to run on systems without Wayland support.
We also can't dlsym() Wayland symbols directly from libwayland-client.so library as we miss
global data entries referenced by code at wayland-client.h then.
As a partial solution (for glibc systems only) we create dummy libwayland-client.so library
implementation and place it *after* Gtk+ 3.0 libraries at linking time.
It fixes build-time dependencies (we link against our libwayland-client.so library).
Run-time dependency is resolved by ld.so - when Gtk+ 3.0 libraries are linked with
system libwayland-client.so library, wayland symbols are pulled from there instead
from our dummy libwayland-client.so library.
When Gtk+ 3.0 is not linked with system libwayland-client.so it means we're running
on system without Wayland support. Our dummy libwayland-client.so implementation
is used (symbols are pulled run-time from there) and Firefox Wayland support is
disabled then.
MozReview-Commit-ID: IyaePwp4MxV
--HG--
extra : rebase_source : 852955d001657176e0bf69c099580be862d0b448
Martin Stransky
Masayuki Nakano
Jan Horak
Chris Peterson
Boris Zbarsky
Tooru Fujisawa
Jan Steffens
Gurzau Raul
Arthur Edelstein
decltype
Noemi Erli
Lee Salzman
Hiroyuki Ikezoe
Jonathan Watt