Forwarding keyboard focus/blur events to VR browser that runs at another process. We will need to set these events in VR shmem, then VR host can receive these states from other process.
Differential Revision: https://phabricator.services.mozilla.com/D48903
--HG--
extra : moz-landing-system : lando
We use SystemParametersInfo to get the current system scroll wheel settings when we process scrollwheel movement in the content process. We need to remove SystemParametersInfo for sandboxing the content process so this code changes the plugin behavior to cache the system wheel settings. We do this by 1) sending wheel settings to the plugin whenever a plugin takes focus and 2) forwarding wheel settings update messages from Windows to the currently focused plugin.
Differential Revision: https://phabricator.services.mozilla.com/D47938
--HG--
extra : moz-landing-system : lando
IMMHandler and TSFTextStore are good class to put native caret when they have
enough information. However, for example, IMMHandler may not have its singleton
instance until first composition of IMM-IME starts. Therefore, typically,
IMEHandler is a good class to put native caret without composition.
This patch adds IMEHandler::MaybeCreateNativeCaret(), and if it won't create
native caret because not yet received WM_GETOBJCT for OBJID_CARET, we should
fire window event for MSAA applications. If there is new MSAA application
retrieves OBJID_CARET, we'll receive WM_GETOBJECT for OBJID_CARET
asynchronously. Then, we should start to put native caret for such
applications.
Note that if we create native caret, some versions of ATOK refers the native
caret and the behavior becomes worse than usual. Therefore, we need to
keep not using native caret as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D13962
--HG--
extra : moz-landing-system : lando
If WM_GETOBJECT for OBJID_CARET is received but a11y module is not active,
IME module should create native caret over our caret because Windows will
handle the request with native caret automatically and we don't need to
enable a11y module only for it.
This patch makes IMEHandler store whether such message has been received and
makes TSFTextStore create native caret when composition, selection or layout
is changed because especially when there is composition, only TSFTextStore
knows correct position to put caret if there is composition or some dispatched
events have not been handled by content process yet.
Note that IMMHandler already does that since some legacy IMEs require native
caret to show its UI and we cannot check active IME strictly. Therefore, this
patch does not touch IMMHandler.
Differential Revision: https://phabricator.services.mozilla.com/D13961
--HG--
extra : moz-landing-system : lando
IMEHandler needs to create native caret later (when there is no composition).
Therefore, IMEHandler should manage whether it creates native caret or not
and IMMHandler and TSFTextStore should create/destroy native caret via
IMEHandler.
Note that this patch makes IMMHandler stops managing whether native caret
is created for plugin or not because native caret is created only one instance
and anyway IME handlers should stop managing native caret when they loses
focus.
Differential Revision: https://phabricator.services.mozilla.com/D13960
--HG--
extra : moz-landing-system : lando
If a11y module is active, it observers caret position and size, and when caret
position or size is changed, it creates/moves native caret to overlap with
our caret.
On the other hand, IME module also creates native caret if active IME requires
it. Therefore, both of them conflicts each other.
This patch makes IME module stop touching native caret if a11y module is active.
Although, a11y module with Flush Player does not work well for IME. Therefore,
this patch keeps the conflict between them as-is for now.
Differential Revision: https://phabricator.services.mozilla.com/D13959
--HG--
extra : moz-landing-system : lando
This patch adds following Microsoft's IMEs into the black list which set
their open state to "closed" when input scope is set to IS_URL and sets
input scope for the URL bar to IS_DEFAULT.
Additionally, this adds a new pref to disable this hack because a lot of
users will affect this hack but perhaps, somebody may not like this if
they use tablet.
The new black listed IMEs:
- Microsoft Bopomofo
- Microsoft ChangJie
- Microsoft Phonetic
- Microsoft Quick
- Microsoft New ChangJie
- Microsoft New Phonetic
- Microsoft New Quick
- Microsoft Pinyin
- Microsoft Pinyin New Experience Input Style
- Microsoft Wubi
- Microsoft IME for Korean (except on Win7)
- Microsoft Old Hangul
MozReview-Commit-ID: BwJKFcu80B8
--HG--
extra : rebase_source : 75aeed04504b476520102984ab6e7875c98b36c8
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
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
Currently, we initialize TSF modules when there is only message window (this
started from bug 1341915). At this time, QQ Input (Simplified Chinese TIP)
fails to initialize itself.
Therefore, we should put off to initialize TSF modules after creating first
normal window. Then, initialize its IMC and input context for the window.
IMEHandler::InitInputContext() should be called when each normal window is
created. Therefore, calling Initialize() from it can guarantee there is
at least one normal window when Initialize() is called.
MozReview-Commit-ID: IfR4y3pYv6J
--HG--
extra : rebase_source : 3f36acfa65567f140eea9c7fc12d6268aadbd5ef
"intl.tsf.hack.ms_japanese_ime.do_not_associate_imc_on_win10" should be unnecessary anymore because it failed to avoid the crash of MS-IME for Japanese but causing other regression. Therefore, this patch removes it completely.
MozReview-Commit-ID: 91jjxfIYReW
--HG--
extra : rebase_source : d261f5bf77c14c41562495574d87364a7bb2d4fc
IME should receive notifications and requests only from proper process. E.g., IME shouldn't commit composition by a request which came from previous focused process.
This patch makes that IMEStateManager::NotifyIME() takes pointer to TabParent optionally. If the request or notification came from remote process, it should be non-nullptr. Then, this makes it ignore notifications and requests from unexpected process.
Note that this patch also touches some gfx headers because they use |ipc::| but compiler is confused at the ambiguousness between |mozilla::ipc::| and |mozilla::dom::ipc::|.
Finally, this patch changes the NS_ASSERTION in IMEHandler::OnDestroyWindow() to MOZ_ASSERT because the orange caused by the NS_ASSERTION was not realized since there was already an intermittent orange bug caused by different NS_ASSERTION.
MozReview-Commit-ID: 9CgKXQRJWmN
--HG--
extra : source : f3b5711908870c5e0e852a399a07e0ae721a12f1
ITfProcessorProfiles are used by a debug method TSFTextStore::CurrentKeyboardLayoutHasIME() and TSFStaticSink (when it's initialized). However, TSFStaticSink isn't necessary until when TSFTextStore needs to hack something for specific IME or notifying IMEHandler of active TIP change. So, we can put off to create the instance of ITfInputProcessorProfiles and TSFStaticSink.
MozReview-Commit-ID: KcrqUbqz1do
--HG--
extra : rebase_source : f1821b782c6cd316a8f234a17ee3c92114547041
TIPs (and normal keyboard layouts) don't need IMC on focused window. So, in most environment, it's not necessary to restore default IMC of focused window.
Therefore, this patch makes IMEHandler not restore default IMC unless legacy IMM-IME is active and disassociate IMC from focused window when IMM-IME isn't active.
However, this is risky change. Therefore, the new behavior is disabled in default settings. On the other hand, we need the new behavior only when MS-IME for Japanese is active on Win10. Therefore, this patch adds a pref to enable/disable the hack and make it true in the default settings.
MozReview-Commit-ID: KAVxVT9CrsW
On Windows, when nsWindow is created, IMEHandler::InitInputContext() is called. Then, it calls TSFTextStore::SetInputContext(). However, at least for now, TSFTextStore needs to do nothing until the widget gets focus.
MozReview-Commit-ID: HBafHEUSCtd
--HG--
extra : rebase_source : 5c21e0f81dbc9b644965f7df42da1b6314b58a26
It's not clear to me what NOTIFY_IME_OF_COMPOSITION_UPDATE means only from the name. For making the name clearer, this patch renames it to NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED and add some explanation to the definition.
MozReview-Commit-ID: 8ySYCNJ1Ytz
--HG--
extra : rebase_source : 3331b8f48e8b460c7f9b088064dcda9488f3403c
On screen keyboard is sometimes invisible even if IsWindowEnabled(osk) == TRUE. So We should call tabtip.exe even if it is invisible.
--HG--
extra : commitid : 3IWCP2tVfdx
extra : rebase_source : a16a1a84139ec5c97e89227609dd66f515f6e138
Daosheng Mu
David Parks
Ryan Hunt
Ehsan Akhgari
Masayuki Nakano
Sylvestre Ledru
Thomas Wisniewski
Nicholas Nethercote
Makoto Kato
Jared Wein
Gijs Kruitbosch
Carsten "Tomcat" Book
Sebastian Hengst