Users may map reserved shortcut keys of Firefox/Thunderbird as an editing
command or a navigation command. Therefore if and only if an editable element
has focus and a reserved key combination is mapped to an editing command or
a navigation command by the system settings, we should allow to dispatch it
into the content and work it as what user expects.
With this change, keyboard only users may loose some shortcut keys to leave
from a web content which blocks keyboard focus in it. However, there may
be another reserved shortcut keys to escape from such web apps only with
keyboard because it's hard to think that all reserved shortcut keys conflict
with users' settings.
Differential Revision: https://phabricator.services.mozilla.com/D138009
`StartOffset` and `EndOffset` of `IMENotification::SelectionChangeDataBase`
depend on whether the range is reversed or not. Therefore, their actual
meaning is "anchor offset" and "focus offset" in the DOM selection terms.
Similarly, `SelectionStartOffset` and `SelectionEndOffset` of
`WidgetQueryContentEvent::Reply` are exactly same ones.
Therefore, they should be renamed to `AnchorOffset` and `FocusOffset` for
making what they return clearer.
Differential Revision: https://phabricator.services.mozilla.com/D137427
Unfortunately, it cannot has `Maybe` because of used by a union. Therefore,
it needs to manage with `bool` members of whether it's initialized with or
without error and whether it has a range.
Note that this changes `nsITextInputProcessorCallback.idl` which is currently
only for automated tests too. The new behavior will be tested by the last
patch in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D137424
For consistency with `IMMHandler::Selection`, let's make it use
`OffsetAndData<uint32_t>` for preparing them to use a new common class.
Differential Revision: https://phabricator.services.mozilla.com/D137419
I'd like to use `OffsetAndData` in `IMMHandler` to store selection range.
Before doing this, this patch adds some useful methods into it.
Differential Revision: https://phabricator.services.mozilla.com/D137411
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
They are not always set. Therefore, it should be managed with `Maybe`.
And this creates a new class `StartAndEndOffsets` and it's similar to
`OffsetAndData` class so that similar API makes the code easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D97949
This patch creates `OffsetAndData` for managing start offset in flat-text
content and composition string in one place. And it supports stream to
log it easier.
Then, this patch makes `TSFTextStore::Composition` inherits it for sharing
similar code with other similar data.
Note that the new class guarantees that it won't return overflown offset
and it won't cut overflown string from max offset.
Differential Revision: https://phabricator.services.mozilla.com/D97947
Autocapitalize isn't applied if type is url, email or password. If these types,
truncate autocapitalize value in InputContext not to pass it to widget.
Differential Revision: https://phabricator.services.mozilla.com/D86676
Actually, altough TSF and IMEStateManager have the logging for InputContext,
I would like to use common logging code using `ToString.h`.
Differential Revision: https://phabricator.services.mozilla.com/D84287
It is useful to use ToString.h to log text and selection change instead of
adding it each source code. Actually, there is same code in
IMEContentObserver and widget.
Also, mozilla namespace is required since this conflicts with
WinModifierKeyState.h.
Differential Revision: https://phabricator.services.mozilla.com/D64021
--HG--
extra : moz-landing-system : lando
I would like to log `IMEState` and `InputContextAction`in widget. But this
utilities are in `IMEStateManager`, so I would like to move it to widget
by using `mozilla/ToString.h`.
Differential Revision: https://phabricator.services.mozilla.com/D44103
--HG--
extra : moz-landing-system : lando
Actually, long tap can set focus. But since it uses `nsIFocusManager::FLAG_BYMOUSE` flag, we cannot recognize whether setting focus is by long tap or not.
So I would like to add new flag `FLAG_BYLONGPRESS` and `CAUSE_LONGPRESS` that are by long tap.
Differential Revision: https://phabricator.services.mozilla.com/D35991
--HG--
extra : moz-landing-system : lando
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
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
IMEStateManager has a static instance of InputContext which has some nsString
instances. Then, their members will be released after XPCOM shutdown and
that is detected as unexpected destruction.
Therefore, IMEStateManager should release them by itself at XPCOM shutdown.
Using nsTSubstring::SetCapacity(0) is the simplest way to release only the
string buffers.
MozReview-Commit-ID: LMrQxQF9xPn
--HG--
extra : rebase_source : 7cbaf19b76be8db083c10270d0ee436a1c061ea2
Telemetry and some performance profiles show that Msg_NotifyIMEFocus can take
a few seconds to complete, and jank the browser. With bug 1217700, it removes
the necessity of sync Msg_NotifyIMEFocus, so in this patch we make this async
for performance improvement.
MozReview-Commit-ID: 15eUwMJ2Q7H
--HG--
extra : rebase_source : b463e6e881ca5ebec00d0f76e29ca103059b3ddd
Android now supports telling an IME that it shouldn't store user-entered content into it's dictionary/language model/etc. and we want to automatically enable this in private browsing.
As the code that handles input on Android doesn't have any notion of tabs (and therefore of the difference between normal and private tabs), the best way to get that info across is to retrieve it directly within the IMEStateManager from the corresponding document and store it in the inputContext, which is then passed to Java for Fennec to handle.
Implementing this within Gecko also has the benefit that this part of the code can be used by other platforms as well should they want to support similar features in the future.
MozReview-Commit-ID: DsxjC4Ma7DR
--HG--
extra : rebase_source : f0940cb40170ab32cf5a172d07a61d083427be8a
Currently, IMEStateManager always sets input context as set by current process even when it needs to adjust IME state when a tab parent for current focused IME process is removed. Then, input context for the widget is marked as for main process but the widget still have IME focus of a remote process.
For fixing this mismatch, IMEStateManager should set ORIGIN_CONTENT even when the tab parent is being destroyed.
MozReview-Commit-ID: C10YOAtkET4
--HG--
extra : source : 9430d123b19e0ac551c6048bb044fcfa22d13e45
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
IMEContentObserver can store pointer of IMENotificationRequests of its mWidget. Therefore, it can check the requests dynamically when it receives content change or layout change.
This patch makes IMEContentObserver stores IMENotificationRequests as pointer and check it at every change notification received. Additionally, notification request may be changed due to focus move or something. Therefore, this patch makes IMEContentObserver and IMEContentObserver::IMENotificationSender() check if the notifications are still necessary.
MozReview-Commit-ID: 2uU2wN15D8v
--HG--
extra : rebase_source : 6086e0293343632df43087c767ad00521e764476
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
--HG--
extra : rebase_source : d2634ada6c33dbf7a966fadb68608411ee24bfab
I think that we can drop nsIMEUpdatePreference::DontNotifyChangesCausedByComposition(), i.e., nsIMEUpdatePreference::NOTIFY_CHANGES_CAUSED_BY_COMPOSITION because it's now used only by TSFTextStore but TSFTextStore ignores if SelectionChangeDataBase::mCausedByComposition or TextChangeDataBase::mCausedOnlyByComposition is true (for supporting async changes in e10s mode). So, only issue is, dropping the flag might cause increasing computing TextChangeData cost during composition in TSF mode. However, now, it's already enough fast and even if it'd cause performance regression, we could add a hack with TextComposition's offset information. Therefore, we don't need to worry about the performance regression so seriously.
MozReview-Commit-ID: HNT3G4isONj
--HG--
extra : rebase_source : 164231023aa2a17ceab94d92fb49ba0a00dab429
Currently, all widgets request selection change notifications to IMEContentObserver. Additionally, IMEContentObserver needs to listen selection changes for caching latest selection for eQuerySelectedText. Therefore, it doesn't make sense to keep defining nsIMEUpdatePreference::NOTIFY_SELECTION_CHANGE.
If widgets didn't need selection change notifications, they could just ignore the unnecessary notifications.
Note that all widgets don't need selection change notifications if a plugin has focus and IMEContentObserver cannot observe selection changes in the plugin. Therefore, if IMEContentObserver is initialized with a plugin, it shouldn't listen selection changes (and doesn't need to notify widgets of selection changes).
MozReview-Commit-ID: FOVFFgA2nOz
--HG--
extra : rebase_source : 3e16d5023835f99f82934e754d2e7db70474f9ee
For sending NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED after the other change notifications which was caused by the user input, we need to use IMEContentObserver::IMENotificationSender because it sends the notifications when it's safe to do it.
This patch makes TextComposition use IMEContentObserver to send the notification. However, if there is no active IMEContentObserver, e.g., composition events are fired on unfocused window, TextComposition sends it by itself (same as current implementation).
If IMEContentObserver stops observing when it has pending NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED, it cannot send the notification (i.e., it is discarded completely in such case). However, in such case, IMEContentObserver sends NOTIFY_IME_OF_BLUR. So, anyway, native IME handler should treat the blur notification as it including NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED.
On the other hand, we're buggy if composition events are fired in non-active window. Even in such case, IMEContentObserver should be created for active editor in each document and it notifies IME of the changes. But this is out of the scope of this bug.
MozReview-Commit-ID: 7Q0ZsJTh4hX
--HG--
extra : rebase_source : 6417f991fa8c0fbe3f25b27bacf4257e5485aecc
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
Masayuki Nakano
Makoto Kato
Kartikaya Gupta
Jonathan Watt
Tooru Fujisawa
Sylvestre Ledru
Henri Sivonen
Andi-Bogdan Postelnicu
Sebastian Hengst
Tristan Bourvon
Milan Sreckovic
Eugen Sawin
Eric Rahm
James Willcox
Henry Chang
Jan Henning