Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB. For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.
Therefore, InputContextAction should declare two causes. One is unknown but
occurred during handling non-keyboard event. The other is unknown but occurred
during handling keyboard event.
However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event. Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling. Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.
IMEStateManager uses this new API to adjust the cause of changes of input
context.
Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.
MozReview-Commit-ID: 5JsLqdqeGah
--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
ATOK started to be TIP of TSF since 2011. Older than it, i.e., ATOK 2010 and
earlier have a lot of problems even for daily use. Perhaps, the reason is
Win 8 has a lot of changes around IMM-IME support and TSF, and ATOK 2010 is
released earlier than Win 8.
ATOK 2006 crashes while converting a word with candidate window.
ATOK 2007 doesn't paint and resize suggest window and candidate window
correctly (showing white window or too big window).
ATOK 2008 and ATOK 2009 crash when user just opens their open state.
ATOK 2010 isn't installable newly on Win 7 or later, but we have a lot of
crash reports.
Note that ATOK 2006 is the first version supporting Win XP x64. So, ATOK 2005
must not support x64 apps.
Unfortunately, we cannot block loading DLLs of them. Therefore, IMEHandler
should disassociate IMC from active window when user changes active keyboard
layout to the legacy ATOK and not associate IME with any window when
SetInputContext() is called even with "enabled". Additionally, when user
changes active keyboard layout from the legacy ATOK to one of the other
keyboard layouts, IMEHandler should associate IMC with current window for
new active IME.
MozReview-Commit-ID: RVYwmYxzO7
--HG--
extra : rebase_source : c237a3aca6ceb6a1f7251bd9421e4b905be5bc6c
Some odd touchpad utils give focus to window under mouse cursor when user tries
to scroll the content with swiping or something.
This is really odd behavior because some windows like popup windows doesn't
want focus. However, such ones do actually. For making easier to check such
device's behavior, we should have a pref to emulate such behavior.
MozReview-Commit-ID: 6euwpHn7blf
--HG--
extra : rebase_source : cc23f08f422f25f2851404696e06e069c7936186
This patch will
* Move native print dialog code to the PrintDialogService of widget.
* Toolkit call PrintDialogService instead of calling the native print dialog.
* Change SetWindowText/CreateWindow to SetWindowTextW/CreateWindowW
in order to treat localized string correctly.
MozReview-Commit-ID: DOgp3STaJ4t
--HG--
rename : toolkit/components/printingui/win/nsPrintDialogUtil.cpp => widget/windows/nsPrintDialogUtil.cpp
rename : toolkit/components/printingui/win/nsPrintDialogUtil.h => widget/windows/nsPrintDialogUtil.h
extra : rebase_source : 9b428f528156a70f5a127b1eeec60f6f593387a0
In order to move print native dialog code to windows widget, this patch will
create skeleton of PrintDialogService to windows widget.
Toolkit code(i.e. nsIPrintingPrompotService) will call this PrintDialogService.
Note that this PrintingDialogService suppose running on main process, so we
should call this interface from main process(i.e. nsPrintingPromptService, not
nsPrintingProxy).
MozReview-Commit-ID: 3P6kac9I9W4
--HG--
extra : rebase_source : 5b5ecd104cf4cecd1b68a3d6d4b33aca9fea9548
The functions changed are given signed arguments (that are converted to unsigned).
Changing them to signed resolves the warnings and preserves the original values.
MozReview-Commit-ID: BxIAECFiuQR
--HG--
extra : rebase_source : c48cef46f3ad5a060ad1f33d1c97744bfa8a82d7
inline functions are supposed to be declared in the header file, so the compiler can inline them.
gcc complains about this, but clang/msvc apparently do not.
We also needed to move the DeadKey struct and class into the header, as the function calls a
method on the DeadKey class, and you can't do that on a forward declared class.
MozReview-Commit-ID: 8NxP59AXuZi
--HG--
extra : rebase_source : 9fd74d2c571bdeb4244cb63baf508946a2f19aa6
The intention of these macros here is merely to log a warning and enable
a developer to notice the inconsistency. Pass the result to Unused.
MozReview-Commit-ID: 9IOuwQ3InVm
--HG--
extra : rebase_source : 83f265a5e042dee0c2ad66d45b67906f1b0422aa
This avoids a lot of mismatches between nsAString and char16_t*, thus removing
many getter_Copies() and ToNewUnicode() and get() calls, and generally making
things simpler.
Note: the patch removes GetDefaultPrinterNameFromGlobalPrinters() by simply
inlining it at its two callsites, which is easy with the changed types.
--HG--
extra : rebase_source : 9ab9b3694f093fc9b22c7f8e2394a98674d76c11
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : e7e0a3f83001813239338bc5b3895252e1fb3ea6
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(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
Removes the XPCOM interface for nsIDOMHTMLCanvasElement, replacing it
with binding class usage.
MozReview-Commit-ID: DQJhqGlY8U6
--HG--
extra : rebase_source : a33146a22ee356a0840bb9fef82d51b2b315f6d7
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : a2661dce1ac191fdf098e631cd7878f0215643d5
When "mozAwesomebar" is set to inputmode value, that means that the Smart
Location Bar gets focus. In that case, we should notify IME of input scopes
as "URL" because on-screen keyboard for URL has some useful additional keys
but they are not hindrances even when users want to type non-URL text.
On the other hand, MS-IME for Japanese and Google Japanese Input changes their
open state to "closed" if we notify them of URL input scope. A lot of users
complain about this behavior. Therefore, we should notify only them of
"Default" input scope even when "mozAwesomebar" has focus.
MozReview-Commit-ID: DIgqpR7TXQx
This warning is saying the operation may be undefined because the value of
->left is not guarenteed to be the same because of undefined order of operations.
Fortunately, this seems like a typo and we actually meant to assign ->bottom
MozReview-Commit-ID: H5G8fnDwIJP
--HG--
extra : rebase_source : cd6a2463a90b6675b12bb8255fe605937771bee8
When we UnregisterAudioSessionNotification in response to an OnSessionDisconnected
message, we unintentionally decrement the refcount before restoring it. This KungFu
grips us for the duration of that operation.
--HG--
extra : rebase_source : 7c7e786064811d040d23741c143d9eef04edb5e0
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
With this change, we are able to load PDFium engine from different library.
MozReview-Commit-ID: ErAZCPRzRR5
--HG--
extra : rebase_source : f0421af9c70d69564ed8f96d32870314871aabef
The problem happened only on themed widget. The problem was triggered by Bug 888870. It just added Windows 8.1 support. When high contrast mode was enabled on Win 10, background color problem happend on themed widgets. There were 2 patterns.
- After hover the menu item, its background color remained highlighted
- After hover the menu item, its background color became black
From it, the problem seemed to be caused by background color drawing of themed widgets. nsNativeThemeWin::DrawWidgetBackground() does the background color drawing. AssumeThemePartAndStateAreTransparent() controls skipping background color drawing of themed widgets. If AssumeThemePartAndStateAreTransparent() was removed, the problem was addressed. From it, how DrawThemeBackground() works seems to be changed on high contrast mode since since Win8.1. To address the problem, the patch remove the skipping on high contrast mode since since Win8.1
Masayuki Nakano
Tom Ritter
Brad Werth
Sebastian Hengst
Sylvestre Ledru
Masatoshi Kimura
Mantaroh Yoshinaga
Kris Maglione
Nicholas Nethercote
Emilio Cobos Álvarez
Kyle Machulis
Wes Kocher
David Parks
David Anderson
cku
Chris Peterson
sotaro