There are a lot of places which calls
`HTMLEditor::MaybeSplitAncestorsForInsertWithTransaction()` and then calls
`HTMLEditor::CreateAndInsertElementWithTransaction()` with split point of the
preceding result. It's better to wrap them in a method for reducing the
maintenance cost.
`HTMLEditor::CreateOrChangeBlockContainerElement()` handles to calling them
safer than the others so that let's use this code for the new method. The
additional change won't change the most web apps which don't touch the DOM
tree from legacy mutation event listeners.
Depends on D131198
Differential Revision: https://phabricator.services.mozilla.com/D131199
I realized that it's now used only by `HTMLEditor` so that we can move it
into `HTMLEditor` and we can make `CreateElementTransaction` treat `HTMLEditor`
directly rather than via `EditorBase`.
Differential Revision: https://phabricator.services.mozilla.com/D131198
It touches the DOM tree only with `SplitNodeTransaction()` and it now returns
`NS_ERROR_EDITOR_DESTROYED` so that the callers don't need to check whether
the editor is destroyed or alive by themselves.
Depends on D131043
Differential Revision: https://phabricator.services.mozilla.com/D131044
For making the code simpler, this patch makes it returns
`Result<nsCOMPtr<nsIContent>, nsresult>` instead of using `ErrorResult`.
This must make the construction faster and callers simpler.
Depends on D130950
Differential Revision: https://phabricator.services.mozilla.com/D131043
It does the following things when caret is collapsed in a text node in a `<p>`
or `<div>` element.
1. Split the text node containing caret to insert `<br>` element
2. Insert `<br>` element after it
3. Split ancestor elements which inclusive descendants of the `<p>` or `<div>`
4. Delete the `<br>` element if unnecessary from the left paragraph
#3 and #4 are performed by `HTMLEditor::SplitParagraph()` and it calls
`WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` correctly before
splitting the block. However, in the case (caret is at middle of a text node),
the text has already been split to 2 nodes because of #1. Therefore, it fails
to handle to keep the white-space visibility.
So that I believe that the root cause of this bug is, the method does much
complicated things which are required, and doing the redundant things will
eat memory space due to undo transactions. However, for now, I'd like to fix
this with a simple patch which just call the preparation method before splitting
the text node because I'd like to uplift this if it'd be approved (Note that
this is not a recent regression, the root cause was created by bug 92686 which
was fixed in 17 years ago:
<https://searchfox.org/mozilla-central/commit/2e66280faef73e9be218e00758d4eb738395ac83>,
but must be annoying bug for users who see this frequently).
The new WPTs are pass in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D130950
Similar to the previous patch, this patch also make it track invisible
white-space ranges and clear outdated things.
And this makes it cache some information instead of tracking some changes
because of performance reason.
Depends on D131037
Differential Revision: https://phabricator.services.mozilla.com/D131038
It `pointToSplit` should be tracked at replacing text, but I have no idea how
to test this because it replaces the text after the split point.
Differential Revision: https://phabricator.services.mozilla.com/D131036
Currently, it assumes that new node is the left node and split node is the
right node. However, we need to make it possible to handle the case that
right node is new one for fixing bug 1735608.
Depends on D130458
Differential Revision: https://phabricator.services.mozilla.com/D130624
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
There is 2 overloads. One is `TextServicesDocument`'s method, and the latter is
for `nsIEditActionListener`. The latter could occur if `TextServicesDocument`
is added to the editor when there is no inline spellchecker, `EditorSpellCheck`
or `mozSpellChecker`.
https://searchfox.org/mozilla-central/rev/d2f8488b6a704443a5c5bfc6d2878171b5f0d393/editor/libeditor/EditorBase.cpp#2388,2391,2393,2396,2398
I don't know whether this is possible case, but unfortunately,
`nsIEditActionListener::DidJoinNodes()` is not implemented by JS and implemented
only by `TextServicesDocument`. Therefore, we can make it "noscript" and use
non-scriptable classes as arguments.
This patch makes them get jointed point and removed content node and the joining
direction for fixing bug 1735608. Unfortunately, there is no test framework
to check the result in `TextServicesDocument` nor the new path. The latter
should be tested when we fix bug 1735608 later.
Differential Revision: https://phabricator.services.mozilla.com/D130458
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
Currently, it assumes that `aLeftNode` is new node and the other is the original
one. However, we need the opposite case when we fix bug 1735608.
Unfortunately, we cannot test the new path until we fix bug 1735608. Therefore,
the new path may contain some bugs.
Differential Revision: https://phabricator.services.mozilla.com/D130427
Currently, it assumes that all children or text data of `aRightContent` is
moved into `aLeftContent`. However, we need the opposite case when we fix
bug 1735608.
Unfortunately, we cannot test the new path until we fix bug 1735608. Therefore,
the new path may contain some bugs.
Differential Revision: https://phabricator.services.mozilla.com/D130426
The telemetry result is written in bug 1706266 comment 1:
https://bugzilla.mozilla.org/show_bug.cgi?id=1706266#c1
`increasefontsize`, `decreasefontsize`, `gethtml`, `heading` and `readonly` are
obviously not used by web apps in the wild. Therefore, they can be disabled
in all channels.
`contentReadOnly` and `insertBrOnReturn` are odd. The usage is really low (less
than 1% of beta users). However, the number of documents which used the command
is about 1k samples. The result of the commands are not tiny (making the editor
not editable or changing the behavior at typing `Enter` key in `<div>`, `<p>`,
etc). Therefore, it's hard to use them in web apps which supports not only
Gecko. So I guess that they are collected the number of used by automated
tests of somebody because of the constant number in other beta versions.
Perhaps, we should disable it only in Nightly channel for now, and after a
couple of releases, we should try to disable those commands too later.
Depends on D130328
Differential Revision: https://phabricator.services.mozilla.com/D130329
I'd like to split utilities for all editors and only for `HTMLEditor`.
This moves some trivial classes into new `HTMLEditHelpers.h`. Perhaps, it's
better if we can move them into `HTMLEditUtils.h`, but it has too many inline
method definitions so that adding new classes into it makes it much bigger.
Depends on D130349
Differential Revision: https://phabricator.services.mozilla.com/D130425
Now, it does not notify nobody before joining the nodes. Therefore, it can
return error immediately if it fails to create a transaction to join the given
nodes.
Additionally, this patch makes it return `NS_ERROR_EDITOR_DESTROYED` if the
editor is destroyed while it handles to join nodes. Therefore, we can get rid
of the check by the callers.
Differential Revision: https://phabricator.services.mozilla.com/D130349
`TopLevelEditSubActionData::WillJoinNodes()` and
`TopLevelEditSubActionData::DidJoinNodes()` are called only by
`HTMLEditor::JoinNodesWithTransaction()`. `WillJoinNodes()` assumes that
all children or text data in `aLeftContent` is moved to head of `aRightContent`.
Therefore, it just stores length of `aLeftContent` and `DidJoinNodes()` lets
`AddPointToChangedRange()` know the joined point.
Same value is stored by `HTMLEditor::JoinNodesWithTransaction()`. Therefore,
it can create same DOM point at calling `DidJoinNodes()` so that we can get
rid of `WillJoinNodes()`.
Differential Revision: https://phabricator.services.mozilla.com/D130348
Now, it does not notify nobody before joining the nodes. Therefore, it can
return error immediately if it fails to create a transaction to join the given
nodes.
Additionally, this patch makes it return `NS_ERROR_EDITOR_DESTROYED` if the
editor is destroyed while it handles to join nodes. Therefore, we can get rid
of the check by the callers.
Differential Revision: https://phabricator.services.mozilla.com/D130349
`TopLevelEditSubActionData::WillJoinNodes()` and
`TopLevelEditSubActionData::DidJoinNodes()` are called only by
`HTMLEditor::JoinNodesWithTransaction()`. `WillJoinNodes()` assumes that
all children or text data in `aLeftContent` is moved to head of `aRightContent`.
Therefore, it just stores length of `aLeftContent` and `DidJoinNodes()` lets
`AddPointToChangedRange()` know the joined point.
Same value is stored by `HTMLEditor::JoinNodesWithTransaction()`. Therefore,
it can create same DOM point at calling `DidJoinNodes()` so that we can get
rid of `WillJoinNodes()`.
Differential Revision: https://phabricator.services.mozilla.com/D130348
Currently, checking whether an `EventTarget` is `nsINode` (or its concrete
classes) or not requires a QI, but it's expensive and used a lot while we
handle each event. Therefore, it'd be nicer for creating a virtual method,
`EventTarget::IsNode()` and use it for the check.
If trying to convert `EventTarget` to a concrete class, it may require two
virtual method calls. I'm not sure whether it's cheaper than a QI, but at
least, it won't depend on the UUID check order of `QueryInterface()` when
multiple interfaces are implemented.
Differential Revision: https://phabricator.services.mozilla.com/D129781
LineBreaker has no member variables and acts like "namespaces" with
utility functions. Therefore, its methods can be static and called
directly without needing a LineBreaker instance.
Rename GetJISx4051Breaks() to ComputeBreakPositions() per review
feedbacks.
Differential Revision: https://phabricator.services.mozilla.com/D129107
