If I remember correctly, `enum class` was not allowed when I added
`enum Command`. Now, we can make it `enum class` for better type check at
compile time.
Differential Revision: https://phabricator.services.mozilla.com/D29169
--HG--
extra : moz-landing-system : lando
`TextInputHandler::HandleCommand()` dispatches `Tab` key events only when
it receives `insertTab:` or `intertBacktab:` command which are caused by
actual `Tab` key press.
However, these commands could be generated by IME or the system shortcut
keys are customized oddly.
This patch makes the method support such situation with dispatching fake
`keydown` and `keypress` events to emulate `Tab` key press for
mainly focus navigation.
Differential Revision: https://phabricator.services.mozilla.com/D20804
--HG--
extra : moz-landing-system : lando
Currently, when IME sends a command with committing composition,
TextInputHandler::HandleCommand() dispatches a *fake* `keypress` event
for making default event handler (e.g., focused editor) handle the
event. However, we stopped dispatching `keypress` events for
non-printable keys. Therefore, web apps cannot do that like us.
On macOS, simple conversion IMEs like Korean 2-set IME, behave
differently if active application is changed. E.g., on Safari,
some of them may never use composition string, but not so on
Chrome and Firefox. So, this is what the case we need to emulate
Safari's behavior.
Dispatching a fake `keydown` event for this purpose does **not**
conform to UI Events because `keydown` events should notify web
apps of **physical** key state changes. However, Chrome dispatches
fake `keydown` events intentionally. Therefore, we should follow
this hacky behavior for user experience.
Differential Revision: https://phabricator.services.mozilla.com/D20644
--HG--
extra : moz-landing-system : lando
This issue is e10s only.
Even if calling SetSelection, it doesn't reset selection cache in
TextInputHandler. Since selection cache is updated by OnSelectionChange
asynchronous, we should set temporary range when having replacement range.
Also, even if marking dirty doesn't fix this issue. Content cache may return
other range such as caret position instead of replacement range by SetSelection.
Differential Revision: https://phabricator.services.mozilla.com/D14002
--HG--
extra : moz-landing-system : lando
If a key inputs multiple characters, we dispatch same number eKeyPress
events to input each character. However,
TISInputSourceWrapper::WillDispatchKeyboardEvent() always sets
charCode of all eKeyPress events to first character of inserting.
Instead, it should set charCode value to nth character of the
inserting string.
Differential Revision: https://phabricator.services.mozilla.com/D5884
--HG--
extra : moz-landing-system : lando
This patch adds a telemetry probe to collect Input Source ID or Bundle ID of
IME when an IME open mode is selected by user. Input Source ID includes
input mode of IME, but Bundle ID does not so. In most languages, we need
to collect the former, but only for Japanese IME, we need to collect the
latter because non-Japanese IME's input mode is "how to input characters".
So, the input mode is important. However, Japanese IME's input mode is
"to input which type of characters". So, Japanese IME user may use multiple
input modes but we need only the IME mode. If we'd collect number of
each input mode users of Japanese language, it'd be difficult to count
how many users actually used typical Japanese IME since somebody may use
only a mode, some others may use only different modes.
So, this patch collects Input Source ID when non-Japanese IME is open and
Bundle ID when Japanese IME is open.
MozReview-Commit-ID: CltLrWVGyRk
--HG--
extra : rebase_source : 752dd00c4e43bda9586ed3ba498636bf5069ead2
If a key combination causes text input, we need to dispatch keypress
events without alt/ctrl/meta modifiers since TextEditor won't handle
keyepress events whose altKey, ctrlKey or metaKey is true as inputting
text.
Currently, TextEventDispatcher sets mCharCode of eKeyPress event from
mKeyValue. Then, when altKey, ctrlKey or metaKey is true, it'll call
WillDispatchKeyboardEvent() and then, TextInputHandler needs to reset
the charCode value from native event information.
However, the problem is, TextInputHandler::InsertText() is called
with control character when control key is pressed and InsertText()
clears the modifier information before sending eKeyPress event to
TextEvenDispatcher so that TextEventDispatcher won't call
WillDispatchKeyboardEvent() even though control key is actually
pressed. Therefore, TextInputHandler cannot adjust charCode value
and modifier flags in some cases such as control + option + 'a'.
This patch makes InsertText() stop clearing the modifiers and
makes WillDispatchKeyboardEvent() do it instead. This procedure
is expected by TextEventDispatcher.
MozReview-Commit-ID: Ig6qgRBeQDh
--HG--
extra : rebase_source : 446e8af0e921946f3409d26ede70446248317673
First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event
before sending IME. This is different behavior from Gecko on the other
platforms and it means TextInputHandler does not know if the eKeyDown event
will be handled by IME. Therefore, we need to make TextInputHandler dispatch
an eKeyDown event dispatch when it needs to dispatch another event. Therefore,
this patch makes TextInputHandler not dispatch an eKeyDown even from
its HandleKeyDown() unless it's already has composition (because if it's
already had composition, any eKeyDown event except modifier keys should be
marked as "processed by IME" for compatibility with the other browsers).
For dispatching eKeyDown event only once for a native keydown event,
this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent()
to check whether eKeyDown event has already been dispatched for the event
and if it's not so, dispatches eKeyDown event.
Note that on macOS, dead keys are implemented as IME. However, we need to
treat dead keys as is. Therefore, if current keydown event is a dead keydown
event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching
eKeyDown event and its following eKeyDown event as "processed by IME".
MozReview-Commit-ID: 7epk8wdAznd
--HG--
extra : rebase_source : 0ed30ff3e108170fd96eabe626e0530473f2f3b1
First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event
before sending IME. This is different behavior from Gecko on the other
platforms and it means TextInputHandler does not know if the eKeyDown event
will be handled by IME. Therefore, we need to make TextInputHandler dispatch
an eKeyDown event dispatch when it needs to dispatch another event. Therefore,
this patch makes TextInputHandler not dispatch an eKeyDown even from
its HandleKeyDown() unless it's already has composition (because if it's
already had composition, any eKeyDown event except modifier keys should be
marked as "processed by IME" for compatibility with the other browsers).
For dispatching eKeyDown event only once for a native keydown event,
this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent()
to check whether eKeyDown event has already been dispatched for the event
and if it's not so, dispatches eKeyDown event.
Note that on macOS, dead keys are implemented as IME. However, we need to
treat dead keys as is. Therefore, if current keydown event is a dead keydown
event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching
eKeyDown event and its following eKeyDown event as "processed by IME".
MozReview-Commit-ID: 7epk8wdAznd
--HG--
extra : rebase_source : 4f4e23a8cc5005d8f0da3c35910eba30f8777e6b
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
TextInputHandler::HandleCommand() has two bugs. One is, checking whether
the key event has caused composition events. Even if it caused composition
events, we decided to dispatch keypress event for emulating native behavior.
Therefore, this patch removes the check of
|currentKeyEvent->CanDispatchKeyPress()|.
The other is, for making content handle dispatching keypress event as given
command, it needs to dispatch a keypress event whose key combination will
cause the command. However, HandleCommand() needs to set native key event
since content may not refer key combination for some edit actions, they just
refer command which is computed with native key event with NativeKeyBindings.
Therefore, even if current native key event has already caused dispatching
some events, HandleCommand() needs to set
WidgetKeyboardEvent::mNativeKeyEvent to current native key event for
NativeKeyBindings. Although it must be rare case, given key could be
not related to the command or not key could cause the command. In this
case, and perhaps in all cases, we should set all commands of dispatching
keypress event before dispatching it. Howevever, this needs more work,
so, we shouldn't do it in this bug to making it possible to uplift.
Therefore, this patch makes always set mNativeKeyEvent to current native
key event. So, just warning it when command is caused without native
key event.
MozReview-Commit-ID: 2MvDTw4ruAu
--HG--
extra : rebase_source : 02a4ca980530aa16fa0e1aecd6d18fa42873c1dc
extra : source : 1e3137db3fe9822f34b98d59fb928497caca466a
Let's make TextInputHandler::HandleCommand() handle other
commands which are caused by Backspace, Delete, Tab, ArrowUp,
ArrowDown, ArrowRight, ArrowLeft, PageUp, PageDown, Home, End
and Escape keys with various modifiers.
This patch makes Korean users can do most key operation in
editor even with composing Hangul character.
Note that this patch has a hack for cancelOperation: command.
The command is typically fired for Escape key press. However,
it's also fired for Command + Period. Unfortunately, this
behavior is really odd if subclass of NSResponder implements
|void cancelOperation:(id)sender|. If it's implemented,
Cocoa doesn't call its |void keyDown:(NSEvent)theEvent|.
Instead, it calls only |void doCommandBySelector:(SEL)aSelector|
and |void cancelOperation:(id)sender| when Command + Period is
pressed. Therefore, we cannot dispatch keydown nor keypress
event for this key combination if we implement it. Therefore,
this patch doesn't implement the method but handle it in
doCommandBySelector even though the super class of ChildView
cannot handle the command with this path.
MozReview-Commit-ID: 4hS23SiwNJv
--HG--
extra : rebase_source : 38ac1ea494b5f786ecd5c9327efbacd460b59faf
Currently, we handle insertNewline: of NSResponder with
TextInputHandler::InsertNewline(). However, its
implementation is useful for handling some other
commands. So, let's rename it to HandleCommand() and
make it take Command as its argument for handling
specific behavior of each command.
MozReview-Commit-ID: GgzQdTlVtYl
--HG--
extra : rebase_source : e1d1c8617897d29eb10ba62708e3549a77c6ee59
Extracts out the creation of an NSEvent from a WidgetKeyEvent in
TextInputHandler.mm into generic helper method. The helper is used by headless
to create a fake NSEvent to then build edit commands from key events.
Fixes:
- test_selectevents.html
- test_bug756984.html
- test_movement_by_characters.html
- test_movement_by_words.html
- test_backspace_vs.html
- test_bug1094000.html
- ... many key event tests
MozReview-Commit-ID: 1Jur5MHOrkp
--HG--
extra : rebase_source : fbe320aff8fd2e1b36f3b46e02336e9fc89c48d0
When Gecko started to support Cocoa widget, we needed to use NSInputManager.
That allowed applications to access only focused IME context. Therefore, commit
composition request handler for Cocoa is designed as handling asynchronosly if
it's requested when the window is not active or is being inactivated.
Additionally, the asynchronous handling isn't perfect. We hit some MOZ_ASSERT()
now in some places. E.g., in SelectedRange(), it doesn't assume that it's
called during deactive.
On the other hand, NSInputManager was alreay obsolete and we already stopped using it
(bug 810225). Instead, we're using NSTextInputContext and it allows applications
to access IME anytime. Therefore, if we make IMEInputHandler handles commit/cancel
composition requests synchronsly, that behaves same as the other platforms. So, we
can get rid of macOS specific issue completely.
MozReview-Commit-ID: X7aWmGq95x
--HG--
extra : rebase_source : a472a03e3ef6f424fe73c2d438b8326bed80278d
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
On macOS, we fall back eKeyPress event to native menu. Therefore, widget always requests a reply from remote process because it's difficult to check if the eKeyPress event will be sent to a remote process actually. If it's not sent to any remote processes, PresShell needs to dispatch the event into the DOM tree. Additionally, even if it's marked as "waiting reply from remote process", it needs to dispatch the DOM event in the main process first because we need to check if the key combination is reserved by chrome (if it's reserved, the eKeyPress event shouldn't be fired in the remote process).
Therefore, this patch makes EventStateManager::PreHandleEvent() resets the state when focused content isn't in any remote processes and the event's propagation hasn't been stopped.
Additionally, this patch makes PresShell::HandleEventInternal() checks WidgetEvent::PropgationStopped() with WidgetEvent::IsWaitingReplyFromRemoteProcess() before dispatching the event into the DOM tree.
MozReview-Commit-ID: FmgL3rCuQ8y
--HG--
extra : rebase_source : aa8d6b924fc78d1d9dd35a35c92976c35c758657
I found invalidateCharacterCoordinates in NSTextInputContext. It's available 10.6 and later.
Calling this API does NOT make visible candidate window follow window move nor something to change layout, though. But we should call it.
MozReview-Commit-ID: KbllLDwlMOz
--HG--
extra : rebase_source : 175377bf7dd703dcd304ffbb8648e350080c07fc
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
Due to bug 1358958, simply inserting a line breaker with composition events doesn't work as expected in HTML editor. Therefore, we need to dispatch "fake" Enter keypress event even if it's not handling Enter key actually or shouldn't dispatch keypress event anymore.
The method tries to dispatch Enter keypress event. If it's handling Enter key press actually and can dispatch keypress event normally, it dispatches Enter keypress event as-is. Otherwise, it tries to dispatch "fake" Enter keypress. It doesn't have Control, Option and Command key state for emulating to insert a line breaker. Additionally, its code value is not set to "Enter" because the fake key event isn't a physical key event.
If it cannot dispatch Enter keypress event, it dispatches composition events to insert "\n" even though it won't work in HTML editor.
MozReview-Commit-ID: 7AsJLKS8Tgz
--HG--
extra : rebase_source : 03a8628fd35eff404792691de0d2600f11ef1614
When typing Enter key when active keyboard layout is Korean IME and it has composition string, the composition string is committed and then, "insertNewline:" command is sent. However, TextInputHandler::DoCommandBySelector() consumes the command because the key event has already modified the composition string.
This patch makes TextInputHandler::DoCommandBySelector() consume the command if it's not handling keydown or neither dispatched keydown event nor dispatched keypress event (if it does) is consumed. Therefore, insertNewline:sender of nsChildView will be called later, then, it causes inserting a line break with a set of composition events.
MozReview-Commit-ID: Afr1FKZbUtL
--HG--
extra : rebase_source : 0c43986907553750b63bed0c95b3d5aaa1b16bea
UIEvent.isChar is not supported by the other browsers and the value isn't initialized any platforms except on macOS. So, the value isn't useful and we have no reason to keep it.
MozReview-Commit-ID: 4BLpo88gSZj
--HG--
extra : rebase_source : ca950f8cb618a0cadc99ba4c80b5a8df94a20f27
Bug 1343075 - 1a. Add TextEventDispatcherListener::GetIMEUpdatePreference; r=masayuki
Add a GetIMEUpdatePreference method to TextEventDispatcherListener to
optionally control which IME notifications are received by NotifyIME.
This patch also makes nsBaseWidget forward its GetIMEUpdatePreference
call to the widget's native TextEventDispatcherListener.
Bug 1343075 - 1b. Implement GetIMEUpdatePreference for all TextEventDispatcherListener; r=masayuki
This patch implements GetIMEUpdatePreference for all
TextEventDispatcherListener implementations, by moving previous
implementations of nsIWidget::GetIMEUpdatePreference.
Bug 1343075 - 2. Allow setting a PuppetWidget's native TextEventDispatcherListener; r=masayuki
In PuppetWidget, add getter and setter for the widget's native
TextEventDispatcherListener. This allows overriding of PuppetWidget's
default IME handling. For example, on Android, the PuppetWidget's native
TextEventDispatcherListener will communicate directly with Java IME code
in the main process.
Bug 1343075 - 3. Add AIDL interface for main process; r=rbarker
Add AIDL definition and implementation for an interface for the main
process that child processes can access.
Bug 1343075 - 4. Set Gecko thread JNIEnv for child process; r=snorp
Add a JNIEnv* parameter to XRE_SetAndroidChildFds, which is used to set
the Gecko thread JNIEnv for child processes. XRE_SetAndroidChildFds is
the only Android-specific entry point for child processes, so I think
it's the most logical place to initialize JNI.
Bug 1343075 - 5. Support multiple remote GeckoEditableChild; r=esawin
Support remote GeckoEditableChild instances that are created in the
content processes and connect to the parent process GeckoEditableParent
through binders.
Support having multiple GeckoEditableChild instances in GeckoEditable by
keeping track of which child is currently focused, and only allow
calls to/from the focused child by using access tokens.
Bug 1343075 - 6. Add method to get GeckoEditableParent instance; r=esawin
Add IProcessManager.getEditableParent, which a content process can call
to get the GeckoEditableParent instance that corresponds to a given
content process tab, from the main process.
Bug 1343075 - 7. Support GeckoEditableSupport in content processes; r=esawin
Support creating and running GeckoEditableSupport attached to a
PuppetWidget in content processes.
Because we don't know PuppetWidget's lifetime as well as nsWindow's,
when attached to PuppetWidget, we need to attach/detach our native
object on focus/blur, respectively.
Bug 1343075 - 8. Connect GeckoEditableSupport on PuppetWidget creation; r=esawin
Listen to the "tab-child-created" notification and attach our content
process GeckoEditableSupport to the new PuppetWidget.
Bug 1343075 - 9. Update auto-generated bindings; r=me
Because of conforming to UI Events KeyboardEvent key Values, when some modifier keys cause not inputting character, the KeyboardEvent.key value should be computed with removing all modifier state except glyph modifier keys.
When Control key is pressed, Cocoa fires odd key events typically. For example, characters isn't computed with same logic of UI Events KeyboardEvent key Values especially when Option key is pressed (see adding testcases for the detail).
Therefore, this patch makes TISInputSourceWrapper::InitKeyEvent() ignore both characters and charactersIgnoringModifiers at computing KeyboardEvent.key value when Control key is pressed and InsertText() isn't called.
On the other hand, this patch does NOT touch the path to compute KeyboardEvent.key when Command key is pressed. It should be changed in different bug because Command key behavior isn't so simple.
MozReview-Commit-ID: dMHgUEOnQw
--HG--
extra : rebase_source : 7a67c98d2bf6ca38c7e6ae9dcbad01020d9cea31
macOS oddly sends kVK_ISO_Section instead of kVK_ANSI_Grave when user types left key of Key1 only when the connected keyboard is ISO keyboard. On the other hand, macOS sends kVK_ANSI_Grave instead of kVK_ISO_Section when user types left key of KeyZ only when the connected keyboard is ISO keyboard. So, macOS swapps their key code values only when ISO keyboard is connected.
So, we should treat them as swapped when we compute KeyboardEvent.code value since Chromium treates them as swapped only when computing KeyboardEvent.code value too.
MozReview-Commit-ID: BYeFedydyR5
--HG--
extra : rebase_source : c3bf2a9fefe0e3e98a1955e829243f8fd7d1041a
Korean IME and some other simple IME may not use marked text at composing text. Such IME modifies composing character with InsertText() with aReplacementRange. Then, when
user types new character, such IME may replace the previous character with a call of InsertText() with aReplacementRange and insert the next character with additional call of InsertText() without aReplacementRange.
In this case, InsertText() ignores the call when the native keydown event is already caused composition events. However, we need to allow to dispatch keypress event for supporting to insert text even in such case.
This patch checks if inserting text is printable. If it's not a printable character such as U+000A at pressing Enter, keeping current behavior. Otherwise, dispatching keypress event instead.
MozReview-Commit-ID: 5NcCgXfvniO
--HG--
extra : rebase_source : f05db8655d623880cb658cef144d1e9fcdce8a2a
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode. Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*. Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.
MozReview-Commit-ID: 5cs4zQ061Lc
--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
Bug 1180564 dropped NSTextInput protocl implementation from ChildView but IMEInputHandler::SendCommittedText() still calls it via mView. Therefore, it fails to commit composition in widget level. Instead, we it should call insertText:replacementRange: of NSTextInputClient protocol.
Additionally, this patch adds a last resort path. If calling insertText:replacementRange: didn't commit composition in widget level, it calls TextInputHandler::InsertText() directly.
MozReview-Commit-ID: BZZypBqC0Mx
--HG--
extra : rebase_source : bef5612a933db3211400e9d8bd2848690de2d2e5
This patch changes it from |NS_IMETHOD| to |virtual nsresult|. The callsites
were a mix of checked and unchecked so using |MOZ_MUST_USE| didn't feel
appropriate.
--HG--
extra : rebase_source : 471ca43dcd565ddd1761d01df344c30e4e04a9ec
Currently, when InsertText() which is caused by a key press causes committing composition, it consumes keypress event. However, Korean 2-set IME calls InsertText() two times when there is composition and key press causes inserting another character next to the composition. In this case, current design ignores second InsertText() becuase keypress event is already consumed by the first InsertText() call.
For solving this issue safely, InsertText() should mark current key event as "dispatched composition event". Then, following InsertText() calls should cause composition events instead of keypress events since following event order is too odd:
1. keydown (currently not dispatched by TextEventDisaptcher)
2. compositionupdate
3. compositionend
4. keypress
5. keyup
with the new design this becomes:
1. keydown (currently not dispatched by TextEventDispatcher)
2. compositionupdate
3. compositionend
4. compositionstart
5. compositionupdate
6. compositionend
7. keyup
This is similar to Chromium, although, Chromium includes the second InsertText() call into the first composition, we need to fix it later due to risky.
MozReview-Commit-ID: GL42cU2WIL0
--HG--
extra : rebase_source : 2063c56166f6c9ccee25a74e1d29f94daa6b159c
Vietnamese Telex perhaps referes this result and change its behavior. When typying something, Telex starts composition on Chrome but may not behave so on Gecko.
Fortunately, Chromium just returns some attributes when validAttributesForMarkedText: of NSTextInputClient [1] but it doesn't return these styles when attributedSubstringForProposedRange: of NSTextInputClient is called (always returns non-styled plain text) [2]. Therefore, this patch does not touch IMEInputHandler::GetAttributedSubstringFromRange().
*1 <7d85f23cb0/content/browser/renderer_host/render_widget_host_view_mac.mm (2936)>
*2 <7d85f23cb0/content/browser/renderer_host/render_widget_host_view_mac.mm (3036)>
MozReview-Commit-ID: 1gPIiu4Qbud
--HG--
extra : rebase_source : 5336eea303ee157959941dcc4bda2a0931f1f532
Vietnamese Telex IME handles Backspace key immediately after inputting a word even when there is no marked text. At this time, it tries to replace the word with specific string. In such case, our editor shouldn't remove anything at handling the Backspace keypress event.
For avoiding this issue, InserText() should dispatch a set of composition for inserting the specified text into the range. Then, editor won't perform any action of the key.
Additionally, when a Backspace keydown tries to remove the last character of the word, Telex removes it with a composition. At this time, it creates dummy marked text "a" and make it empty later. So, in this case, InsertText() won't be called, therefore, we need to consume the Backspace keypress when SetMarkedText() is called for preventing removing the previous character of the word.
MozReview-Commit-ID: LfeEHDWn0cZ
--HG--
extra : rebase_source : 4753262ef16bc3875754ae38e966d8512947ad89
TextInputHandler::InsertText() dispatches a set of composition events when a key press causes 2 or more characters (Note that InsertText() is typically called only when IME is available because it's called via [NSResponder interpretKeyEvents]). However, this is different from the behavior of Windows. On Windows, NativeKey dispatches two ore more eKeyPress events in this case.
So, for consistency between platforms, TextInputHandler should dispatch eKeyPress events in such case.
MozReview-Commit-ID: EMvaL7sklKf
--HG--
extra : rebase_source : 0309d32d692a2394f53cd59216c6e774068e452b
The cause of bug 1309515 is, HandleKeyDownEvent() dispatches eKeyPress events even after InsertText() dispatches composition events via InsertTextAsCommittingComposition().
Therefore, this patch consumes the current key event after dispatching composition events.
Note that for consistency with Windows, InsertText() should use eKeyPress events rather than composition events at least in this case. However, changing the behavior has some risk. So, we should fix this bug with the safest hack for uplift.
MozReview-Commit-ID: 7FYR5N2lATe
--HG--
extra : rebase_source : 4485bd76a68567e8c20a84c2fbca78c626f592c5
IMEInputHandler shouldn't append any ranges to dispatch empty composition event since empty clause information may make TextComposition confused. Additionally, it doesn't need to append caret range because CompositionTransaction always sets caret at start of composition when the composition string is empty.
MozReview-Commit-ID: FkLWePXZGJf
--HG--
extra : rebase_source : ede2687618ca072b40ba6d21861f1fc97296c416
