Currently, we try to commit composition only when we know there is a composition
in `TSFTextStore`. However, according to the crash report, TIP may have a
hidden composition and may fail to manage ref-count of something when we
disassociate IM context from the window when they have a hidden composition.
Therefore, we could avoid the crash if we try to commit all composition in the
all contexts.
Note that a document manager can have at most 2 contexts, according to MSDN [1].
1. https://learn.microsoft.com/en-us/windows/win32/api/msctf/nf-msctf-itfdocumentmgr-push
Differential Revision: https://phabricator.services.mozilla.com/D209993
As far as I've tested on Win 11, we can put it off to load it when first needed
of the keyboard layout data. `ToUnicodeEx` API changes the dead key state and
it's called a lot in `KeyboardLayout::LoadLayout`, however, this patch does
not newly call `LoadLayout` after `TranslateMessage` API at least while handling
a key message. Therefore, this should be safe but regressions of this change
could be serious, so this makes it enabled only in early beta and earlier for
now.
Differential Revision: https://phabricator.services.mozilla.com/D200600
As far as I've tested on Win 11, we can put it off to load it when first needed
of the keyboard layout data. `ToUnicodeEx` API changes the dead key state and
it's called a lot in `KeyboardLayout::LoadLayout`, however, this patch does
not newly call `LoadLayout` after `TranslateMessage` API at least while handling
a key message. Therefore, this should be safe but regressions of this change
could be serious, so this makes it enabled only in early beta and earlier for
now.
Differential Revision: https://phabricator.services.mozilla.com/D200600
This pref is used for behavior check of how newer TSF behave without IMC.
Therefore, this shouldn't be used by users. However, like bug 1367692 and
bug 1409155, this may be useful when we meet a critical bug of old IME in
newer Windows. Thus we should keep this pref.
Depends on D159817
Differential Revision: https://phabricator.services.mozilla.com/D159818
It's introduced in bug 1367692 to make it possible to test the bug of old
MS-IME on Windows 10 with later versions. Now, the bug and the old versions
have gone. Therefore, we don't need this pref anymore.
Depends on D159816
Differential Revision: https://phabricator.services.mozilla.com/D159817
Now, `inputmode` attribute (`inputMode` in the DOM interface) is a global
attribute for `contenteditable`. Therefore, `Input` is not necessary and
`Inputmode` should be `InputMode`.
Differential Revision: https://phabricator.services.mozilla.com/D158244
Now, `inputmode` attribute (`inputMode` in the DOM interface) is a global
attribute for `contenteditable`. Therefore, `Input` is not necessary and
`Inputmode` should be `InputMode`.
Depends on D157894
Differential Revision: https://phabricator.services.mozilla.com/D158244
It looks like it was added to abstract commonalities between Win32 and
WinRT. But we dropped support for WinRT a long time ago, and there hasn't been
any work on this area of code in 8 years. In the meantime, it just adds an
extra layer of indirection that doesn't need to exist.
Differential Revision: https://phabricator.services.mozilla.com/D139771
When "search" is set to the input scope, there is a case ATOK stop their
suggestions depending on thire setting. To resolve the issue, we need to avoid
sending "search" input scope when ATOK is active. If using the touch keyboard
for touch screens, this change makes user cannot access some specific features
for a "search" input field. Therefore, we introduce a new pref
`intl.tsf.hack.atok.search_input_scope_disabled`, make user can control this
feature.
Differential Revision: https://phabricator.services.mozilla.com/D136448
This fix simply ignores tablet mode when running on Windows 11. The
reasoning behind this is that per Microsoft documentation tablet mode
is specific to Windows 10 and not supported anymore on Windows 11. This
seems consistent in the behavior of the APIs we use to detect the
presence of a keyboard: Windows 10-specific APIs return unexpected
results while APIs that predate them return values that seem consistent
and reliable.
Differential Revision: https://phabricator.services.mozilla.com/D128229
For bug 1670539, I would like to move each on software keyboard code to
own class at first.
Actually, MaybeShowOnScreenKeyboard handels VR keyboard if VR mode. But
I would like to move VR code to ShowOnScreenKeyboard or own class.
Differential Revision: https://phabricator.services.mozilla.com/D109259
Before deleting `IMEState::Enabled::PLUGIN`, let's make it an enum class
for making the change safer. Almost all of this change is done by
"replace" of VSCode.
Differential Revision: https://phabricator.services.mozilla.com/D100100
Sorry for this big patch.
This makes `WidgetQueryContentEvent::Reply` is stored with `Maybe` to get
rid of `WidgetQueryContentEvent`. And `Reply` stores offset and string
with `Maybe` and ``OffsetAndData<uint32_t>`, and also tentative caret offset
with `Maybe`. Then, we can get rid of `WidgetQueryContentEvent::NOT_FOUND`.
Note that I tried to make `OffsetAndData` have a method to create `NSRange`
for cocoa widget. However, it causes the column limit`to 100 or longer
and that causes unrelated changes in `TextEvents.h` and `IMEData.h`.
Therefore, I create an inline function in `TextInputHandler.mm` instead.
Differential Revision: https://phabricator.services.mozilla.com/D98264
This is regression by bug 1618759 and bug 1197722.
By bug 1197722, we use registry value whether opening software keyboard even if
desktop mode. But this fix isn't enough.
Also, before landing bug 1618759, since TSF manages software keyboard state on
newer Windows 10 version such as Windows 10 RS1, bug 1197722's fix isn't used.
Then, after landing bug 1618759, since we use `EnableDesktopModeAutoInvoke`
again, this issue occurs.
Since `EnableDesktopModeAutoInvoke` is available if in HKLM, we should read
HKLM's key too.
Differential Revision: https://phabricator.services.mozilla.com/D83489
`inputmode=none` means that OSK is closed.
`SetInputContext` doesn't call `DismissOnScreenKeyboard` directly since
`DismissOnScreenKeyboard` has no hack of Firefox VR.
Depends on D68316
Differential Revision: https://phabricator.services.mozilla.com/D68317
As long as I test on my environment, bug 1226148 isn't fixed. Since native
message queue has high priority, Gecko may check whether focus is changed
before changing focus to another.
So we shouldn't use native message queue for this. It is better to use idle
queue instead.
Depends on D68315
Differential Revision: https://phabricator.services.mozilla.com/D68316
Unfortunately, current on-screen keyboard (OSK) code in Gecko doesn't work on
current Windows 10. Actually, Windows automatically control OSK when getting
focus. But this isn't good for web browser since `inputmode` spec can close
OSK by `none` value.
Windows 10 RS1 has new API (IInputPane [*1]) to control software keyboard. So
we have to use it if OS is RS1 or later.
TSF has new flag as `TS_SD_INPUTPANEMANUALDISPLAYENABLE` not to control OSK by
TSF. We should use it.
IMM doesn't have this feature to manage OSK. This will become a limitation for
`inputmode` implementation.
[*1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.inputpane
Depends on D68314
Differential Revision: https://phabricator.services.mozilla.com/D68315
Current WHATWG spec is that `inputmode` attribute supports non-input element.
I would like to remove input element check for bug 142484 that is
contenteditable support.
Microsoft IME, Google IME and etc refer 1st input scope that they support, so
we will add both input scopes from `type` and `inputmode`.
Depends on D68313
Differential Revision: https://phabricator.services.mozilla.com/D68314
`inputmode=none` means that OSK is closed.
`SetInputContext` doesn't call `DismissOnScreenKeyboard` directly since
`DismissOnScreenKeyboard` has no hack of Firefox VR.
Depends on D68316
Differential Revision: https://phabricator.services.mozilla.com/D68317
As long as I test on my environment, bug 1226148 isn't fixed. Since native
message queue has high priority, Gecko may check whether focus is changed
before changing focus to another.
So we shouldn't use native message queue for this. It is better to use idle
queue instead.
Depends on D68315
Differential Revision: https://phabricator.services.mozilla.com/D68316
Unfortunately, current on-screen keyboard (OSK) code in Gecko doesn't work on
current Windows 10. Actually, Windows automatically control OSK when getting
focus. But this isn't good for web browser since `inputmode` spec can close
OSK by `none` value.
Windows 10 RS1 has new API (IInputPane [*1]) to control software keyboard. So
we have to use it if OS is RS1 or later.
TSF has new flag as `TS_SD_INPUTPANEMANUALDISPLAYENABLE` not to control OSK by
TSF. We should use it.
IMM doesn't have this feature to manage OSK. This will become a limitation for
`inputmode` implementation.
[*1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.inputpane
Depends on D68314
Differential Revision: https://phabricator.services.mozilla.com/D68315
Current WHATWG spec is that `inputmode` attribute supports non-input element.
I would like to remove input element check for bug 142484 that is
contenteditable support.
Microsoft IME, Google IME and etc refer 1st input scope that they support, so
we will add both input scopes from `type` and `inputmode`.
Depends on D68313
Differential Revision: https://phabricator.services.mozilla.com/D68314
Masayuki Nakano