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
This is regression by bug 1672095. `GeckoEditableSupport` expects that
NOTIFY_IME_OF_BLUR is always sent. I would like to allow this even if
IME content observer is being destroyed.
To reproduce this, we have to lost application focus, I cannot write
geckoview-junit test.
Differential Revision: https://phabricator.services.mozilla.com/D94414
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
The telemetry probe was added in bug 1506434, and it's not necessary anymore
because of the event in the default group was completely disabled in
bug 1288640 (Gecko 65).
Therefore, we can get rid of the pref, and we can take back a room for a
bool member in `nsPIDOMWindowInner` for new telemetry probes which need
to know whether a specific event listener has been added or not.
Depends on D92395
Differential Revision: https://phabricator.services.mozilla.com/D92397
In a follow-up commit a new `ComparePoints` method with cleaner
arguments and return value will be added.
Differential Revision: https://phabricator.services.mozilla.com/D55295
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
For avoiding confusion between API of `nsRange` and `StaticRange`, I'd like to
rename `nsRange::CreateRange()` to `nsRange::Create()` because
`StaticRange::CreateStaticRange()` is too long name and
`StaticRange::CreateRange()` sounds odd. This patch renames it and changes
related methods to template methods to avoid runtime cost of temporary
`RawRangeBoundary` instance creation.
Differential Revision: https://phabricator.services.mozilla.com/D35141
--HG--
extra : moz-landing-system : lando
If insertion string ends with ASCII whitespace and there is no following
content in the block, `HTMLEditRules::AdjustWhitespaces()` needs to insert
`<br>` element. It's called only by `HTMLEditRules::AfterEditInner()` and
that does only simple things with `WSRunObject`. Therefore, this moves the
code into `AfterEditInner()`.
For making it adjust the whitespaces, `HTMLEditRules::WillInsertText()` needs
to notify `AfterEditInner()` of dirty range with `mDocChangeRange`. Therefore,
this patch makes it set `mDocChangeRange` manually after inserting composition
string.
On the other hand, there is another bug. `WSRunObject` was designed to treat
only inserting text for `WSRunObject::InsertText()`. I.e., not designed to
treat replacing existing composition string with new string. Therefore,
`WSRunObject::InsertText()` adjusts whitespaces only around start of
composition string. Therefore, if composition string ends with an ASCII
whitespace, it's not replaced with NBSP and that causes:
- failing `WSRunObject::AdjustWhitespaces()` inserts `<br>` element at
`AfterEditInner()` of committing composition.
- then, next composition's first `WSRunObject::InsertText()` removes the
last whitespace due to not followed by `<br>` nor any other content.
Therefore, this patch makes `WSRunObject` takes 2 DOM points to be able to
treat replaced range.
In strictly speaking, the latter change require more changes and tests for
supporting replacement with any other methods. However, it's risky and out
of scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D26423
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
The usage of our specific "text" event is enough low (0.0003%). So, let's
stop dispatching the event in the default group of web content. Once we
release this new behavior, we can get rid of dispatching the event even in
chrome. Then, we can optimize the event order for new specs.
Differential Revision: https://phabricator.services.mozilla.com/D13034
--HG--
extra : moz-landing-system : lando
TextEditor modifies composition string or selected string when first
eCompositionChange event is received. However, TextComposition dispatches
eCompositionChange event ("text" event of DOM) only when composition string
becomes non-empty if current composition string is empty. So, when IME
dispatches only eCompositionStart and eCompositionCommit events for removing
selected text, TextEditor does nothing. This hacky behavior is used by
MS Pinyin on Windows 10 at least.
For supporting this behavior, we need to make TextComposition dispatch
eCompositionChange event when eCompositionChange(AsIs) event is fired
even before dispatching eCompositionChange event.
Although from point of view of web apps, the hacky composition should be
merged into the previous composition if it's possible but it's out of scope
of this bug.
MozReview-Commit-ID: 7QfeBJamGTU
--HG--
extra : rebase_source : 8de1353021f2961ae9f8bdf17ddded1058175339
EditorBase stores a text node, offset in it and length in it of composition
string directly. However, this wastes memory space if user never uses IME
or user only sometimes uses IME. Additionally, storing all data in
TextComposition is better than current design when other classes like
CompositionTransaction wants some information of both EditorBase and
TextComposition.
This patch moves those 3 members from EditorBase to TextComposition.
MozReview-Commit-ID: 4N7wmGGfxmt
--HG--
extra : rebase_source : bd7cb37fe9631b959ec21da40c20751fec269dca
According to the log in crash reports, eCompositionCommitRequestHandled is
sent to ContentCacheInParent twice or more for a composition. This causes
breaking mPendingCompositionCount and mPendingEventsNeedingAck management.
Currently, nsIWidget::NotifyIME() should be called only by
TextComposition::RequestToCommit(). Therefore, the method should manage if
it should request it actually. If the composition has already received
eCompositionCommit(AsIs) event, it shouldn't request it because parent process
may have already stated new composition and it shouldn't be broken by request
for old composition.
MozReview-Commit-ID: 2ekSa6EIeRP
--HG--
extra : rebase_source : d23aa29ce7871e83b99cec8c15aff0c580e08fb4
When TextComposition::RequestIMEToCommitComposition() is called but the request is handled by native IME asynchronously, TextComposition synthesizes eCompositionCommit(AsIs) event to commit composition synchronously. (This behavior helps web apps which tries to commit composition from JS.) Then, TextComposition::DispatchCompositionEvent() should ignore following composition events which are actually sent from native IME.
However, if composition is in a remote process, TextComposition::DispatchCompositionEvent() in the main process doesn't discard the following events coming from native IME. Therefore, ContentCacheInParent is confused by this unexpected events. So, TextComposition::DispatchCompositionEvent() shouldn't send the following unnecessary composition events to TabParent.
Note that in remote process, composition is committed synchronously with the hack mentioned above and synthesized eCompositionCommit(AsIs) event of TextComposition::RequestIMEToCommitComposition() in the parent process looks like coming from native IME. Therefore, following composition events coming from native IME are not necessary for the remote process.
MozReview-Commit-ID: 2uKFxcAq88J
--HG--
extra : rebase_source : f4fc3f19c86b03813479e6751cc19424f361d537
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
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
According to ATOK's behavior, IME may send different line breaker from its platform's standard. Therefore, we should treat \r as \n too.
Additionally, currently, TextComposition doesn't allow to input \n with composition. However, this was added for preventing to see odd control characters as boxes with code point. Therefore, we should allow \n for IMEs. (It was allowed, this limitation is unexpected when I reviewed the patch to reject control characters in TextComposition.)
MozReview-Commit-ID: DzGSMgp89Av
--HG--
extra : rebase_source : 0644e5941a080583af8701546111fbf46ec646ec
TextComposition::GetSelectionStartOffset() tries to query the start offset of the composition if there is a composition. Therefore, it tries to query first clause when it has some clause information of the composition string. However, even if the composition string is empty, TextComposition::mRanges which refers CompositionEvent::mRanges of the last eCompositionChange event may have empty clause information. In such case, this method tries to query not existing IME selection range. Then, this returns UINT32_MAX and ContentCacheInChild will query character rects around the offset and ContentEventHandler::SetRangeFromFlatTextOffset() will meet odd case.
For avoiding this issue, TextComposition::GetSelectionStartOffset() should query normal selection when composition string in the editor is empty. Note that TextComposition::mString will be updated after the editor completes updating its DOM contents. Therefore, TextComposition should refer mLastData which is set before dispatching eCompositionChange in the tree.
MozReview-Commit-ID: F2UGCQLXLSz
--HG--
extra : rebase_source : 0349a74f20f0948afa9989552a88047788aa1585
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
TextComposition should update its composition start offset after every DOM event dispatch with first clause's selection type if there is composition string.
MozReview-Commit-ID: HFkePci1PhU
--HG--
extra : rebase_source : c7af075115505b52e48d8bbd5f2dd1d9001fe36e
TextComposition queries selection start offset a lot of times. Therefore, for reducing the runtime cost, it should use IMEContentObserver if it's available or ContentEventHandler, otherwise.
MozReview-Commit-ID: 61GgQZDX2HP
--HG--
extra : rebase_source : 2080f77fa36e967e070495b11cc7b72e42e63fd1
When composition string hasn't been non-empty, insertion point of the composition string can be changed by a DOM event handler. E.g., compositionstart, first compositionupdate and first text. Therefore, TextComposition should update the composition start offset cache after every event dispatch.
MozReview-Commit-ID: FOPewPTRuCn
--HG--
extra : rebase_source : 95fbba8130a1d21e957cee305b3b2a433bfae56a
It's enough to store target clause offset from start of the composition and better to modify mCompositionStartOffset because when even if mCompositionStartOffset is changed, we don't need to modify the target clause offset.
This patch renames mCompositionTargetOffset to mTargetClauseOffsetInComposition.
MozReview-Commit-ID: 1wt2OTUUjkY
--HG--
extra : rebase_source : 1bb87899c6f2e374252aaa00535915d42c6bb29d
Currently, when TextComposition tries to forcibly commit composition synchronously, it cancels the composition if there is only an ideographic space since legacy Chinese IMEs for Windows were used an ideographic space as a placeholder and shows actual composition string in its owning window (called reading window).
However, Japanese TIPs basically use composition to input an ideographic space. Unfortunately, this intentional input of an ideographic space is always canceled if an editor commits to composition at every input event in TSF mode because TSF cannot commit during a call of ITextStore::RequestLock(). Additionally, we will enable e10s mode, then, on all platforms, requesting commit composition is handled asynchronously.
Therefore, we should make the hack disabled in default settings now. If we'll find a way to distinguish if an ideographic space is a placeholder, we should recover this hack. Note that such input fields cannot handle such legacy IMEs, so, disabling the hack in default settings must be fine.
MozReview-Commit-ID: IdBcfBxeJum
--HG--
extra : rebase_source : 18ca5cd1083ade8813703cec05c020dc03f09f63
For sending NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED after the other change notifications which was caused by the user input, we need to use IMEContentObserver::IMENotificationSender because it sends the notifications when it's safe to do it.
This patch makes TextComposition use IMEContentObserver to send the notification. However, if there is no active IMEContentObserver, e.g., composition events are fired on unfocused window, TextComposition sends it by itself (same as current implementation).
If IMEContentObserver stops observing when it has pending NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED, it cannot send the notification (i.e., it is discarded completely in such case). However, in such case, IMEContentObserver sends NOTIFY_IME_OF_BLUR. So, anyway, native IME handler should treat the blur notification as it including NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED.
On the other hand, we're buggy if composition events are fired in non-active window. Even in such case, IMEContentObserver should be created for active editor in each document and it notifies IME of the changes. But this is out of the scope of this bug.
MozReview-Commit-ID: 7Q0ZsJTh4hX
--HG--
extra : rebase_source : 6417f991fa8c0fbe3f25b27bacf4257e5485aecc
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
Masayuki Nakano
Makoto Kato
Andi-Bogdan Postelnicu
Narcis Beleuzu
Simon Giesecke
Mirko Brodesser
Nicholas Nethercote
Ryan Hunt
Mark Banner
Oana Pop Rus
Henri Sivonen
Ehsan Akhgari
Sylvestre Ledru
Bill McCloskey
Kan-Ru Chen
Chris Peterson
Arata Furukawa