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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
