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
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
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
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
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
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
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
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
