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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Current WHATWG spec means that `numeric` is `IS_DIGITS` and `decimal` is
`IS_NUMBER`.
Depends on D68312
Differential Revision: https://phabricator.services.mozilla.com/D68313
--HG--
extra : moz-landing-system : lando
Gecko has duplicated code for input scope support, so I would like to clean up
this.
Differential Revision: https://phabricator.services.mozilla.com/D68312
--HG--
extra : moz-landing-system : lando
`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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Current WHATWG spec means that `numeric` is `IS_DIGITS` and `decimal` is
`IS_NUMBER`.
Depends on D68312
Differential Revision: https://phabricator.services.mozilla.com/D68313
--HG--
extra : moz-landing-system : lando
Gecko has duplicated code for input scope support, so I would like to clean up
this.
Differential Revision: https://phabricator.services.mozilla.com/D68312
--HG--
extra : moz-landing-system : lando
Microsoft IME on Windows 10 20H1 (build 19025+) supports IME private mode by
input scope. Although previous Windows version uses undocumented API for
Edge and IE only, next Windows will use public API for it.
So let's use IS_PRIVATE input scope in private browsing mode.
Differential Revision: https://phabricator.services.mozilla.com/D53918
--HG--
extra : moz-landing-system : lando
Microsoft IME on Windows 10 20H1 (build 19025+) supports IME private mode by
input scope. Although previous Windows version uses undocumented API for
Edge and IE only, next Windows will use public API for it.
So let's use IS_PRIVATE input scope in private browsing mode.
Depends on D53917
Differential Revision: https://phabricator.services.mozilla.com/D53918
--HG--
extra : moz-landing-system : lando
Gregory Pappas
Masatoshi Kimura
Natalia Csoregi
Masayuki Nakano
Sandor Molnar
Mike Hommey
Norisz Fay
Emilio Cobos Álvarez
Chris Martin
Daisuke Akatsuka
Hiroyuki Ikezoe
Gabriele Svelto
Makoto Kato
Kagami Sascha Rosylight
Simon Giesecke
Mihai Alexandru Michis
Tom Ritter
Brindusan Cristian