On some Linux environment, GTK_IM_MODULE env may be "xim". Then, actual
IM is specified with XMODIFIERS env with "@im=". Therefore, if active IM
context ID is xim, IMContextWrapper::Init() needs to look for actual IM name
in XMODIFIERS.
MozReview-Commit-ID: 1aGjBkF4AQn
--HG--
extra : rebase_source : 8c50baa517c61ec2d872c036abc989b4a07e8e36
We'll start to dispatch keydown event and keyup event even during composition.
So, for testing those events won't break our UI, we should make
EventUtils.synhtesizeComposition() and EventUtils.synthesizeCompositionChange()
dispatch keydown event and keyup event even if callers don't specify keyboard
event explicitly.
Typically, "keydown" event is marked as "processed by IME", i.e., keyCode
value is set to DOM_VK_PROCESSKEY and key is set to "Process", with our
widget which handles native IME and key input. On the other hand, "keyup"
is NOT marked as so.
Therefore, this patch makes TextInputProcessor emulates this behavior without
any new special flags. And for making possible to emulate special cases,
this patch adds two flags to nsITextInputProcessor. One is
KEY_DONT_MARK_KEYDOWN_AS_PROCESSED. The other is KEY_MARK_KEYUP_AS_PROCESSED.
Unfortunately, those flags have opposite meaning but this must be better than
making necessary to one flag for emulating usual keydown/keyup events.
Finally, this makes some tests specify better keyboard information to
synthesizeComposition() and synthesizeCompositionChange() to emulate
actual keyboard events during composition.
MozReview-Commit-ID: ItYaXILkNQE
--HG--
extra : rebase_source : e50cc77c1efbc12686d7ea334d41926c7392b30d
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
This remotes the APZInputBridge interface over the PAPZInputBridge
protocol in the case of the GPU process, and makes the GPU process'
main thread act as the APZ controller thread in that process. If
there is no GPU process we continue as before and the APZInputBridge
interface implementation is the concrete APZCTreeManager instance
in the UI process.
The main changes in this patch are moving all the code associated with
these messages out of APZCTreeManager{Parent,Child} and into
APZInputBridge{Parent,Child}. APZCTreeManagerChild now returns an
APZInputBridgeChild instance via InputBridge(), instead of returning
itself. The SetControllerThread call in the GPU process is also updated.
MozReview-Commit-ID: M4AaIW1Q0h
--HG--
extra : rebase_source : e5a8f14e23be34229fe80a47f6789d19b19e0a9f
This separates the methods that are used to deliver input events
synchronously over IPDL to the compositor; this interface will be
remoted over a new APZInputBridge IPDL protocol in future patches.
MozReview-Commit-ID: 1f3V9SUKlfW
--HG--
rename : gfx/layers/apz/public/IAPZCTreeManager.cpp => gfx/layers/apz/src/APZInputBridge.cpp
extra : rebase_source : 523abce7949baf9e3b7803a61632eb4434a6967f
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
Currently the ZoomToRect function is only ever called on Android, on the
UI process main thread, which is neither the controller nor the sampler
thread. Instead of allowing "random" threads to run inside APZ, we
ensure that callers run it on the controller thread.
MozReview-Commit-ID: 64LkHaFLIOl
--HG--
extra : rebase_source : 61f397c0e18f83c68c228879692c9d4767b25675
Since we can have multiple browser windows on multiple different
displays with different DPIs, it doesn't make sense to have a single
static DPI value shared across all APZCTreeManagers. Instead, each
APZCTM should store its own DPI value for the display the window is on.
Since the DPI is only ever read from the controller thread, we can make
it bound to that thread, and update the setter code to also set it on
that thread.
As with the previous patch, the change in APZCTreeManagerParent is a
no-op but allows making some other thread in the GPU process the controller
thread. And the change in nsBaseWidget is a no-op everywhere except
Android.
MozReview-Commit-ID: CB23MxGISeL
--HG--
extra : rebase_source : b3358202ec5fa27422c56ae1b0b2237dbc8e489b
- The change in APZCTreeManagerParent is functionally a no-op because it
only ever runs in the GPU process on the controller thread. But it
allows moving the controller thread to some other thread.
- The change in nsBaseWidget is a no-op for desktop platforms, because
in the UI process the main thread is the controller thread. But on
Android it moves the call from the main thread to the Java UI thread.
MozReview-Commit-ID: LVVZLFxSuyj
--HG--
extra : rebase_source : 89e9c8824c31867ad92152ff9b496744a6afdd83
IIIMF is really old IME framework. In these days, it's not used as default IM
module of any major distributions. However, ATOK X which is old proprietary
IME requires IIIMF and it's still used by some Japanese IME users. Therefore,
we need to take back the hack to prevent crash caused by IIIMF.
We did increment refcount of GtkIMContextIIIM class to prevent IIIM module
from being unloaded. However, it was not ported when we changed default
toolkit from GTK2 to GTK3. So, this is doing the porting.
Unfortunately, the instance of GtkIMContextIIIM is wrapped by opacity struct.
So, it's not safe to access the pointer with declaring a mimic struct.
Therefore, we should directly get GType from the name with calling
g_type_from_name("GtkIMContextIIIM") instead of using G_TYPE_FROM_INSTANCE()
and g_type_name().
MozReview-Commit-ID: GCZaSUtPiS9
--HG--
extra : rebase_source : 3b959023bf47fa26393fc04e722c9da79a50991d
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
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
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]
--HG--
extra : rebase_source : 0dfcf4286a74adac03f7498f1d35fee069528826
TSF doesn't send WM_KEYDOWN nor WM_KEYUP to us while it handles a key message
with ITfKeystrokeMgr::KeyDown() or ITfKeystrokeMgr::KeyUp(). Therefore,
TSFTextStore needs to store handling key event message during calling
those methods and if it does something, we need to dispatch eKeyDown event
or eKeyUp event before dispatching any events.
However, we shouldn't dispatch WidgetKeyboardEvent during a document lock
because TSF/TIP do not assume that document is broken during a document lock.
Therefore, TSFTextStore needs to put it as a pending action into the queue.
So, this patch wraps this with
TSFTextStore::MaybeDispatchKeyboardEventAsProcessedByIME(). It checks if
there is a document lock when it's called. If it's locked (and not yet
dispatched keyboard event for the handling key message), it adds pending
action to dispatch keyboard event later. Otherwise, (and not yet dispatched
one), it dispatches keyboard event directly.
MozReview-Commit-ID: 9rJTJykVLyf
--HG--
extra : rebase_source : 4f8297b2b9fe2905e4cd1f64086fcdbe3d0b6035
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we need additional
pref to make the new behavior behind pref.
Therefore, this patch adds a new pref,
"intl.ime.hack.on_any_apps.fire_key_events_for_composition", to override
existing "intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition"
pref. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents to
NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : c76b613ea186458ebdf0d67f4bc984e8ac5f1041
ibus and fcitx usually post key event to other IME process, then, if it causes
some signals to updating composition string, they may not send the posted
key event to us again. Then, IMContextWrapper dispatches neither eKeyDown nor
eKeyUp event since mProcessingKeyEvent becomes non-nullptr only while
OnKeyEvent() is called. So, IMContextWrapper need to store key event if
OnKeyEvent() assumes that given key event is posted to different process.
Then, if IMContextWrapper receives some signals, it should dispatch eKeyDown
and eKeyUp event with stored key event.
Note that we cannot compare the pointer of first event and following event
directly even though usually both events are same address as far as I checked
because according to the source code of ibus, fcitx and GDK, they use
gdk_event_copy() to keep storing original event. According to the document of
the API, it might just increment refcount. However, the actual implementation
of the API always creates another instance and return it. So, it might be
used same address by arena allocation or something accidentally. Anyway,
we shouldn't compare them. Instead, we need to compare each information of
two key events. Unfortunately, we also cannot compare them simply. Both
ibus and fcitx set unused bits of GdkEventKey::state to true when they send
back the event to us. Therefore, we should compare some of or all of the
members by ourselves. I think that matching time must be enough in most
cases since its value of native key events are properly set. However, for
safer code, this patch also checks type, keyval and part of state.
MozReview-Commit-ID: FZSwN61v0Sd
--HG--
extra : rebase_source : e57a654392f476f5ec52d82bdd238eed2eb91e83
ibus and fcitx have asynchronous key event handling mode and it's enabled in
default settings. That is, when they receive a key event from application via
a call of gtk_im_context_filter_keypress(), they may post the key event
information to other IME process, then does nothing but store the copy of the
event with gdk_event_copy() and returns true for the result of
gtk_im_context_filter_keypress(). When the other IME process handles the
event, returns the result to them in our process. Then, they send the stored
key event to us again. Finally, they actually handles the event in our process
actually.
Therefore, we may receive every key event twice. So, this causes dispatching
eKeyDown event and eKeyUp event twice. Preceding key event is always marked
as "processed by IME" since gtk_im_context_filter_keypress() returns true
temporarily and following key event is dispatched as expected. So, we need
to ignore the first event only when gtk_im_context_filter_keypress() returns
true but the event is posted to different process.
Unfortunately, we cannot know if the key event is actually posted to different
process directly. However, we can know if active IM is ibus, fcitx or another
one and if ibus or fcitx is in asynchronous key handling mode.
The former information is provided by gtk_im_multicontext_get_context_id().
It returns a string which is set to the IM multicontext instance by creator.
We'll get "ibus" if IM is ibus, get "fcitx" if IM is fcitx.
The latter information is not provided. However, they consider the mode from
env value. ibus checks IBUS_ENABLE_SYNC_MODE. fcitx checks both
IBUS_ENABLE_SYNC_MODE and FCITX_ENABLE_SYNC_MODE.
Additionally, we can know if received key event has already been posted to
other IME process. They use undefined bit of GdkEventKey::state to store
if the key event has already been posted (1 << 25, they called "ignored" flag).
Although their approach is really hacky but we can refer the information at
least for now.
Finally, when we guess a key event is posted to other IME process, let's
IMContextWrapper::OnKeyEvent() not dispatch eKeyDown nor eKeyUp event.
Note that if it's handled synchronously as unexpected, it may causes
dispatching one or more composition events and/or delete content event.
So, in such case, we dispatch a keyboard event for processing key event
anyway. There is only once case we'll fail to dispatch keyboard event.
If we receive signals to dispatch composition events or delete content
command event when IM receives the result from other IME process but
it doesn't send the key event to us. This will be fixed by the following
patch.
MozReview-Commit-ID: 94PrlnmQ3uJ
--HG--
extra : rebase_source : fc31b0293ff0f0688dd39b0094fdf8f98b6c64d3
First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event
before sending IME. This is different behavior from Gecko on the other
platforms and it means TextInputHandler does not know if the eKeyDown event
will be handled by IME. Therefore, we need to make TextInputHandler dispatch
an eKeyDown event dispatch when it needs to dispatch another event. Therefore,
this patch makes TextInputHandler not dispatch an eKeyDown even from
its HandleKeyDown() unless it's already has composition (because if it's
already had composition, any eKeyDown event except modifier keys should be
marked as "processed by IME" for compatibility with the other browsers).
For dispatching eKeyDown event only once for a native keydown event,
this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent()
to check whether eKeyDown event has already been dispatched for the event
and if it's not so, dispatches eKeyDown event.
Note that on macOS, dead keys are implemented as IME. However, we need to
treat dead keys as is. Therefore, if current keydown event is a dead keydown
event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching
eKeyDown event and its following eKeyDown event as "processed by IME".
MozReview-Commit-ID: 7epk8wdAznd
--HG--
extra : rebase_source : 0ed30ff3e108170fd96eabe626e0530473f2f3b1
Currently, IMContextWrapper doesn't dispatch eKeyDown event and eKeyUp event
if it's handled by IME. However, for conforming to UI Events, it should
not eat given keyboard events completely.
This patch makes IMContextWrapper dispatches eKeyDown event or eKeyUp event
before dispatching first event of composition events or content command
event.
MozReview-Commit-ID: H2jHpViTH5Q
--HG--
extra : rebase_source : a1f4127ba87e03e1ff97690f97fb7bf64b4d4818
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
--HG--
extra : rebase_source : b7e2a70db1fbb4ca7d20379fd1c14f7dc38e656d
Some themes (Adwaita for instance) draws bold dark line at
titlebar bottom. It does not fit well with Firefox tabbar UI so
draw themed titlebar with some extent to make the titlebar
bottom part invisible (it's clipped by cairo).
MozReview-Commit-ID: 3rs4UzFJdPa
--HG--
extra : rebase_source : ca9270f549a3106711afac8ee0c7a30839ab2bf3
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
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
ibus and fcitx usually post key event to other IME process, then, if it causes
some signals to updating composition string, they may not send the posted
key event to us again. Then, IMContextWrapper dispatches neither eKeyDown nor
eKeyUp event since mProcessingKeyEvent becomes non-nullptr only while
OnKeyEvent() is called. So, IMContextWrapper need to store key event if
OnKeyEvent() assumes that given key event is posted to different process.
Then, if IMContextWrapper receives some signals, it should dispatch eKeyDown
and eKeyUp event with stored key event.
Note that we cannot compare the pointer of first event and following event
directly even though usually both events are same address as far as I checked
because according to the source code of ibus, fcitx and GDK, they use
gdk_event_copy() to keep storing original event. According to the document of
the API, it might just increment refcount. However, the actual implementation
of the API always creates another instance and return it. So, it might be
used same address by arena allocation or something accidentally. Anyway,
we shouldn't compare them. Instead, we need to compare each information of
two key events. Unfortunately, we also cannot compare them simply. Both
ibus and fcitx set unused bits of GdkEventKey::state to true when they send
back the event to us. Therefore, we should compare some of or all of the
members by ourselves. I think that matching time must be enough in most
cases since its value of native key events are properly set. However, for
safer code, this patch also checks type, keyval and part of state.
MozReview-Commit-ID: FZSwN61v0Sd
--HG--
extra : rebase_source : e54284c27a171f899a6cf87a65935669e2d57021
ibus and fcitx have asynchronous key event handling mode and it's enabled in
default settings. That is, when they receive a key event from application via
a call of gtk_im_context_filter_keypress(), they may post the key event
information to other IME process, then does nothing but store the copy of the
event with gdk_event_copy() and returns true for the result of
gtk_im_context_filter_keypress(). When the other IME process handles the
event, returns the result to them in our process. Then, they send the stored
key event to us again. Finally, they actually handles the event in our process
actually.
Therefore, we may receive every key event twice. So, this causes dispatching
eKeyDown event and eKeyUp event twice. Preceding key event is always marked
as "processed by IME" since gtk_im_context_filter_keypress() returns true
temporarily and following key event is dispatched as expected. So, we need
to ignore the first event only when gtk_im_context_filter_keypress() returns
true but the event is posted to different process.
Unfortunately, we cannot know if the key event is actually posted to different
process directly. However, we can know if active IM is ibus, fcitx or another
one and if ibus or fcitx is in asynchronous key handling mode.
The former information is provided by gtk_im_multicontext_get_context_id().
It returns a string which is set to the IM multicontext instance by creator.
We'll get "ibus" if IM is ibus, get "fcitx" if IM is fcitx.
The latter information is not provided. However, they consider the mode from
env value. ibus checks IBUS_ENABLE_SYNC_MODE. fcitx checks both
IBUS_ENABLE_SYNC_MODE and FCITX_ENABLE_SYNC_MODE.
Additionally, we can know if received key event has already been posted to
other IME process. They use undefined bit of GdkEventKey::state to store
if the key event has already been posted (1 << 25, they called "ignored" flag).
Although their approach is really hacky but we can refer the information at
least for now.
Finally, when we guess a key event is posted to other IME process, let's
IMContextWrapper::OnKeyEvent() not dispatch eKeyDown nor eKeyUp event.
Note that if it's handled synchronously as unexpected, it may causes
dispatching one or more composition events and/or delete content event.
So, in such case, we dispatch a keyboard event for processing key event
anyway. There is only once case we'll fail to dispatch keyboard event.
If we receive signals to dispatch composition events or delete content
command event when IM receives the result from other IME process but
it doesn't send the key event to us. This will be fixed by the following
patch.
MozReview-Commit-ID: 94PrlnmQ3uJ
--HG--
extra : rebase_source : 0bb58ed432bacef8ad13264babd2b21fe950b71c
On Linux, dead key is implemented with "table-based input methods" which are
available even on GtkIMContextSimple (i.e., available even in password fields).
Therefore, IMContextWrapper handles dead key sequence as usual composition of
IME. However, on the other platforms, we dispatch "Dead" eKeyDown and eKeyUp
events for dead key.
We started to mark keyboard events which are handled by IME as "processed by
IME" since bug 1343451, i.e., we started to set mKeyNameIndex to
KEY_NAME_INDEX_Process. However, we should keep previous behavior, i.e., keep
setting it to KEY_NAME_INDEX_Dead. Fortunately, GDK's key event tells us
whether the keyboard event is a dead key event with keysym. So, we can detect
if we're in a dead key sequence simply.
MozReview-Commit-ID: Dv336WptfXN
--HG--
extra : rebase_source : e8a7b5a7eb7c57e1e45de20ebebd56f88457cfc6
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we cannot test
this behind pref ("dom.keyboardevent.dispatch_during_composition") even in
Nightly.
Therefore, this patch enables new behavior only when it's Nightly build or
early Beta. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents
to NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : fade31954eaa1be8b7592977095ba8aebdd75104
First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event
before sending IME. This is different behavior from Gecko on the other
platforms and it means TextInputHandler does not know if the eKeyDown event
will be handled by IME. Therefore, we need to make TextInputHandler dispatch
an eKeyDown event dispatch when it needs to dispatch another event. Therefore,
this patch makes TextInputHandler not dispatch an eKeyDown even from
its HandleKeyDown() unless it's already has composition (because if it's
already had composition, any eKeyDown event except modifier keys should be
marked as "processed by IME" for compatibility with the other browsers).
For dispatching eKeyDown event only once for a native keydown event,
this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent()
to check whether eKeyDown event has already been dispatched for the event
and if it's not so, dispatches eKeyDown event.
Note that on macOS, dead keys are implemented as IME. However, we need to
treat dead keys as is. Therefore, if current keydown event is a dead keydown
event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching
eKeyDown event and its following eKeyDown event as "processed by IME".
MozReview-Commit-ID: 7epk8wdAznd
--HG--
extra : rebase_source : 4f4e23a8cc5005d8f0da3c35910eba30f8777e6b
Currently, IMContextWrapper doesn't dispatch eKeyDown event and eKeyUp event
if it's handled by IME. However, for conforming to UI Events, it should
not eat given keyboard events completely.
This patch makes IMContextWrapper dispatches eKeyDown event or eKeyUp event
before dispatching first event of composition events or content command
event.
MozReview-Commit-ID: H2jHpViTH5Q
--HG--
extra : rebase_source : 4129620126a34e27af1503e7c4652bb09c7e9bb6
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
--HG--
extra : rebase_source : 9c88967b8e2a5539023deb1277ae8704418dfd0d
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.
--HG--
extra : rebase_source : 0606f6c87116204ec290c19276072d0c1c35691e
When we reset the old native queue when transferring to another session,
perform the reset right after the transfer() call, instead of in
onTransfer(), which is too late for clearing stale pending calls.
Then, after transferring to a new queue, let Gecko call Window.onReady
to set the new queue's state if needed. That way the Java queue state is
consistent with the Gecko state.
MozReview-Commit-ID: CUXGrhR4FCD
--HG--
extra : rebase_source : a196361f1db1304c178a3471082d586dddfe2a32
In an "attach > detach > attach" sequence, detach will post a call to
disposeNative, so the sequence looks like "attach > detach > attach >
disposeNative". In that case, disposeNative will cancel attach. This
patch makes us ignore disposeNative in that case, so the second attach
works as intended.
MozReview-Commit-ID: Kr55PZcsPg1
--HG--
extra : rebase_source : 0a4480149f5a13a6759bd7280964456b12d57c9b
Ensure that we unregister and re-register all listeners on
closeWindow, so that the listeners are ready for any new windows that
are subsequently opened.
MozReview-Commit-ID: EKzCRS10odN
--HG--
extra : rebase_source : 80615ef28839d9e76ecc47881d7b47b59ddea563
In the past there were cases where treating double click behavior differently from draggability
was necessary, but there don't seem to exist such cases any more. For example, we don't have any
windows with bottom bars / draggable status bars any more.
This change simplifies the code and frees the frontend from having to use special -moz-appearance
values to indicate titlebary parts of the window.
MozReview-Commit-ID: IRe3FPU2EaT
--HG--
extra : rebase_source : e52b79d4cbc15b3c3a70b8411c5917309a7f78d8
For confirming to UI Events spec, we should dispatch "keydown" event and
"keyup" event even during in composition.
This patch makes only Nightly and early Beta start to dispatch those events
during a composition.
MozReview-Commit-ID: 8md7NtSdurJ
--HG--
extra : rebase_source : 2527089ee2844ee6a816ee3afae461275c61c409
Following the naming scheme "SessionFoo" for GeckoSession sub-objects,
and "getFoo()" for getters of GeckoSession sub-objects, rename
TextInputController to SessionTextInput and getTextInputController() to
getTextInput().
MozReview-Commit-ID: 6GtgCjCLKhg
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/geckoview/TextInputController.java => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/SessionTextInput.java
extra : rebase_source : 6f20fd9a1853befc6e8aa98714f7e4733b1ee46f
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
mCompositorVsyncDispatcher is created and destroyed on main thread. But it is
accessed from Compositor thread or VSyncBridge thread. To avoid race condition
between main thread and Compositor thread/VSyncBridge thread,
mCompositorVsyncDispatcher needs to be protected by lock.
Mostly just convert nsInt{Rect,Region} to LayoutDeviceInt{Rect,Region}.
One exception is to change the parameter of nsWindow::OnResize from
nsIntRect to LayoutDeviceIntSize, because it really only needs that.
MozReview-Commit-ID: 963Mzd5Wed6
--HG--
extra : rebase_source : efae039d26feb98a3591a7cd46c30ce4f052d70b
I accidentally broke the ability to retrieve a big string from the
clipboard, and there was no test that failed. So this provides a new
test that does the following:
1. Store a big string in a nsTransferable.
2. Copy it to the clipboard.
3. Create a new nsTransferable, initialize with small data.
4. Populate the nsTransferable with (big) data from the clipboard.
5. Populate the nsTransferable with small data.
After each step, the test checks whether the transferable holds the
expected data and length, and (on non-Windows) checks that the big
data is backed by a file, and small data is not.
MozReview-Commit-ID: 9yuXZxVqD6R
--HG--
extra : rebase_source : 6cec638c59e8ce5a18adbb642779c1dcd457cc5b
DataStruct cannot safely be copied if its mCacheFD member is set.
Currently there is no code for this case, but to avoid problems later,
mark the copy and assignment constructors private and delete them.
A move-constructor was added to compensate for the deleted copy
constructor. nsTransferable::AddDataFlavor uses this new constructor
instead of the previous implicit default copy constructor.
MozReview-Commit-ID: 3N5xjFXOUKB
--HG--
extra : rebase_source : dc609f20c7048b3630fa99fe2deef3f5be155334
- Count open file descriptors instead of testing the existence of a file
(because the clipboard is now only reachable through file descriptors,
and not through a file path).
- Use a fixed string instead of a random string. The previous way of
generating a string was non-deterministic, and there was a very small
chance that the generated string was not large enough to trigger the
cache-to-disk-mode.
- Use "text/unicode" instead of "text/plain", because JavaScript strings
use two bytes, not one bytes each.
- The cache file is already created when the Transferable is created, so
check the cache file after assigning data to the nsITransferable, but
before copying it to the clipboard.
MozReview-Commit-ID: KOkYOm280Oh
--HG--
extra : rebase_source : 3515ff55a316720b87f2473a1450e5d8304728e8
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 01c8d16f7d31977eda6ca061e7889cedbf6940c2
Ensure that only DataStruct::mData + mDataLen, XOR
DataStruct::mCacheFD is used.
(Previously it was possible that all of these members were populated,
which is a waste of memory.)
The effect of this change is visible when SetTransferData is called
multiple times with the same flavor, but with one below the threshold
for storing in-memory, and the other above (=store in a file).
MozReview-Commit-ID: 4UlkKAYsjf
--HG--
extra : rebase_source : 75398f84f039bdf2ff0195342f3db8efbdce6d3d
The cache file is never directly exposed to consumers of DataStruct,
so it does not make sense to keep the clipboardcache file around
forever.
The only change in this commit is to switch from using a filename to
using a file descriptor. In the destructor, the FD is explicitly closed
(which releases the file data). nsAnonymousTemporaryFile takes care
of removing the file when the destructor is not called (e.g. crashes).
Previously, the clipboard cache was stored in a file called:
TmpD/clipboardcache-N
As of this commit, the clipboard cache is stored at:
TmpD/mozilla-temp-randomN (macOS and Linux)
TmpD/mozilla-temp-files/mozilla-temp-randomN (Windows)
(see xpcom/io/nsAnonymousTemporaryFile.{h,cpp} for more details)
To verify that these files are really gone:
1. Create a document with 500k+ characters, open it in Firefox.
2. Copy its content - this will trigger the clipboard cache.
3. Look for the open file descriptor of the deleted file:
( macOS and Linux: )
lsof +L1 | grep mozilla-temp
4. Copy anything (under the 500k threshold), or quit/kill Firefox.
5. Repeat step 3 and observe that the number of file descriptors
has decreased.
MozReview-Commit-ID: 85GlKQrNUl5
--HG--
extra : rebase_source : 6937143639d6a6280ffe8b53b4c2fa4b1e7ef55d
We have stopped dispatching "keypress" events for non-printable keys
and key combinations for conforming to UI Events and following the
other browsers.
However, this change hits a serious bugs of Google Docs, Google
Spreadsheets and Gmail. Until they will fix their bugs, we should
take back the traditional behavior for keeping Nightly usable for
any Nightly testers.
MozReview-Commit-ID: 9CyEbsFit1S
--HG--
extra : rebase_source : 837288b1fb53121badff4e65094a87cebfe3cfee
Some themes (Ambiance for instance) uses first-child/last-child css selectors
to style titlebar buttons. Ubuntu Ambiance theme places titlebar buttons closer
by negative margin applied to them.
We put titlebar buttons to GtkBox as well as Gtk+ does and also keep
the button order here to match first-child/last-child selectors. It also means
we must have maximize/restore as one button to keep the correct order.
MozReview-Commit-ID: 9mqljOa4Vu7
--HG--
extra : rebase_source : 9c31a2073d1bb247ce9d0240333143661b8ae4b8
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
--HG--
extra : rebase_source : 03a495ebc81b5ae5b4093406bd40daf83251343a
This a remaining issue of bug 1435180. We need to skip keypress event check of
non-printable key operation in the test.
MozReview-Commit-ID: InobZCbrzWL
--HG--
extra : rebase_source : 9f17cd04500f4ef31c3674087188ec6ee157173b
UI Events declares that keypress event should be fired only when the keydown
sequence produces some characters. For conforming to UI Events and
compatibility with the other browsers, we should stop dispatching keypress
events for non-printable keys.
For getting regression reports, we should enable this new behavior only
on Nightly and early Beta.
MozReview-Commit-ID: 5IIL9huejXH
--HG--
extra : rebase_source : 0abdbe84a50d6fd1b4d52521b92e7513483b197c
https://bugzilla.mozilla.org/show_bug.cgi?id=1418749
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.
--HG--
extra : rebase_source : 92cbe495ce097b080a9f94ec5312169da9a8648d
We still get occasional messages for the internal OLE Main Thread window.
Also, the PeekMessage call allows internal windows messages to be processed for
things like GDI.
GtkHeaderBar has property "spacing" which defines space between buttons at titlebar.
Get this property and apply as margin to titlebar buttons when there's more than one.
Also cache this value for furter use at titlebar metrics cache.
MozReview-Commit-ID: J7qAIWEnK4Y
--HG--
extra : rebase_source : 73f0f605444cf4e4ada3da335ff003e9df05c9c4
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
--HG--
extra : rebase_source : b880e4d89ebe3546b7ef70e3d94926a628f98598
A lot of "WARNING: Invalid monitor scale: -1" appering for the puppet widget since
fix for bug 1439881 landed. We don't need to print the warning, fallback to 1 is
sufficient enough.
MozReview-Commit-ID: 73BGc8neUmu
--HG--
extra : rebase_source : 74b2a818a29514095b5c56b05966cff5e4e9ba60
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
This gtest assumed the current working directory ($OBJDIR/_tests/gtest/) was in the DLL LoadLibrary path. That is no longer true with this bug's patches, so the gtest must specify the absolute path to the PDFium DLL to load it.
MozReview-Commit-ID: 5TXj6A9Tb9w
--HG--
extra : rebase_source : b097ae0c3430767e9ff16632ee96fd8739a902bf
extra : histedit_source : 1f13fa04c29039f8aeae05028d0a20ede5ee794b
Because of rounding errors there's a change that returned monitor scale
is 0. That would lead to SIGFPE because it's later used in division.
MozReview-Commit-ID: 4d7nHaBm4XG
--HG--
extra : rebase_source : d7fb5c64698d1e99afc223d401b30e0eb168fdb4
Windows default behavior will trigger the System menu bar when F10 is released.
Among other things, this causes the System menu bar to appear when a web page overrides the contextmenu event.
We *never* want this default behavior, so eat this key (never pass it to Windows).
MozReview-Commit-ID: 4fWOuj4mWvW
--HG--
extra : rebase_source : 45d38ba19b2f23aca74a60819c7d93af2ffa167d
Although we haven't any bug reports caused by this, this is a really old bug.
When we implement TSFTextStore, we decided to use queue of dispatching
events and flush it when document lock is unlocked. When we implement the
queue, we got this regression.
When TSFTextStore::SetText() is called with different range from current
selection range, TSFTextStore::SetSelectionInternal() add
PendingAction::SET_SELECTION into the queue first for replacing existing
text or inserting text into different position if there is no composition.
Then, TSFTextStore::InsertTextAtSelectionInternal() inserts text at the new
selection range.
When TSFTextStore::FlushPendingActions() is called after that, eSetSelection
should be dispatched and then, new text is inserted wit a set of composition
events. However, we forgot to dispatch creating eSetSelection event.
So, this patch just dispatches the event.
MozReview-Commit-ID: Hw8FTB1R5kR
--HG--
extra : rebase_source : 8a119f1f48b167d9423fc89ce0efc722313c3732
Olli Pettay
Emilio Cobos Álvarez
sotaro
Florian Quèze
Boris Zbarsky
arthur.iakab
Miko Mynttinen
Noemi Erli
Sylvestre Ledru
Csoregi Natalia
shindli
Masayuki Nakano
Andreea Pavel
Bogdan Tara
Jeff Muizelaar
James Willcox
Kartikaya Gupta
Eitan Isaacson
Coroiu Cristina
Adrian Wielgosik
Markus Stange
Xidorn Quan
Michael Webster
Gurzau Raul
Hector Zhao
Martin Stransky
Dorel Luca
Margareta Eliza Balazs
Cosmin Sabou
Jim Chen
Nicholas Nethercote
Sotaro Ikeda
Rob Wu
Valentin Gosu
Brian Grinstead
Ciure Andrei
Eugen Sawin
Narcis Beleuzu
Geoff Brown
Sebastian Hengst
Bob Owen
Jan Horak
Tiberius Oros
Mike Conley
Chris Peterson
Masatoshi Kimura
James Teh