For making `WSRunScanner::BoundaryData` independent from `WSRunScanner`,
its initializer should be in the class itself as static factory methods.
Depends on D82295
Differential Revision: https://phabricator.services.mozilla.com/D82693
Now, we can call `WSFragment` `VisibleWhiteSpacesData`. Then, the methods of
`WSRunObject` which take `WSFragment` as their arguments become clearer what
they mean.
Differential Revision: https://phabricator.services.mozilla.com/D82295
Now, `WSFragment` instances are created only by
`TextFragmentData::CreateWSFragmentForVisibleWhiteSpaces()`. Therefore, it's
always visible.
Additionally, this patch hides `WSFragment` constructors from the others too.
Differential Revision: https://phabricator.services.mozilla.com/D82294
Now, we know that it returns `WSFragment` for visible white-spaces and may
lie position in the line. Therefore, we should rename it as just representing
visible white-spaces.
Differential Revision: https://phabricator.services.mozilla.com/D82292
Now, nobody uses `WSRunScanner::FindNearestRun()` so that we can remove it.
Then, there is no users of `WSRunScanner:mFragments`. Therefore, we can remove
the member, accessors and initializers.
Differential Revision: https://phabricator.services.mozilla.com/D82291
Unfortunately, remaining code which use `beforeRun` and `afterRun` of
`WSRunObject::PreareToDeleteRangePriv()` is completely broken. It tries to
do what the new utility methods say, but as you see in the method, the
checking code does not make sense. For now, we should keep this broken
check even with the expensive DOM point comparisons. I hope that this does
not harm any benchmark score.
Note that I tested this with all automated tests with comparing the result
of these methods with `MOZ_ASSERT()` like this:
https://hg.mozilla.org/try/rev/29cb7840e404473a41d2d1fbdd229f762ccac5d3
So, I think that this is enough safe because the most edge cases are tested
by the first patch in this bug and `editing/run/(forwarddelete|delete).html`
of WPT.
Differential Revision: https://phabricator.services.mozilla.com/D82290
Similar to the previous changes, `WSRunObject::PrepareToDeleteRangePriv()`
can use `TextFragmentData::CreateWSFragmentForVisibleAndMiddleOfLine()` and
result of comparing with deleting range.
Differential Revision: https://phabricator.services.mozilla.com/D82288
For handling composition, `WSRunObject::InsertText()` rescan white-spaces at
end of replacing range. However, in most cases, `mScanStartPoint` and
`mScanEndPoint` are same. Therefore, we can save the runtime cost of the
rescan easier than the old design.
Differential Revision: https://phabricator.services.mozilla.com/D82287
I realized that `WSFragment::MarkAsVisible()` is called only by
`TextFragmentData::CreateWSFragmentForVisibleAndMiddleOfLine()`. Therefore,
`beforeRun && !beforeRun->IsStartOfHardLine() && beforeRun->IsVisible()` can be
handled with `pointPositionWithVisibleWhiteSpacesAtStart` and
`afterRun && !afterRun->IsEndOfHardLine() && afterRun->IsVisible()` can be
handled with `pointPositionWithVisibleWhiteSpacesAtEnd`. So, we can make
`WSRunObject::InsertText()` stop using `FindNearestFragment()` to compute
inserting string.
Differential Revision: https://phabricator.services.mozilla.com/D82286
Similar to `WSRunObject::InsertBreak()`, `WSRunObject::InsertText()` can use
the new APIs for `InsertBreak()` even though the name is odd for `InsertText()`,
but the mismatching is caused by odd logic of it. If replacing range starts
from and/or ends by middle of invisible white-space sequence, all of the
invisible white-spaces should be removed to prevent they become visible.
However, we shouldn't change any behavior in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D82285
It removes some invisible leading and/or trailing white-spaces when it inserts
`<br>` element into the invisible white-space sequence. It currently checks
whether the insertion point is in invisible leading and trailing white-spaces
or not with `FindNearestFragment()`, but we can do same thing with
comparing the insertion point with the result of
`TextFragmentData::GetInvisibleLeadingWhiteSpaceRange()` and
`TextFragmentData::GetInvisibleLeadingWhiteSpaceRange()`. However, current
implementation does not make sense because:
- It checks trailing white-spaces with `!IsEndOfHardLine()` and
`IsStartOfHardLine()`, but this means that it does ignores invisible
white-spaces which are the only content in a line.
- It checks leading white-spaces with `!IsStartOfHardLine()` and
`IsEndOfHardLine()`, so, this also ignores invisible white-spaces which
are the only content in a line.
- The important thing of the logic is prevent that invisible leading and
trailing white-spaces become visible with new `<br>` element, but this
is done only for trailing white-spaces.
Differential Revision: https://phabricator.services.mozilla.com/D82283
It looks for same `WSFragment` twice with comparing text and what it looks for
is the instance whose `IsVisibleAndMiddleOfLine()` returns `true`.
Additionally, doing twice is for checking only whether the split point is
start or end of the range. Therefore, we can make it simpler with using
`TextFragmentData::CreateWSFragmentForVisibleAndMiddleOfLine()`.
Differential Revision: https://phabricator.services.mozilla.com/D82281
They return a point in an `WSFragment` whose `IsVisibleAndMiddleOfLine()`
returns `true` or start/end of the range. Therefore, they can ignore the
other `WSFragment`s and save comparing points to at most twice.
Differential Revision: https://phabricator.services.mozilla.com/D82280
It scans all `WSFragment`s in the array and call `NormalizeWhiteSpacesAtEndOf()`
only with visible instance. However, as we know, there is at most one such
instance. Therefore, it does not need to scan the fragments (i.e., don't need
to create all fragments).
Differential Revision: https://phabricator.services.mozilla.com/D82279
Most methods handling something with `WSFragment` work only with instances
whose `IsVisibleAndMiddleOfHardLine()` return true, and currently, such
instance exists only one at most in the array. Therefore, they just want
an API to get such fragment.
Differential Revision: https://phabricator.services.mozilla.com/D82276
`Scrub()` does remove leading white-spaces and trailing white-spaces if
there is. So, it does not require `WSFragment` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D82275
This is minimally invasive. In the following parts, methods will be
moved to it and potentially other methods will be extracted.
Differential Revision: https://phabricator.services.mozilla.com/D82384
Different from `GetInvisibleTrailingWhiteSpaceRange()`, it always returns
the range even if it's collapsed (i.e., there is no leading white-space).
Differential Revision: https://phabricator.services.mozilla.com/D82274
One of the `WSFragment`users' purpose is, they remove invisible white-spaces
when there are. So, `TextFragmentData` should have API to retrieve the
ranges and use them for initializing `WSFragment` which represents leading
or trailing white-spaces. For making this patch smaller as far as possible,
these APIs implements only the case when there is no NBSP.
For result of the new API, this creates a template class, `EditorDOMRangeBase`,
whose boundary type is `EditorDOMPointBase`. Its methods are named from
`nsRange`'s same methods.
Differential Revision: https://phabricator.services.mozilla.com/D82272
This patch just creates new stack only class and make it initializes
`WSRunScanner::mFragments` instead of `WSRunScanner`.
Differential Revision: https://phabricator.services.mozilla.com/D82270
For making easier to understand the contents of `WSRunScanner::mFragments`,
we should stop using `InitializeWithSingleFragment()` for now because it's
designed for doing same things a lot, but used only by 2 users and they set
different parameters so that it does not do same things for the callers.
Depends on D82268
Differential Revision: https://phabricator.services.mozilla.com/D82269
