Oddly, in some complicated web apps, `IMEContentObserver` may get selection
change notifications **after** sending a text change notification to IME.
However, I cannot reproduce it with simple testcase. Therefore, the new test
does not test the original issue, but the approach of this patch must avoid
regressions of this special case handling.
Differential Revision: https://phabricator.services.mozilla.com/D137522
Currently, `mSelection` is cached only when `mText` is some, text rects are
cached only when `mSelection` is cached. However, as far as widget can work
with IME, it should cache content as far as possible. Therefore, this patch
makes it keep querying content data even after something fails.
Differential Revision: https://phabricator.services.mozilla.com/D137431
Even after applying this patch, it still returns error when queried with a
relative offset from selection and only when there is no composition string.
However, this shouldn't cause any problem because in this case, widget should
not try to query content with relative offset.
Differential Revision: https://phabricator.services.mozilla.com/D137430
It's intended to indicate whether the selection is collapsed or not, but it can
be referred by other members, there is no reasonable user and the name makes
developers confused.
Differential Revision: https://phabricator.services.mozilla.com/D137422
Sorry for this big patch.
This makes `WidgetQueryContentEvent::Reply` is stored with `Maybe` to get
rid of `WidgetQueryContentEvent`. And `Reply` stores offset and string
with `Maybe` and ``OffsetAndData<uint32_t>`, and also tentative caret offset
with `Maybe`. Then, we can get rid of `WidgetQueryContentEvent::NOT_FOUND`.
Note that I tried to make `OffsetAndData` have a method to create `NSRange`
for cocoa widget. However, it causes the column limit`to 100 or longer
and that causes unrelated changes in `TextEvents.h` and `IMEData.h`.
Therefore, I create an inline function in `TextInputHandler.mm` instead.
Differential Revision: https://phabricator.services.mozilla.com/D98264
Usually, IME sets selection and considers candidate list position at starting
new composition. However, Apple Japanese IME sometimes consider the candidate
list position at retrieving the character rects before setting selection.
Therefore, we need to store last commit string's character rects, but don't
need to store it in long time because Kakutei-Undo is supported by Japanese
IMEs and they work only immediately after committing a composition. E.g.,
after moving caret, it won't be available.
Depends on D97838
Differential Revision: https://phabricator.services.mozilla.com/D97839
Currently, it manages the composition start offset with `uint32_t` and setting
it to `UINT32_MAX` when there is no composition. But this is now rewritable
with `Maybe<uint32_t>` for easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D97838
Immediately after committing composition, i.e., still remote content is
handling the commit, `ContentCacheInParent` does not think that it still
has composition, but `TSFTextStore::GetTextExt()` tries a query whose offset
is relative offset from the last composition start offset and then,
`ContentCacheInParent` solves it with selection start (typically, the last
composition end offset). Therefore, this may cause returning error from
`GetTextExt()` and some TIP may fail to do something for next typing.
This patch makes `TSFTextStore::GetTextExt()` consider whether it'll query
content with relative offset from last composition start or selection start,
from `TextEventDispatcher::IsComposing()` result rather than
`TextEventDispatcher::IsHandlingComposition()` since the former means whether
there is composition in the chrome process, but the latter is there is
composition in focused process, and `ContentCacheInParent` state matches the
former.
Depends on D97270
Differential Revision: https://phabricator.services.mozilla.com/D97392
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Currently, ContentCacheInParent uses selection when it handles query content
event whose input offset is relative one after sending eCompositionCommit(AsIs)
event but it's not yet handled by the remote process. However, in this case,
selection may not be modified with committed string.
So, when mPendingCommitCount is not 0, ContentCacheInParent should compute
absolute offset with the latest composition string information. For doing
this, it needs to keep storing mCompositionStart until eCompositionCommit(AsIs)
is handled in the remote process actually.
MozReview-Commit-ID: 2Dc69HNIbvh
--HG--
extra : rebase_source : 4be432ad363022e4b3f2e3c82c8d229dc9af889d
After fixing bug 1420849, remote process started to ignore composition events
after it synthesizes eCompositionCommit event after requesting to commit
composition. However, remote process still keeps returning composition events
when it receives from the main process. So, if the main process has already
sent eCompositionCommit(AsIs) event when it's requested to commit composition
from the remote process, ContentCacheInParent::OnEventNeedingAckHandled()
receives both eCompositionCommitRequestHandled and eCompositionCommit(AsIs)
events for *a* composition. Therefore, mPendingCompositionCount may be
decremented twice for a composition. This causes hitting MOZ_DIAGNOSTIC_ASSERT.
So, ContentCacheInParent need to manage if sent composition events are ignored
or not. Then, ContentCacheInParent::OnEventNeedingAckHandled() stops
decrementing mPendingCompositionCount when it receives eCompositionCommit(AsIs)
events which are ignored by the remote process.
This patch manages it with |mIsChildIgnoringCompositionEvents| and changes
|bool mIsPendingLastCommitEvent| to |uint8_t mPendingCommitCount| for
making ContentCache be able to manage multiple pending commit events if
its remote process is too busy.
MozReview-Commit-ID: CYQDeZXl7TJ
--HG--
extra : rebase_source : 6de1e2f1302d556d45d19c73b4d1ea3f86b65373
When ContentCacheInParent::RequestIMEToCommitComposition() returns true,
the remote process will synthesize eCompositionCommit event. This causes
destroying TextComposition event in the remote process (by
IMEStateManager::DispatchCompositionEvent()). Then,
IMEStateManager::DispatchCompositionEvent() will recreate new TextComposition
instance when it receives new composition event. Then, it may request
to commit composition to the main process via PuppetWidget accidentally.
So, after PuppetWidget::RequestIMEToCommitComposition() synthesizes
eCompositionCommit, PuppetWidget should discard following composition events
until it receives eCompositionStart since they are unnecessary for the content
and they are for the old composition, i.e., outdated events.
MozReview-Commit-ID: BNRcoYxABpd
--HG--
extra : rebase_source : caea469afeed8cc373aeca33199ac0d570052569
ContentCacheInParent::mPendingCommitLength is never initialized until it
receives eCompositionCommit(AsIs) event from widget or receives the latest
content from the remote process when there is a composition.
The bug is, immediately after dispatching eCompositionStart and first
eCompositionChange event, MS Pinyin tries to query the character at caret,
but ContentCacheInParent::HandleQueryContentEvent() tries to resolve
related position of an eQueryTextRect event with the uninitialized
mPendingCommitLength. Therefore, the query almost always fails and MS Pinyin
gives up to show its candidate window.
This patch just initializes the member with 0.
MozReview-Commit-ID: JyYNqi8hoTa
--HG--
extra : rebase_source : bdc504f83abdbb21e11ea69290908ed501e9a65f
For protecting main process, we should stop crashing main process in release
build even when we detect our bug. However, we should keep crashing with
MOZ_DIAGNOSTIC_ASSER which is enabled only on Night and Developer Edition.
MozReview-Commit-ID: 5BQ46IFzXXj
--HG--
extra : rebase_source : 1a894bb23b6b9f386b19eba95d14cd8db80fb2c6
Now, TextComposition::RequestToCommit() manages if it has already requested
IME to commit or cancel composition and this is important for redundant
requests. Therefore, ContentCacheInParent::RequestIMEToCommitComposition()
shouldn't call nsIWidget::NotifyIME() directly.
MozReview-Commit-ID: 69VpgyK9Jk5
--HG--
extra : rebase_source : 5b86c11669c7a69ceb0a2af155765834621ee968
This is a simple bug of ContentCacheInParent. When
ContentCacheInParent::RequestIMEToCommitComposition() returns true,
PuppetWidget::RequestIMEToCommitComposition() will send
eCompositionCommitRequestHandled pseudo event message back to the main process.
This causes counting down mPendingEventsNeedingAck in
ContentCacheInParent::OnEventNeedingAckHandled(). Therefore, in the normal
path, ContentCacheInParent::OnCompositionEvent() increments it for receiving
the pseudo event message.
However, if the tab parent has already lost focus,
RequestIMEToCommitComposition() returns true without requesting native IME to
commit composition. So, ContentCacheInParent::OnCompositionEvent() cannot
increment mPendingEventsNeedingAck for coming
eCompositionCommitRequestHandled. Therefore, RequestIMEToCommitComposition()
needs to increment mPendingEventsNeedingAck by itself when it won't request
IME to commit composition but it returns true.
MozReview-Commit-ID: 4Alwfy8avB
--HG--
extra : rebase_source : 2588221568440beecc2b992910fa53729b8abe1c
This is a follow up patch of bug 1408086. The previous patch starts to append
log of 2 sets of composition events to app notes of crash report when
ContentCacheInParent::OnEventNeedingAckHandled() meets unexpected state and
crash itself. However, now, we know the unexpected state occurs when TabParent
receives eCompositionCommitRequestHandled message from its remote process.
The event comes when ContentCacheInParent::RequestIMEToCommitComposition()
returns true. So, we need to know what occurs in the method before the crash.
This patch defines each case of RequestIMEToCommitComposition() with an enum
class, RequestIMEToCommitCompositionResult and make
RequestIMEToCommitComposition() append one of its value to the array.
Then, ContentCacheInParent discards unnecessary log of this when it discards
log of old composition events. Finally, appends the log to the app notes of
crash report.
MozReview-Commit-ID: 9sJyl4SvUXu
--HG--
extra : rebase_source : f7e90a157d3819523d3d8932d9f8af5d94e2db1f
We have a lot of crash reports in OnEventNeedingAckHandled() due to unexpected
state (hit MOZ_RELEASE_ASSERT). However, it's unclear what occurs and we're not
sure there are how many cases to crash because the stack trace is too short
because the method is called when TabParent receives event handled message from
the remote process. I.e., it doesn't show what happens immediately before the
crash.
This patch puts 2 sets of composition events to app notes of crash report when
it needs to crash. This *might* make damage to the performance. If so, after
fixing the crashes, we should back this out. Fortunately, we have a lot of
reports from either Nightly or Beta.
MozReview-Commit-ID: 9tDrEIf72MG
--HG--
extra : rebase_source : 523c183466740e08d6c8cc3836b6b52310c1e53a
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
If ContentCacheInParent::RequestIMEToCommitComposition() returns true after its TabParent has already sent eCompositionCommit(AsIs) event, ContentCacheInParent::OnEventNeedingAckHandled() will receive both eCompositionCommit(AsIs) and eCompositionCommitRequestHandled for a composition. Then, that causes making mPendingCompositionCount decreased twice. That causes the crash.
So, even if its TabParent already lost focus, it should return false after its TabParent sent eCompositionCommit(AsIs).
MozReview-Commit-ID: 6OylQtc8kgC
--HG--
extra : rebase_source : 9d8f2ab2b25f129ddbca75fcc8fb4bc7c3a96e56
Due to the fix of bug 1376424, ContentCacheInParent::FlushPendingNotifications() may be called when aWidget is nullptr. In this case, it doesn't need to do anything. So, it should ignore the call.
MozReview-Commit-ID: Fj3J76v6Xuk
--HG--
extra : rebase_source : 18c722628a3ae8fa50beca3908d5e732cec404d9
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
The problem is, only when requesting IME to commit or cancel composition is handled synchronously, TabParent does not send the dispatched eCompositionCommit(AsIs) event to the remote process. Therefore, TabParent (and ContentCacheInParent) never receives the message from the remote process.
This patch makes TabChild notifies TabParent of eCompositionCommitRequestHandled special event message after TabChild dispatches eCompositionCommit into the DOM tree. Then, ContentCacheInParent should decrease mPendingCompositionCount and mPendingEventsNeedingAck as usual composition event messages.
MozReview-Commit-ID: 7ec5HPiE687
--HG--
extra : rebase_source : a9366abf6f8feec2d6ac639fd37f5b5c6ddd9586
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
Masayuki Nakano
Nika Layzell
Narcis Beleuzu
Simon Giesecke
Bogdan Tara
Emilio Cobos Álvarez
Henri Sivonen
Ryan Hunt
Sylvestre Ledru
Milan Sreckovic
Gabriele Svelto
Chris Peterson
Kartikaya Gupta