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
ContentCacheInParent::mCompositionStart was set to ContentCacheInChild::mCompositionStart without any check. However, that's clearly wrong approach. For example, when the remote process handles some composition events after eCompositionCommit(AsIs) in the parent process, mCompositionStart is valid offset even after mWidgetHasComposition is set to false. Similarly, even after parent process sends eCompositionStart, the remote process may send invalid offset for mCompositionStart due to no composition in it.
For solving this issue, ContentCacheInParent should check mWidgetHasComposition.
If it's true and coming offset is valid, let's use it (even if mPendingCompositionCount is 2 or bigger since widget shouldn't use WidgetQueryContentEvent when there are some pending events).
If the coming offset is invalid but mWidgetHasComposition is false, let's use selection start instead because HandleQueryContentEvent() can work around selection start offset only.
Otherwise, i.e., mWidgetHasComposition is false, we should always set mCompositionStart to invalid offset.
MozReview-Commit-ID: IONU0Cbhpil
--HG--
extra : rebase_source : 05ae9eb0e7a0bb63b65be7a54103eb798274c8ff
When ContentCacheInParent receives content information from the remote process, it notifies TextComposition of the latest composition start offset in the remote process. However, the information may be older composition's, i.e., the composition was already committed in the process but is still being handled by the remote process. TextComposition shouldn't work with such obsolete information.
Note that TextComposition instance is created and destroyed when WidgetCompostionEvent is handled by IMEStateManager. Then, TextComposition instance guarantees that all following composition events for a composition are sent to same EventTarget (including TabParent). So, TextComposition is always synced with a composition in widget.
MozReview-Commit-ID: 78NuvpE2rPx
--HG--
extra : rebase_source : 3ffbf2513750f4b940bfedd19a8b191f28611115
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
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
ContentCache::TextRectArray::GetUnionRectAsFarAsPossible() should avoid crash by itself even if it's caller's bug. This makes parent process more stable, that is what one of the purpose of e10s is.
MozReview-Commit-ID: qKAfvm6eZw
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
To optimize copy of text rect array, we should use mozilla::Move. Also, after using it, we should mark is invalid result into SetEventResult
MozReview-Commit-ID: HH9H7DhK12
--HG--
extra : rebase_source : 4e02ece73583306c386597bc92e203fa147cfcbc
extra : histedit_source : 726621cdaf262b9d173ae19d505575f10563cc36
Use new event to update cotent process's cache.
MozReview-Commit-ID: CexTXW4knMQ
--HG--
extra : rebase_source : 525a8b0a1fe6ef533e06f76ac5156e264b158c70
extra : histedit_source : 2a8c46a64eb5c6a7a05adc28917422c488b2b1c4
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
In e10s mode and during focus is in a remote process, ContentCache handles WidgetQueryContentEvent instead of ContentEventHandler. Therefore, for supporting selection relative WidgetQueryContentEvent in e10s mode, we need to support it in ContentCache too.
MozReview-Commit-ID: L5d5ilmpetG
--HG--
extra : rebase_source : 46d646677ac0a5803398d18efbfd667bc3bf0c17
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
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
