Returing TS_E_NOLAYOUT while ATOK shows suggest window causes moving suggest window to odd position. This causes flicking the window. Therefore, we shouldn't return TS_E_NOLAYOUT in this case. In this case, ATOK queries whole rect of composition string. So, we can return TS_E_NOLAYOUT for other cases.
MozReview-Commit-ID: LBZQPFjqQgx
--HG--
extra : rebase_source : 27fda6739562dfaf89efd1d2cd9cac03610846ba
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
ATOK 2011 - 2016 check focused window class name if it's a Mozilla's window. Then, they refer native caret position for deciding its popup window. However, future ATOK release will stop referring native caret position on Mozilla's windows. Therefore, we can stop creating native caret for new ATOK.
MozReview-Commit-ID: HPh3DVqTkvc
--HG--
extra : rebase_source : 00b75b75df2ba1bace328cfb75172c78c6bea29d
ContentEventHandler and ContentCache allow 0 length text rect query. However, if selection is collapsed and caret is at the queried offset, they return actual caret rect whose height (in horizontal layout, width in vertical layout) may be different from actual font height of the line.
Therefore, it may cause "dancing" of candidate or suggest window of TIP. Therefore, we should query text rect at least 1 length. Then, even if there is no character at the offset, they computes caret rect with previous character.
MozReview-Commit-ID: 9LprWTPyMsF
--HG--
extra : rebase_source : c0dfad35bcc1961948e21c8b50b21cdf218ba966
When TSFTextStore::GetTextExt() needs to hack the queried range, it means that the method should not return TS_E_NOLAYOUT since the hacks are implemented for that. However, currently, if hacked offset is still at modified offset, it returns TS_E_NOLAYOUT. This causes flicking IME windows.
For avoiding that, this patch adjust the hacked offset to the last unmodified offset or offset of the start of composition string. Even if there is no modified character in the composition string, we can use the offset since even if there is no character at the offset, query content event returns caret rect at the offset and if there are old characters, it returns its rect which the user still see. So, the rect at the composition start is useful until layout is modified actually.
MozReview-Commit-ID: 4zo9mF3m9u9
--HG--
extra : rebase_source : 6dd15b62422b85edf04150f15caaca45d7bc3600
Currently, TSFTextStore::GetTextExt() checks the offset with mContentForTSF.MinOffsetOfLayoutChanged() as "the first offset of modified characters", however, TSFTextStore::Content::IsLayoutChangedAfter() needs actual offset - 1. This is really not useful. So, we should rename it to IsLayoutChangedAt() and check the offset simply.
Additonally, TSFTextStore::GetTextExt() should set previous offset of MinOffsetOfLayoutChanged() when it hacks the queried range for avoiding bug of active TIP since setting offsets to the result of MinOffsetOfLayoutChanged() means the offset's layout is always not computed yet.
MozReview-Commit-ID: 182BMuubtFc
--HG--
extra : rebase_source : 65355fc4e488592f59dfc0b44806571ff0b87cd6
In CreateAndSetFocus(), SetInputScope() is called *after* setting focus to the context. At this time, Google Japanese Input retrieves InputScopes. Therefore, TSFTextStore returns IS_DEFAULT. But after that, Google Japanese Input tries to retrieve InputScopes after every notification (in this case, a call of ITextStoreACPSink::OnLayoutChange()). Then, we return IS_URL due to set after returns IS_DEFAULT.
This is actually our fault, but according to the other TIPs, Google Japanese Input shouldn't commit composition at detecting an InputScope change, though.
MozReview-Commit-ID: 2tPlcEA0MI0
--HG--
extra : rebase_source : 0956bf79ed84b7b901b6314bb483e40436d49751
I'm still not sure what we should do in this case, though.
If mContentForTSF is initialized and there are some unknown changes in actual contents, i.e., not caused by composition of the active TIP itself, we cannot set selection range properly in some cases.
For example, if TSF tires to set non-empty selection range but the range has been removed by web apps.
For now, let's try to return E_FAIL in such case because that should occur at reconversion or something immediately after previous content change not caused by previous composition. If TIP does nothing in this case, user can retry with same operation after all pending text changes are notified to TSF.
MozReview-Commit-ID: 9unrNVeC1tW
--HG--
extra : rebase_source : 061e48e014a38b2a442bf736031febfe0b1e333d
Same as selection change notification, text change notification shouldn't be notified to TSF while there is cachec content because neither TSF nor TIP may allow to change text by web applications during keeping storing cached content.
This patch makes TSFTextStore stores and merges text changes until MaybeFlushPendingNotifications() is called and there is no cached content.
MozReview-Commit-ID: 9fj0GREbX18
--HG--
extra : rebase_source : 71db6b4b9f0ab979313398a8014bde992183e019
TSFTextStore shouldn't notify TSF of selection change until MaybeFlushPendingNotifications() is called and there is no cached content because while there is cached content, neither TSF nor TIP may allow to change selection by web applications. Therefore, ITextStoreACP::GetSelection() and similar methods need to use mSelection instead of actual selection in the focused editor. Therefore, TSFTextStore should store selection change data during keeping storing content cache and notify it when the cache is cleared. So, when TSFTextStore notifies TSF of selection change, TSFTextStore needs to update mSelection to the actual selection which is stored in mPendingSelectionChangeData.
MozReview-Commit-ID: 8ZWASzu7Znv
--HG--
extra : rebase_source : 0bfaef0bbffd72d661c84992cc8c842215e3407a
This patch stop clearing mContentForTSF at unlocking the document because we should keep it until active composition is committed. If so, TSF/TIP won't be confused by content changes by JS. So, this is important for a11y of TIP users in some complicated websites like GoogleDocs, Facebook, etc.
Note that this patch doesn't work well without following patches. We need to stop notifying TSF of selection changes and text changed while mContentForTSF is valid.
MozReview-Commit-ID: 9QOGZxdYU3I
--HG--
extra : rebase_source : 19a6eeb2357825643497caf5a5298c55f08a0670
I think that we can drop nsIMEUpdatePreference::DontNotifyChangesCausedByComposition(), i.e., nsIMEUpdatePreference::NOTIFY_CHANGES_CAUSED_BY_COMPOSITION because it's now used only by TSFTextStore but TSFTextStore ignores if SelectionChangeDataBase::mCausedByComposition or TextChangeDataBase::mCausedOnlyByComposition is true (for supporting async changes in e10s mode). So, only issue is, dropping the flag might cause increasing computing TextChangeData cost during composition in TSF mode. However, now, it's already enough fast and even if it'd cause performance regression, we could add a hack with TextComposition's offset information. Therefore, we don't need to worry about the performance regression so seriously.
MozReview-Commit-ID: HNT3G4isONj
--HG--
extra : rebase_source : 164231023aa2a17ceab94d92fb49ba0a00dab429
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
TSFTextStore should use insertion point relative query for getting character rect and caret rect while there is a composition because in such case, TSF must want to query a part of or around the composition. Therefore, it makes sense to use insertion point relative query since it adjusts the offset with the latest content information.
MozReview-Commit-ID: IVjZ4zqFUkr
--HG--
extra : rebase_source : e535ffa2c7649f16ffe7f761a9ed01b061848aa7
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
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
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
TSFTextStore::sEnabledTextStore is a static variable to grab a reference to focused TextStore instance. So, this may be changed by accidentally during a call of instance methods of TSFTextStore. Then, focused TextStore may be destroyed during running a method and crash when it accesses a member variable.
For avoiding this crash, static methods which call a method of sEnabledTextStore should create an independent RefPtr to it before calling the method.
MozReview-Commit-ID: 51Sor1LdABr
--HG--
extra : rebase_source : ec6eb378eb4d8b323e8ad28079f27220cae0d0d8
