Bug 1309515 part.2 TextInputHandler::InsertText() should consume current key event when it dispatches composition events r?m_kato
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
--- a/widget/cocoa/TextInputHandler.mm
+++ b/widget/cocoa/TextInputHandler.mm
@@ -2185,16 +2185,24 @@ TextInputHandler::InsertText(NSAttribute
DispatchEvent(deleteCommandEvent);
NS_ENSURE_TRUE_VOID(deleteCommandEvent.mSucceeded);
// Be aware! The widget might be destroyed here.
return;
}
if (str.Length() != 1 || IsIMEComposing()) {
InsertTextAsCommittingComposition(aAttrString, aReplacementRange);
+ // For now, consume keypress events when we dispatch the string with a
+ // composition for preventing to dispatch keypress events later.
+ // TODO: When there is a currentKeyEvent, we should dispatch keypress
+ // events even if the length of the string is over 1.
+ if (currentKeyEvent) {
+ currentKeyEvent->mKeyPressHandled = true;
+ currentKeyEvent->mKeyPressDispatched = true;
+ }
return;
}
// Don't let the same event be fired twice when hitting
// enter/return! (Bug 420502)
if (currentKeyEvent && !currentKeyEvent->CanDispatchKeyPressEvent()) {
return;
}