While a TSFTextStore instance is being destroyed, TSFTextStore::Destroy() tries to commit remaining composition and notify TSF of destroying the view. At this moment, TSF/TIP may try to commit the composition or retrieve the contents with calling ITextStoreACP::RequestLock() but currently TSFTextStore disallows the requests to lock of them. This means that TSFTextStore never sends composition commit events asynchronously. Therefore, TextComposition may keep waiting remaining composition events but this causes odd behavior because they won't be fired.
For avoiding this issue, TSFTextStore should behave as normal even while it's being destroyed. Fortunately, if there is a composition, it always has mLockedContent and mSelection. So, it can compute expected results of TSF/TIP with them.
MozReview-Commit-ID: 2DSCGXXkLx1
--HG--
extra : rebase_source : 1dc5d08186bc50e7c3f1d9c5fe885ed855db8319
While TIP is handling a key message, TSFTextStore shouldn't release any TSF objects since it may cause hitting a bug of TIPs. Actually, MS-IME for Japanese on Windows 10 crashes when TSFTextStore is destroyed during composition because probably it accesses some destroyed objects to request to commit composition or query contents.
MozReview-Commit-ID: 9CTjHhAvG04
--HG--
extra : rebase_source : c34041962927795fe0d288aed10a96cf064b6243
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
It's not clear to me what NOTIFY_IME_OF_COMPOSITION_UPDATE means only from the name. For making the name clearer, this patch renames it to NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED and add some explanation to the definition.
MozReview-Commit-ID: 8ySYCNJ1Ytz
--HG--
extra : rebase_source : 3331b8f48e8b460c7f9b088064dcda9488f3403c
TaskbarTabPreview object will be released by GC. So when Disable method is called, window may already destroyed. So we should check whether window is destroyed.
MozReview-Commit-ID: MGz3JmDh37
--HG--
extra : rebase_source : 43a859cbcb729718b59745182c94ef3688a44f0f
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
We won't enable TSF mode on Windows XP nor Windows Server 2003 because they are already not supported by Microsoft itsef and installed TSF of them is too old and too buggy. Therefore, it's not worthwhile to support TSF on those environments anymore.
MozReview-Commit-ID: Cs85EvWie9K
--HG--
extra : rebase_source : 1fe36c28bf8e34de1172f589f336d1b55542bcd5
This reduces the blocklisting to the version of the AMD driver that
shipped with Windows 7 RTM. I've tested out that driver on hardware in
Toronto and everything seems to run fine.
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 special keyboard layout may use a key as a non-lockable modifier key even if the key isn't a non-lockable modifier key (e.g., CapsLock key of 'Neo' for German). In such case, KeyboardLayout class cannot initialize NativeKey::mCommittedCharsAndModifiers with actual input character properly because KeyboardLayout class doesn't support such eccentric keyboard layouts.
For preventing this issue, NativeKey should overwrite mCommittedCharsAndModifiers with following WM_CHAR message when it handles WM_KEYDOWN and should handle with following WM_CHAR message. However, we should ignore following WM_CHAR message if the character is a control character which shouldn't be inputted into focused text editor.
MozReview-Commit-ID: Ax01nnaRXek
--HG--
extra : rebase_source : fd802e868db8990481873ee8eb98375a50efa47a
rhunt
Kartikaya Gupta
Ralph Giles
Bob Owen
Randell Jesup
Jonathan Kingston
Jonathan Watt
Neil Deakin
Masayuki Nakano
Nicholas Nethercote
Milan Sreckovic
Makoto Kato
Mason Chang
Benoit Girard
Jeff Muizelaar
Keith Yeung
Jonathan Kew
David Anderson
kshitija
Milan Sreckovic
Sotaro Ikeda