It should take `nsStyledElement&` instead of `const Element&`. Then, it won't
fail and will just return the result of `nsStyleElement::Style()`. Therefore,
we can get rid of it.
Note that this patch makes all its callers keep using strong pointer because
I'm not sure whether the layout APIs which are called with them are safe or
not.
Differential Revision: https://phabricator.services.mozilla.com/D87982
When it returns `EditActionIgnored()`,
`AutoDeleteRangesHandler::HandleDeleteAroundCollapsedRanges()` creates another
`AutoDeleteRangesHandler` instance to delete leaf content node in another
block element. However, this dependency makes developers understand the
behavior harder. Therefore, we should make the method do it instead.
Differential Revision: https://phabricator.services.mozilla.com/D87439
For avoiding infinite recursive calls, `AutoDeleteRangesHandler` returns
`EditActionIgnored()` when it needs to fall it back to
`DeleteRangesWithTransaction()` after modifying the DOM tree or the ranges
to delete. However, this makes developers understand the code harder.
And now, with making constructor of `AutoDeleteRangesHandler` manage the
recursive call state, we can make `HandleDeleteSelection()` stop handling
the fallback path.
Differential Revision: https://phabricator.services.mozilla.com/D87438
Even though their method names in stack trace become too long, but we can
guarantee that they are used only at handling deletion.
Differential Revision: https://phabricator.services.mozilla.com/D87433
This patch just moves them into the new stack only class and make each of them
take `HTMLEditor&` as their first argument.
Differential Revision: https://phabricator.services.mozilla.com/D87432
If `AutoSetTemporaryAncestorLimiter` sets ancestor limiter of the `Selection`,
existing range which is already cached by `AutoRangeArray` may be changed
into the new limiter.
Therefore, this patch makes `AutoSetTemporaryAncestorLimiter` take
`AutoRangeArray` optionally and reset it only when it sets new limiter for
the performance.
Differential Revision: https://phabricator.services.mozilla.com/D87820
The root cause of this bug is a bug of async `ScrollSelectionIntoView` that
is what it won't be canceled even if web app changes scroll position with
any API. Fixing it is really risky and this bug affects an existing website.
Therefore, this patch makes the constructors of `AutoPlaceholderBatch` take
whether do or do not `ScrollSelectionIntoView` when it's destructed. And
makes `HTMLEditor::SetInlinePropertyAsAction()` not request
`ScrollSelectionIntoView` for taking back the traditional behavior.
Note that this patch does not make it an optional argument because it's hard to
guess that it'll run `ScrollSelectionIntoView` automatically.
Differential Revision: https://phabricator.services.mozilla.com/D87819
Even though it hasn't normalize white-spaces before invisible `<br>` element,
it needs to do it for making them visible. Therefore, we should make it
use the new method in this case too.
Depends on D87030
Differential Revision: https://phabricator.services.mozilla.com/D87031
Although it does not need to join text nodes around the `<br>` element since
its previous node is `<hr>`, it can use
`WhiteSpaceVisibilityKeeper::DeleteContentNodeAndJoinTextNodesAroundIt()` too.
Depends on D87029
Differential Revision: https://phabricator.services.mozilla.com/D87030
It works with the traditional white-space normalizer. Therefore, it should
be moved into `WhiteSpaceVisibilityKeeper`.
Depends on D86910
Differential Revision: https://phabricator.services.mozilla.com/D87029
This patch changes the behavior in the following 2 points:
* When both content is in same block element, won't return error
* When `<hr>` element has block children accidentally, this solves its container
The former case must not change actual behavior because
`AutoBlockElementsJoiner` is used with content nodes which are in different
blocks.
Differential Revision: https://phabricator.services.mozilla.com/D86886
Now all users of the method is methods of `AutoBlockElementsJoiner`.
Therefore, we can move it into the nested class. And for splitting the
method in the following patch, it should be a nested class of
`AutoBlockElementJoiner`.
Depends on D86791
Differential Revision: https://phabricator.services.mozilla.com/D86881
And now, `HTMLEditor::JoinNodesDeepWithTransaction()` is used only by
`AutoBlockElementsJoiner`. Therefore, this patch moves it to the
stack only class.
Differential Revision: https://phabricator.services.mozilla.com/D86789
For making the following review easier, this patch just moves some part of
`HandleDeleteNonCollapsedRanges()` into `AutoBlockElementJoiner`.
Differential Revision: https://phabricator.services.mozilla.com/D86786
Now, only when deleting table cell contents, `HandleDeleteSelectionInternal()`
depends on `Selection`. However, this can be moved to `HandleDeleteSelection()`
because recursive callers expects `Selection` is collapsed by its previous job.
Differential Revision: https://phabricator.services.mozilla.com/D86183
This patch moves `EditorBase::ExtendSelectionForDelete()` into `AutoRangeArray`
and make it stop modifying `Selection`.
The method extends anchor-focus range with `nsFrameSelection` and it refers
bidi information in it too. Therefore, it needs to be called before modifying
anchor-focus range of `Selection`. Unfortunately, this makes the code messy,
but for now, we should take this. In the future, we should make the API of
`nsFrameSelection` free from `Selection`.
Differential Revision: https://phabricator.services.mozilla.com/D86182
Creation cost of `nsRange` is expensive, and it's only user,
`HTMLEditor::HandleDeleteNonCollapsedRanges()` wants to extend the range.
Therefore, we can make it directly extend the given range.
Differential Revision: https://phabricator.services.mozilla.com/D85849
It may be faster to use `AutoTrackDOMRange` directly. Therefore, current
`WhiteSpaceVisibilityKeeper::PrepareToDeleteRange()` should be renamed to
`WhiteSpaceVisibilityKeeper::PrepareToDeleteRangeAndTrackPoints()` and
we should make `HTMLEditor::HandleDeleteNonCollapsedSelection()` track
the range by itself.
Depends on D85846
Differential Revision: https://phabricator.services.mozilla.com/D85847
There is only `AutoTrackDOMPoint`, but
`HTMLEditor::HandleDeleteNonCollapsedSelection()` requires to tack pairs of
DOM points, i.e., requires to track ranges. For making the code simpler,
we should have range tracker too.
Depends on D85845
Differential Revision: https://phabricator.services.mozilla.com/D85846
This patch makes `EditorBase::DeleteSelectionWithTransaction()` a wrapper of
`EditorBase::DeleteRangesWithTransaction()`.
Differential Revision: https://phabricator.services.mozilla.com/D85686
Currently, `nsIEditActionListener::WillDeleteSelection()` notifies
`FinderHighliter` of deleting selection ranges. But it's referred only
the ranges, not selection object itself and editor shouldn't modify
`Selection` as far as possible for reducing the runtime cost.
Therefore, it should be replaced with this new API. Then,
`EditorBase::WillDeleteSelectionWithTransaction()` can be rewritten as
`EditorBase::WillDeleteRangesWithTransaction()` later.
Differential Revision: https://phabricator.services.mozilla.com/D85681
The recursive call is not safe. We should do it more carefully. For now,
we should not hide the recursive call into the leaf handler.
Differential Revision: https://phabricator.services.mozilla.com/D85573
This patch creates new stack only class, `HTMLEditor::AutoBlockElementsJoiner`
and splits `HTMLEditor::HandleDeleteCollapsedSelectionAtCurrentBlockBoundary()`
to considering the content nodes to be joined part and doing join the nodes
part.
Differential Revision: https://phabricator.services.mozilla.com/D85567
This patch creates new stack only class, `HTMLEditor::AutoBlockElementsJoiner`
and splits `HTMLEditor::HandleDeleteCollapsedSelectionAtCurrentBlockBoundary()`
to considering the content nodes to be joined part and doing join the nodes
part.
Differential Revision: https://phabricator.services.mozilla.com/D85567
`rightListElement` is not used, so, we can put it into smaller scope.
`leftListElement` is used for storing original `leftBlockElement` when
`newListElementTagNameOfRightListElement` is some. Therefore, we can
stop using it with caching the original `leftBlockElement` before
maybe modified its value.
Differential Revision: https://phabricator.services.mozilla.com/D85531
Now, the new method,
`WhiteSpaceVisibilityKeeper::MergeFirstLineOfRightBlockElementIntoLeftBlockElement()`
is the only user of the method so that we can get rid of it since it does enough
simple thing.
Differential Revision: https://phabricator.services.mozilla.com/D85530
And the name is wrong. It depends on `aPoint` whether the `<br>` element is
visible or invisible because it just scans preceding `<br>` element but
stop doing it when it meets a visible content. Therefore, this patch renames
it to explain what it does.
Differential Revision: https://phabricator.services.mozilla.com/D85528
CLOSED TREE
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
The previous patch changed target of white-space normalization. That caused
`editor/libeditor/tests/test_bug1425997.html` starting to failed with new
exception. What happens in the test is, selection is collapsed into comment
node (I think that this behavior is also a bug though) after second
`document.execCommand("delete")`, and then, failed to delete anything
and throws the exception. For fixing this issue, the most simple approach is
make `HTMLEditor::HandleDeleteAroundCollapsedSelection()` stop handling
deletion when caret position is not editable. So, unfortunately, this
patch changes traditional path too.
Depends on D84948
Differential Revision: https://phabricator.services.mozilla.com/D84949
Blink normalizes preceding white-spaces of deleting range only when the range is
NOT remove last character or there are no following text nodes. If removing
last character at first text node which is followed by another text node, Blink
normalize white-spaces at start of the following text node.
This behavior seems odd, but we should follow the Blink's behavior for better
compatibility.
Note that new test failures in
`white-spaces-after-execCommand-forwarddelete.tentative.html` is caused by
that forward deletion is handled by existing path instead of the new handler.
Therefore, it's no problem for now.
Additionally, this change causes a mochitest
(`editor/libeditor/tests/test_bug1425997.html`) and a crash test
(`editor/libeditor/crashtests/1424450.html`) becoming oranges since their
DOM tree becomes different after applying this patch. The oranges will
be fixed by the following patches.
Depends on D84947
Differential Revision: https://phabricator.services.mozilla.com/D84948
The difference between `HTMLEditor::HandleDeleteCollapsedSelectionAtTextNode()`
and `HTMLEditor::HandleDeleteCollapsedSelectionAtWhiteSpace()` is whether
it treats surrogate pair or not. And it's easy to handle it in `WSRunScanner`.
Therefore, they can handle all deletion in a text node.
Some new failures are caused by that we normalize preceding white-spaces of
deletion range but Blink does not to it. These failures will be fixed by
part 5.
Depends on D84946
Differential Revision: https://phabricator.services.mozilla.com/D84947
For the following patches, it's nicer that the API has optional behavior which
removes new empty text node or empty parent elements because directly removing
parent element can reduce the number of transactions and avoid storing text
with `DeleteTextTransaction()`.
Depends on D84944
Differential Revision: https://phabricator.services.mozilla.com/D84945
`InputEvent.getTargetRange()` should have actual delete range. It means that
the range should contain the invisible leading/trailing white-spaces which
need to be removed for keep them invisible, but should not contain the range
of normalizing white-space sequence because they are not target of edit action
indicated by `InputEvent.inputType`.
So, we can use new path which uses the new white-space normalizer for
computing the value of `InputEvent.getTargetRanges()` because difference of
white-space normalizer shouldn't affect the deleting ranges (although, some
existing path calls `DeleteNodeIfInvisibleAndEditableTextNode()` later so that
the new method, `ComputeRangeInTextNodesContainingInvisibleWhiteSpaces()`, does
not exactly same thing, but the result shouldn't become different in usual
cases). This new path can test with some WPTs under `editing/other`.
This patch creates new backspace/delete key handler when caret is at next
to a white-space as `HTMLEditor::HandleDeleteTextAroundCollapsedSelection()`
and creates helper methods of `WSRunScanner` to treat invisible leading and
trailing white-spaces.
Note that new failures are caused by the difference whether adjacent white-space
sequence at deletion is normalized or not in edge cases. They will be fixed
by the part.5.
Depends on D84943
Differential Revision: https://phabricator.services.mozilla.com/D84944
With the previous patch, 2 bugs become visible.
One is a `MOZ_ASSERT` in
`WhiteSpaceVisibilityKeeper::MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()`
is wrong. When `TextFragmentData::GetReplaceRangeDataAtEndOfDeletionRange()`
returns a replace range, it may set the start to inclusive next character of
end to delete. So, start of replace range may start after end to delete when
container of end to delete is not a text node and its next editable char point
is an ASCII white-space. Therefore, this patch rewrite it with
`MOZ_ASSERT_IF` and `EditorDOMPoint::IsInTextNode()`.
The other is `TextFragmentData::GetReplaceRangeDataAtEndOfDeletionRange()`
and `TextFragmentData::GetReplaceRangeDataAtStartOfDeletionRange()` may call
`TextFragmentData::GetFirstASCIIWhiteSpacePointCollapsedTo()` and
`TextFragmentData::GetEndOfCollapsibleASCIIWhiteSpaces()` with a point in
preformatted text node. Therefore, this patch adds the check into them.
Depends on D84323
Differential Revision: https://phabricator.services.mozilla.com/D84943
Traditionally, `WSRunScanner` (and formerly `WSRunObject`) treats all text
nodes in its range when scan start container node has preformatted style.
This means that when starting start from start or end of preformatted text node
or inline element, it treats adjacent white-spaces which is not preformatted
as preformatted.
This patch fixes this issue. Because of the fix of preceding patches,
`BoundaryData` stops scanning if it meets preformatted text node. So,
`BoundaryData` can store whether the scanners found a preformatted character.
Therefore, if one of `BoundaryData`s is marked as "preformatted", it means
the range contains a preformatted character. And keep referring the style
of scan start point if there is no visible text nodes around it.
Note that the above change causes new failures with `<listing>` element which
should be treated as `<pre>` element, but `HTMLEditUtils` treats it as
non-container inline element.
https://html.spec.whatwg.org/multipage/dom.html#elements-in-the-dom:listing
Therefore, this patch changes the definition of `<listing>` element and
`<xmp>` element which is also mentioned in the above link to container
element etc. `<listing>` element is treated exactly same as `<pre>`,
therefore, the new definition is same as `<pre>`, but `<xmp>` does not
allow any tags after opens it (i.e., even if its close tag). Therefore,
`<xmp>` definition is different from `<listing>` and `<pre>` elements'
definition.
Differential Revision: https://phabricator.services.mozilla.com/D84323
The check does not make sense because `TextFragmentData`'s range may contain
multiple text nodes which may have different style.
With the previous patch, the range won't cross characters in preformatted
text nodes. Therefore, their result won't contain preformatted characters
right now. So, we can just drop the unnecessary check from them.
Differential Revision: https://phabricator.services.mozilla.com/D84320
Simply, if a white-space is in a preformatted text node, we shouldn't modify
it for normalizing. This patch adds such checks to various points in
`WSRunObject.cpp`.
Differential Revision: https://phabricator.services.mozilla.com/D84319
Currently, `TextFragmentData` stores whether the scan start point is
preformatted or not. However, it does not make sense because the class
may contain other text nodes which may have different style in its range.
The main job of `TextFragmentData` is managing white-spaces as visible
sequence or invisible sequence. So, preformatted white-space should be
treated as visible character because of not collapsible with adjacent
formatted ASCII white-spaces.
First of all, this patch its initializer stop scanning white-spaces if
it meets non-empty preformatted text node.
Note that the new failures are caused by the difference whether which
white-space sequence should be normalized when modifying text at text node
or inline element boundary. This difference should be fixed in another
bug because our new normalizer does not handle this same as Blink for now.
Differential Revision: https://phabricator.services.mozilla.com/D84317
