The test runs `execCommand("insertHorizontalRule")` when the document node
has no children. In this case, `TextFragmentData` fails to initialize itself.
In this case, our editor cannot do anything. Therefore, returning error
in this case must be better.
This patch makes all callers of the scan methods handle the error case unless
the caller cannot return error.
Comparing with Blink, perhaps, we should insert `<html>` and `<body>` element
in this case first and keep doing the requested operation in the future.
Currently, doing it may cause another complicated issue with mutation event
listeners.
Differential Revision: https://phabricator.services.mozilla.com/D95126
If deleting/replacing range selects a text node, it may shrink the range
to start and end of the text node. So, the result may not be wider than
the original range.
This behavior is compatible with Blink.
Depends on D90639
Differential Revision: https://phabricator.services.mozilla.com/D90640
This is causes taking back bugs in
`WSRunScanner::GetNewInvisibleLeadingWhiteSpaceRangeIfSplittingAt()` and
`WSRunScanner::GetNewInvisibleTrailingWhiteSpaceRangeIfSplittingAt()` (I.e.,
they were fixed by bug 1647556). Therefore, this removes the odd `if` blocks
which are pointed with `XXX` comment for avoiding "regressions" (without them,
some WPTs for `InputEvents.getTargetRanges()` become failure).
Depends on D89582
Differential Revision: https://phabricator.services.mozilla.com/D89869
When its `Run()` join the block elements, even if it won't move any content
nodes in first line, it may notify the callers as "handled" when there is a
preceding invisible `<br>` element since it needs to delete it in any cases.
Therefore, whether there is or not a preceding invisible `<br>` element is
important to compute target ranges since if there is one, `Run()` won't return
"ignored" and the callers won't delete leaf content instead.
Note that the new assertions are not hit in any tests, but due to searching
preceding invisible `<br>` element in `Prepare()`, expected assertion
count of 2 tests is increased.
Depends on D89577
Differential Revision: https://phabricator.services.mozilla.com/D89578
This patch implements computation of target ranges for this part:
https://searchfox.org/mozilla-central/rev/73a14f1b367948faa571ed2fe5d7eb29460787c1/editor/libeditor/HTMLEditSubActionHandler.cpp#3099-3141
This patch adds some utility methods for computing the ranges. Currently,
it's not yet standardized, but the other browser engines look for leaf content
of another block when blocks are joined (or a block is deleted like this case).
Therefore, we follow the behavior basically, but different from the other
browsers, we should include invisible white-spaces into the range when they
are included. That avoids the invisible white-spaces become visible when
web apps do something instead of us. Note that utility methods have the code,
but this patch does not use it because in this case, we just delete a empty
block ancestor, not join it with previous/next block.
Differential Revision: https://phabricator.services.mozilla.com/D88377
This patch implements computation of target ranges for this part:
https://searchfox.org/mozilla-central/rev/73a14f1b367948faa571ed2fe5d7eb29460787c1/editor/libeditor/HTMLEditSubActionHandler.cpp#3099-3141
This patch adds some utility methods for computing the ranges. Currently,
it's not yet standardized, but the other browser engines look for leaf content
of another block when blocks are joined (or a block is deleted like this case).
Therefore, we follow the behavior basically, but different from the other
browsers, we should include invisible white-spaces into the range when they
are included. That avoids the invisible white-spaces become visible when
web apps do something instead of us. Note that utility methods have the code,
but this patch does not use it because in this case, we just delete a empty
block ancestor, not join it with previous/next block.
Differential Revision: https://phabricator.services.mozilla.com/D88377
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
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
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
`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
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
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
They return copy of cached `EditorDOMRange` instance. So, they can return
const-reference rather than copy of stored data.
Differential Revision: https://phabricator.services.mozilla.com/D83919
With this patch, the creation cost of `TextFragmentData` is minimized, but
`MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()` can work
with the latest DOM tree information at touching start of the deleting range
even after touching end of the range.
Depends on D83228
Differential Revision: https://phabricator.services.mozilla.com/D83229
For representing delete or replace data which have the range and replace string,
this patch creates `ReplaceRangeDataBase` class which is stack-only, has
`EditorDOMRange` or `EditorDOMRangeInTexts` as the range and has replace string
which can be empty string.
Then, `MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()` should
modify the DOM tree by itself. With the following patch, the behavior is
corrected for multiple DOM tree changes.
Depends on D83224
Differential Revision: https://phabricator.services.mozilla.com/D83226
This patch is preparation for easier to review.
This patch duplicates the body of
`MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()` and calls the
copies from new `MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()`.
The one is for handling start of deleting range, and the other is for handling
end of deleting range.
As you see, this patch and the following patches do not work because of the
duplicated code. Perhaps, part 2 works if there is no mutation event listeners.
Part 9 works even if there is mutation event listeners which touch the DOM
tree in the worst case (when it touches both end of delete range and start of
delete range, and around the start of deleting range is modified by JS).
Finally, part 9 takes back the original performance.
Depends on D82715
Differential Revision: https://phabricator.services.mozilla.com/D83217
Now, these classes are used only by `TextFragmentData` and they can be not
exposed. Therefore, we should hide them with making them private nested
classes of `TextFragmentData`.
Differential Revision: https://phabricator.services.mozilla.com/D82714
Although the new name is long, but I have no better idea. The class's purpose
is to keep white-space visibility around modifying DOM position. Therefore,
I use "keeper" for the name.
Differential Revision: https://phabricator.services.mozilla.com/D82713
Similar to the previous patch, `WSRunObject::NormalizeWhiteSpacesAround()` is
a wrapper to create `WSRunObject` instance for calling
`NormalizeWhiteSpacesAtEndOf()`, but it does not need to be `WSRunObject`'s
instance. Therefore, we can merge them.
Note that this renames the merged method to `NormalizeVisibleWhiteSpacesAt`.
Differential Revision: https://phabricator.services.mozilla.com/D82711
Now, it does not need to be a `WSRunObject` instance so that its wrapper to
create `WSRunObject` instance is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D82710
It's now can work with static helper methods and a `TextFragmentData` instance.
Therefore, this patch makes it a static method.
Note that it's always called with `nsIEditor::eNone` so that we can get rid of
the argument.
Differential Revision: https://phabricator.services.mozilla.com/D82705
Now, `mScanEndPoint` is not used. This patch removes it and clean up the
constructors of `WSRunScanner` and `WSRunObject`.
Differential Revision: https://phabricator.services.mozilla.com/D82703
It's simpler to make `WSRunScanner::InsertText()` take insertion point.
Then, it can do its jobs with `TextFragmentData` instance(s).
Differential Revision: https://phabricator.services.mozilla.com/D82702
`CreateVisibleWhiteSpacesData()` is now called multiple times and maybe called
after the DOM tree is modified even though it's a bug. Therefore, we should
make it store first result and return its reference instead.
Differential Revision: https://phabricator.services.mozilla.com/D82701
Same as the previous patch, it can be split to computation part and
modifying the DOM tree part. Then, the former can be in `TextFragmentData`
and the latter can be done by the caller which is only
`WSRunObject::InsertText()`.
Depends on D82699
Differential Revision: https://phabricator.services.mozilla.com/D82700
It's called by `WSRunObject::InsertText()` and `WSRunObject::InsertBreak()` and
it has 2 parts. One is, considering whether previous char is an NBSP or not
and whether it should be replaced with an ASCII white-space if it's followed
by visible character. The other is, doing the replacement. The latter code
is enough simple. Therefore, we can copy them into the callers. Then,
we can move the check logic into `TextFragmentData`.
Depends on D82698
Differential Revision: https://phabricator.services.mozilla.com/D82699
They work with a `TextFragmentData` instance, and the following patches
require to run it without `WSRunScanner`/`WSRunObject` instances.
Therefore, this patch moves them into `TextFragmentData`.
Depends on D82695
Differential Revision: https://phabricator.services.mozilla.com/D82697
This patch makes `WSRunScanner` have `TextFragmentData const mTextFragmentData`
instead of 2 `BoundaryData`s, a `NoBreakingSpaceData` and a `bool` storing
whether it's preformatted or not.
Depends on D82694
Differential Revision: https://phabricator.services.mozilla.com/D82695
Andi-Bogdan Postelnicu
Masayuki Nakano
Mihai Alexandru Michis