Add a new interface, nsIAndroidEventFinalizer, that is called whenever a
callback object is finalized, i.e. there can be no more callbacks for a
particular dispatch. Add the finalizer as a new parameter to dispatch().
Existing callers that don't need a finalizer are not affected.
This functionality is required in order to unregister our message
manager listener in a child process, after dispatching an event with
callback from a child process.
MozReview-Commit-ID: 8n89c63UGNm
--HG--
extra : rebase_source : 4913b449588e128122d7f4f64145a7794de5ab5d
There are some legacy APIs in Messaging.jsm that we can remove, now that
we no longer have to support legacy add-ons.
MozReview-Commit-ID: 3Gfg12hmkN7
--HG--
extra : rebase_source : 874b812be89a7591d9c06fbb616347aca9a8db9d
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
nsIClipboardDragDropHooks and nsIClipboardDragDropHookList allow XUL apps
to customize drag and drop operation and paste operation. However, this
feature was used only by ChatZilla and it doesn't work on Gecko anymore.
So, we can get rid of them from our tree.
MozReview-Commit-ID: Ibs3V1gI8Ry
--HG--
extra : rebase_source : 83428293d59aaca432d76c71b214aa7799f7f9de
This API is deprecated (callers are supposed to be using
nsISound::playEventSound instead) and there are no callers remaining in
mozilla-central, or references to the strings for the API. Let's remove
dead code.
This implements the only useful piece of functionality that the
TitlebarAndBackgroundColor class was providing.
MozReview-Commit-ID: FXC6ICgDaoZ
--HG--
extra : rebase_source : fcd5b02ef057199df34459a4361ef7b4184d3a57
We no longer need the ability to specify a background color which gets drawn in
the titlebar. This was the only reason why we were using a textured window.
MozReview-Commit-ID: E8zizuvjjnA
--HG--
extra : rebase_source : ecd4d23e9bb068efbcd192b90e039809bdb451b0
Another patch in this patch series is going to remove our custom window
background color entirely, so we no longer need this override.
MozReview-Commit-ID: 5Hk8jiudzir
--HG--
extra : rebase_source : 24f067726b6c9ce9991dd11df19b726c327eaf05
OnUpdateComposition() may be called without new range instance by some TIPs
when they starts to modify composition string. At this timing, TSFTextStore
should append a pending action for dispatching keyboard event into the queue.
Without this patch, OnUpdateComposition() creates incomplete pending action
for composition update and then, MaybeDispatchKeyboardEventAsProcessedByIME()
appends pending action for dispatching keyboard event from another point
immediately (e.g., from SetText()), then, finally, the caller of
MaybeDispatchKeyboardEventAsProcessedByIME() appends another pending action
for composition update with proper composition string. Therefore, the
first pending action for composition update clears composition string before
actually updating it with new composition string. In other words, new
pending action for dispatching keyboard event splits a pending composition
update. So, this patch prevents the splitting.
MozReview-Commit-ID: 9pYO9pm3Vh9
--HG--
extra : rebase_source : a8fb903174c0f1af61a71175dbbf01b7b1c5cb53
When EditorEventListener receives keyboard events, it tries to execute
native key bindings which are stored by each keyboard event. For performance
reason in e10s, TabParent initializes native key binding information of every
keyboard event before sending it to the remote process. Therefore,
PuppetWidget checks if every keyboard event has native key binding information.
However, the native key binding information of dummy keyboard events marked as
"processed by IME" on Android are never initialized before sending PuppetWidget.
Therefore, we hit MOZ_ASSERT in PuppetWidget.
This patch makes GeckoEditableSuppor::SendIMEDummyKeyEvent() set native key
binding information to "none" before dispatching every keyboard event since
keyboard events during composition shouldn't cause any edit actions.
MozReview-Commit-ID: Bk532ahCQP6
--HG--
extra : rebase_source : 939c1befd4b587681192b6827e7c7fa52619d498
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
When dragging an image, add the image request's MIME type to the transfer
so that the MIME-extension check can be done in the parent process.
Move the MIME-extension check to the parent process to avoid
issues caused by content process sandboxing.
MozReview-Commit-ID: 3cb4fCr6GnL
--HG--
extra : rebase_source : ec49b8c83613be844fe4cd88a5024ac41a845199
nsBaseWidget::BoundsUseDesktopPixels() states that window types before
eWindowType_popup take desktop pixels rather than device pixels for
parameters of Move and Resize.
Cocoa widget seems to treat all of them as desktop pixels, and sheet is
one of the window types that it can actually open, so it should be put
before popup so that BoundsUseDesktopPixels() is correct on that.
MozReview-Commit-ID: FPqOoUQlQCy
--HG--
extra : source : 1d1f62a81d9fc059af9038eebc64256aeba397d3
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