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
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
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
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
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
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
Original patch author is Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: Jnqz35iNsQb
--HG--
extra : rebase_source : b3be56afc3330a98a981af0d8b85a28164953e1c
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
Authored by Andrew Comminos <andrew@comminos.com>
MozReview-Commit-ID: FIQBHSXgjMh
--HG--
extra : rebase_source : 1ae73bed3b2b933d11803ae3b93afbf3d1e1f570
Authored by Andrew Comminos <andrew@comminos.com>
MozReview-Commit-ID: FIQBHSXgjMh
--HG--
extra : rebase_source : 22885a2846ec0bc718196d6e16bacb37b0410b25
Now, nsIWidget::ExecuteNativeKeyBinding() isn't used by anybody for executing
edit commands. Instead, they need array of edit commands for the key
combination. So, the method should be renamed to GetEditCommands() and just
return edit commands as an array.
MozReview-Commit-ID: 4G0B1lJ8Lbe
--HG--
extra : rebase_source : 4a5829281d59677c773950c34d91a1cd8074d243
GetScreenBounds() is slow for the GTK port so we override and use
mBounds directly in nsWindow::GetWidgetScreen()
MozReview-Commit-ID: ICElOCEzswf
--HG--
extra : rebase_source : 2fb450cc9d933346cebfdbff0b32ea4130550395
Shift+F10 is also well-known shortcut key on Linux. So, it should behave same as pressing ContextMenu key. So, for allowing web page to prevent its default, nsWindow for GTK needs to consume Shift key state at dispatching eContextMenu key.
Additionally, we should allow to open context menu with Shift+ContextMenu because only ContextMenu key press can be prevented its default by web page. Therefore, we should allow users to open context menu even with keyboard even if web content doesn't want it.
Note that Ctrl+Shift+F10 or Alt+Shift+F10 should behave same as Shift+ContextMenu key, but we should discuss later.
MozReview-Commit-ID: 1mPGKMTsrkv
--HG--
extra : rebase_source : 75dd8333b24f5e2f4ded4414b5e5ee85de253cc7
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
We were miscounting the number of manual configure events which we
needed to send gtk as the workaround for bug 1225044, causing it not
to work in some cases. This is because configure events can come from
more sources than were counting.
Decrement mPendingConfigures only as far as zero, like
configure_request_count in gtk_window_configure_event().
MozReview-Commit-ID: GxpR2Zozxor
--HG--
extra : rebase_source : 9d02c4d019d8bea7a07c20fb1435d2f677ae6e28
This patch changes it from |NS_IMETHOD| to |virtual nsresult| because some call
sites are checked and others aren't.
--HG--
extra : rebase_source : 6723b9db709d1506dd394b1e85572309c1c2e2cf
This patch changes one from |NS_IMETHOD| to |virtual nsresult| and the other to
|virtual void|.
--HG--
extra : rebase_source : 55af71c01dc75d6bf7c63191e9cfabc9f5368ffa
This patch changes it from |NS_IMETHOD| to |virtual void|. The return value was
only checked in one low-value assertion and one other place where the check had
no useful effect (in nsCocoaWindow::HideWindowChrome()).
--HG--
extra : rebase_source : f6671e9e0e10ee18fb32f8b1c83f1e64c3d97e67
This patch changes it from |NS_IMETHOD| to |virtual void|. The return value was
only checked in one low-value assertion so I decided it wasn't needed.
--HG--
extra : rebase_source : 3523d9a086cf98c40d237d777f5dd471af0d7465
This patch changes it from |NS_IMETHOD| to |virtual void| because every
implementation of these functions always returns |NS_OK|.
--HG--
extra : rebase_source : 07ee29c514bf35b97d7195c53bb5b9220d1ef961
This patch changes them from |NS_IMETHOD| to |virtual void| because every
implementation of these functions always returns |NS_OK|.
--HG--
extra : rebase_source : 6207df5a46aeb6b8aaa0f697447a51bc6a6dc366
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from the android nsIWidget instance,
because it can use the nsBaseWidget one.
--HG--
extra : rebase_source : 0791d3cb05907d6b41879549b52f3a33018abf45
This patch removes its return value, because none of the call sites check it
except for one non-vital assertion.
--HG--
extra : rebase_source : 3471c4e22394b8a05c6708d0f8469686ffad9814
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : a1a04193bc3940f1468c7c235f6d6e0341d0f1c2
Specifically: OnDefaultButtonLoaded, AttachNativeKeyEvent, BeginMoveDrag,
BeginResizeDrag, GetAttention. These are all fallible functions whose result is
always checked.
The patch also moves some trivial function definitions from nsBaseWidget.cpp to
nsBaseWidget.h, and removes the android BeginResizeDrag() because it can
use the nsBaseWidget one.
--HG--
extra : rebase_source : ef32a41b547bcbc21f7df0043f683307470b136e
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 1c42bb32a662f2659c934a245ecd0025045120a5
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 2a94a47f1e7fe986d1efc3854c72968a3e28e365
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from the android nsIWidget instance,
because it can use the nsBaseWidget one.
--HG--
extra : rebase_source : f276e1629fcd0ffccb8c8dbec7bba6639a5ebd9f
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : 82733f682c9e254e20354cc6908955a1e7485ee7
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : ccf64aaa9364d096e1f060ef77be7e8455b11e1f
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : b8a0d9a49b31929dd06af9e61fc57f484af7671d
This patch does the following.
- Removes the return value, because none of the call sites check it.
- Puts an empty implementation into nsBaseWidget.
- Removes the empty implementations from several nsIWidget instances, because
they can use the nsBaseWidget one.
--HG--
extra : rebase_source : e98b7f9970a920c39e941bb531dfc098125913d1
Its return value is only checked in one low-value assertion.
The patch also does the following.
- Removes the Android and GTK overloadings of EnableDragDrop(), which are
identical to the nsBaseWidget one.
- Streamlines the Windows implementation: fixes the indentation and takes
advantage of infallible |new|.
--HG--
extra : rebase_source : d090848cf5ea2e92c0188b07559c1e1f3899829f
The only implementation of SetSizeMode() that can fail is the nsCocoaWindow
one, on an Objective C exception, which is unlikely and can be swallowed.
This allows some nsGlobalWindow functions to become infallible as well.
--HG--
extra : rebase_source : 85d54185f63d2c138ee3f3e0e0bfe3b5e805a981
They don't need to be NS_IMETHOD, but they should be MOZ_MUST_USE. Adding the
latter catches a few missing checks, which the patch adds.
The patch also gives PuppetWidget an InfallibleCreate() function, which makes
the infallibility of PuppetWidget creation clear.
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
Use scale-facotr signal to detect DPI change. Also, we should update
mBounds for current scaling setting.
MozReview-Commit-ID: 9fuFORzSzaD
--HG--
extra : rebase_source : 48462e9f251399433d25ffed100fbaa5bca8186a
This patch removes dozens of ToUnknown/FromUnknown conversions and doesn't add
any new ones, which is nice. It also removes UntypedDevPixelsToCocoaPoints(),
which is no longer needed.
--HG--
extra : rebase_source : 81288126b582402408518aecfc304bc128e05d15
