Requests to commit/cancel composition came from remote process with sync message. So, it may be too late. E.g.,
* If the process already sent new composition start but is not handled by the remote process yet.
* If the process already send commit message but it's not handled by the remote process yet.
* If focus was already moved to different process.
In the former 2 cases, the remote process should wait eCompositionCommit(AsIs) events for clearing TextComposition. Therefore, the requested should be treated as it's handled asynchronously.
In the last case, the remote process should commit composition with latest composition string in the main process because if the remote process commits composition with "current" composition string in it, user may lost some inputted text.
MozReview-Commit-ID: 18BUoZZq7HS
--HG--
extra : source : fd1585ad670a87d8b1ef8908931f3d4037751475
IME should receive notifications and requests only from proper process. E.g., IME shouldn't commit composition by a request which came from previous focused process.
This patch makes that IMEStateManager::NotifyIME() takes pointer to TabParent optionally. If the request or notification came from remote process, it should be non-nullptr. Then, this makes it ignore notifications and requests from unexpected process.
Note that this patch also touches some gfx headers because they use |ipc::| but compiler is confused at the ambiguousness between |mozilla::ipc::| and |mozilla::dom::ipc::|.
Finally, this patch changes the NS_ASSERTION in IMEHandler::OnDestroyWindow() to MOZ_ASSERT because the orange caused by the NS_ASSERTION was not realized since there was already an intermittent orange bug caused by different NS_ASSERTION.
MozReview-Commit-ID: 9CgKXQRJWmN
--HG--
extra : source : f3b5711908870c5e0e852a399a07e0ae721a12f1
When IME commits composition and restarts composition immediately, query event with relative offset doesn't work as expected until the commit is handled in the remote process.
Therefore, this patch makes ContentCacheInParent store the last commit string length until it's handled in the content. Note that ContentCache doesn't need to store all commit string lengthes which have not been handled in the remote process yet because it's important and possible to return next character of commited composition only when there are not 2 or more pending compositions. Even if there are, i.e., the remote process is too busy, ContentCacheInParent doesn't have necessary character rect.
MozReview-Commit-ID: 8gBr8kO4JcF
--HG--
extra : rebase_source : f4748928c07ee284a5c312b89291e3a4fb8f790d
TextComposition in the main process is destroyed when the main process sends eCompositionCommit(AsIs) to focused remote process. Therefore, ContentCacheInParent::mCompositionPendingCount is never 2 or more now.
It may cause ContentCacheInParent::Assign() setting older composition's start offset to current composition's start offset in the main process.
For making uplift the following patch easier, the wrong patch should be backed out first.
MozReview-Commit-ID: IHWc7qZBQtc
--HG--
extra : rebase_source : d3936fa82ed670217b711d15bbb0201a8741501b
ContentCacheInParent::mPendingCompositionCount is now managed with composition events which TabParent received. However, TextComposition doesn't dispatch composition events after coming request to commit active composition. Therefore, composition is committed forcibly in a remote process over 255 times, the main process crashes.
It's the safest way to use TextComposition to manage ContentCacheInParent::mPendingCompositionCount.
MozReview-Commit-ID: DEhzYcK1zcW
--HG--
extra : rebase_source : a47891b1d620bbe4e380e73134ec6da5d21f4ea9
When ContentCacheInParent receives eCompositionStart, it temporarily sets mCompositionStart to selection start offset. However, if there is a composition in the remote process, the selection start is caret position in the composition string. Therefore, it's not useful information. Instead, the composition start offset should be used because around there are a lot of information.
For that, ContentCacheInParent should always store compostion start offset in the remote process with mCompositionStartInChild even if mWidgetHasComposition is false. And when it receives eCompositionStart, mCompositionStart should be set to mCompositionStartInChild.
MozReview-Commit-ID: DksPNEsi6Ec
--HG--
extra : rebase_source : bcf2946273d24a4c37c33fa18a321660115e3fb6
If the remote process is busy or user restarts composition too quickly, there could be 2 or more compositions in ContentCache. For managing such case, ContentCacheInParent should manage the pending composition count which is increased at dispatching eCompositionStart event to the remote process and decreased at receiving eCompositionCommit(AsIs) event from the remote process.
MozReview-Commit-ID: KbTsK20NEZD
--HG--
extra : rebase_source : 428b14646ccde190b446b5c820e0e84866a855f2
For making the meaning of ContentCacheInParent::mIsComposing clearer, let's rename it to mWidgetHasComposition. It becomes true when the parent process sends eCompositionStart to the remote process and false when the parent process sends eCompositionCommit(AsIs). So, it represents if the widget (i.e., the native IME handler in the chrome process) has composition.
MozReview-Commit-ID: 5k05IXMgJxw
--HG--
extra : rebase_source : 69be70f22fb9b9dd6125ce390026b0740bd6de8f
ContentCache::TextRectArray's end offset is computed as start offset + its length. Therefore, end offset is the last offset in the range + 1. So, IsOverlappingWith() shouldn't return true only when end offset is overlapped with given range.
That means that when TextRectArray doesn't have rects, i.e., mRects is empty, IsOverlappingWith() always returns false. And when TextRectArray has one or more rects, IsOverlappingWith() should compare its range and given range without "=".
MozReview-Commit-ID: JxNPcEwikjR
This patch makes ContentCache store previous character's rect of selection anchor and selection focus because if caret is at end of a line, IME may query the last character of the line.
MozReview-Commit-ID: 5X1K8KtrYfl
--HG--
extra : rebase_source : 403e4c993b48a832d50b4f44738c5b5c6d5ce085
This must be able to reproduce with some IMEs which creates 0 length composition string. In such case, mTextRectArray isn't available, but mTextRectArray.GetUnionRectAsFarAsPossible() always assumes that it's valid and has at least one rect. Therefore, it can meet this crash.
Therefore, this patch makes that ContentCacheInParent::GetUnionTextRects() not use mTextRectArray when it's not valid nor doesn't have rects.
MozReview-Commit-ID: 2yLMo4lxI3Z
--HG--
extra : rebase_source : 3ef3f2c6ba6473fd3eefbd5c909c1ef6c51c76af
ContentCache may store composition string's rects which are inserted by one or more older composition event. Even in such case, native IME, especially TIP of TSF, expects non-empty rects.
Therefore, if native IME handler uses "insertion point relative query", ContentCache should return non-empty rect as far as possible. For example, even if query offset or range is not in its rect array of composition string, ContentCache should adjust the offset into the stored range.
MozReview-Commit-ID: 7hcIqxOWFk2
--HG--
extra : rebase_source : 8b1572e01cc56e5596ffba4eac0f7d5818b85a89
Masayuki Nakano