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
Start offset of composition string is fixed when composition string becomes non-empty in focused editor. In other words, until composition string is fixed, composition start offset may be changed from selection start offset at dispatching compositionstart event. Especially, in e10s mode, pending keyboard events usually change composition start offset.
So, while there is composition, IMEHandler should use query events querying text rect or text content relative to actual start offset of composition string because native IME believes composition string at selection selection start when starting composition in the main process.
MozReview-Commit-ID: 3hinwozl9Ow
--HG--
extra : rebase_source : 4b79dd4f53aa51edfc78ff08c07a710160a8de01
TextInputHandler may dispatch keypress events after InsertText() is called if there was composition and it's committed by "current" keydown event. In that case, [NSEvent characters] may have the committing string. For example, when Opt+e of US keyboard layout started composition, Cmd+v causes committing the "`" character and pasting the clipboard text. Then, the "v" key's keydown event's |characters| is "`v". So, after InsertText() is called with "`", TextInputHandler shouldn't dispatch keypress event for "`" again. I.e., the KeyboardEvent.key value should be "v" rather than "`v".
For solving this issue, TextInputHandlerBase::AutoInsertStringClearer which is created at every InsertText() call should store the inserted string to TextInputHandlerBase::KeyEventState. However, for making the implemntation simpler, it should recode only when the inserting string is actually a part of [mKeyEvent characters]. Then, TextInputHandlerBase::KeyEventState can compute unhandled insert string at initializing WidgetKeyboardEvent.
So, finally, TextInputHandlerBase::InitKeyEvent() should be called via TextInputHandlerBase::KeyEventState::InitKeyEvent(). This ensures that all key events which may cause InsertText() calls are always initialized with unhandled string.
MozReview-Commit-ID: A9o8o9pV2XV
--HG--
extra : rebase_source : d99e9ab7633f45069d0a3940cc2b2b5ad859ea05
For making TextInputHandler MOZ_LOG* environment variables aware, TextInputHandler should use LazyLogModule.
MozReview-Commit-ID: 9La229BFaJ1
--HG--
extra : rebase_source : f18f689ea6522f3300c5411bcd9e49d4c31143e4
This is preparation. TISInputSourceWrapper is created before starting XPCOM, however, when its first instance is created, TextInputHandler.mm tries to log all keyboard layouts and IMEs which are installed into the system. This would be problem if it uses LazyLogModule because it's initialized at starting XPCOM.
MozReview-Commit-ID: DWz8TylL175
--HG--
extra : rebase_source : f377530f6325d6fcf8f90be5d6856972e9d312e5
TextEventDispatcher::MaybeDispatchKeypressEvents() dispatches keypress events with passed event's mKeyNameIndex and mKeyValue values. I.e., setting mCharCode doesn't make sense in this case. Similarly, mKeyCode value is also ignored (overwritten by 0) if it's printable key's key event (mKeyNameIndex == KEY_NAME_INDEX_USE_STRING).
MozReview-Commit-ID: bdBQOlVKTs
--HG--
extra : rebase_source : 0786fb72ce8cc5468bbf3d4d1e5cadaa4586837e
Currently, TextInputHandler::DispatchEvent() isn't used for WidgetKeyboardEvent nor WidgetCompositionEvent since TextEventDispatcher directly uses nsIWidget::DispatchEvent(). Therefore, old code hiding mouse cursor at dispatching eKeyPress event is never run in current mozilla-central since TextInputHandler dispatches eKeyPress events via TextEventDispatcher.
Additionally, it's not enough to hide mouse cursor only when widget dispatches eKeyPress events because if IME starts composition, eKeyPress event won't be fired until finishing the composition. So, I think that we should hide mouse cursor at receiving native keydown events. The event handler receives keydown events before IME handles them. Additionally, modifier key events which won't cause eKeyPress events are not using native keydown event handler, fortunately. So, I believe that it's the best place to do it.
MozReview-Commit-ID: 9dnpiVEV2Lx
--HG--
extra : rebase_source : fd42be85f93fed9e38eeece2cbdbfb7ad45555ba
For making our code clearer by the stronger type check, we should change the anonymous enum for NS_TEXTRANGE_* to enum class whose name is "TextRangeType" and whose type is "RawTextRangeType" which is an alias of uint8_t.
Additionally, this also adds some utility methods for them.
Note that some lines which are changed by this patch become over 80 characters but it will be fixed by the following patches.
MozReview-Commit-ID: 76izA1WqTkp
--HG--
extra : rebase_source : 27cd8cc8f7f8e82055dbfe82aba94c02beda5fa4
This method is for old NSTextInput API and unused now.
MozReview-Commit-ID: thcbEExH58
--HG--
extra : rebase_source : 7d9f665d867366990c5aac5a54555cc2c3483828
For e10s, we send Bidi keyboard information to content process. We should add utility method to share it for all platforms.
MozReview-Commit-ID: JJX26OivQvt
--HG--
extra : rebase_source : fe6d000080e3fa993a27d570c703e93f23439520
And mCharCode shouldn't be compared with NS_VK_*, nsIDOMKeyEvent::DOM_VK_*. Additionally, when it's compared with a character constant, cast isn't necessary.
MozReview-Commit-ID: JMT614copjG
--HG--
extra : rebase_source : 69ee3c589e5a71c814ec9a40ac3aab39c789c11d
And also WidgetKeyboardEvent::mKeyCode should be compared with NS_VK_* rather than nsIDOMKeyEvent::DOM_VK_*.
MozReview-Commit-ID: IKjQ1nr8XYe
--HG--
extra : rebase_source : 83125cd2523f6b70759f621470aad23b00aae8ae
Some IME handles mouse event by handleEvent method of NSTextInputcontext. So we should call it on mouse event for IME
MozReview-Commit-ID: 6lyXCpOJ3yr
--HG--
extra : rebase_source : a180e0750a2f40838cf24d2985638f96899cf2d4
extra : histedit_source : 84ea9a9b113b33d8dc982b855e2271931c1084f9
When a plugin has focus, TextInputHandler shouldn't send native keydown event to interpretKeyEvents of NSView. However, it should dispatch keypress events because shortcut key handlers wait following keypress event.
MozReview-Commit-ID: HpG108s2Rde
--HG--
extra : rebase_source : de0b76f0d1e78092f6e9cdcece22ab47a0810621
Stephen A Pohl
Masayuki Nakano
Jim Chen
Tom Tromey
Nicholas Nethercote
Xidorn Quan
Michael Layzell
Makoto Kato
Jonathan Watt