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
This is what the original method should've done. Mutation event listeners may
change the DOM tree at the first modification, but it hasn't checked whether
the range to delete or replace around start of deleting range is still valid
or not.
Depends on D83226
Differential Revision: https://phabricator.services.mozilla.com/D83228
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
Masayuki Nakano
Mirko Brodesser
Simon Giesecke
Razvan Maries
tkhan
Bogdan Tara