Currently, all widgets request selection change notifications to IMEContentObserver. Additionally, IMEContentObserver needs to listen selection changes for caching latest selection for eQuerySelectedText. Therefore, it doesn't make sense to keep defining nsIMEUpdatePreference::NOTIFY_SELECTION_CHANGE.
If widgets didn't need selection change notifications, they could just ignore the unnecessary notifications.
Note that all widgets don't need selection change notifications if a plugin has focus and IMEContentObserver cannot observe selection changes in the plugin. Therefore, if IMEContentObserver is initialized with a plugin, it shouldn't listen selection changes (and doesn't need to notify widgets of selection changes).
MozReview-Commit-ID: FOVFFgA2nOz
--HG--
extra : rebase_source : 3e16d5023835f99f82934e754d2e7db70474f9ee
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
The new names Create{,PreservingTransform}OrNull() better communicate that
these functions (a) do object creation, and (b) are fallible.
--HG--
extra : rebase_source : a36bd9a2bcdfae281868959403f811f2bc690ad4
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
When calling showDefinitionforAttributedString on OSX 10.11, it always return error due to the following exception.
Exception: decodeObjectForKey: class "TitlebarAndBackgroundColor" not loaded or does not exist
So before calling it, we set temporary color value, then restore color after calling it.
MozReview-Commit-ID: 1YeY6X1W6AV
When calling showDefinitionforAttributedString on OSX 10.11, it always return error due to the following exception.
Exception: decodeObjectForKey: class "TitlebarAndBackgroundColor" not loaded or does not exist
So before calling it, we set temporary color value, then restore color after calling it.
MozReview-Commit-ID: 1YeY6X1W6AV
--HG--
extra : rebase_source : 1bfafdb24f7d6df0ad2552b786b8af84b71cc28a
