It's always work with `Selection` ranges. Then, it should be treated within
`AutoRangeArray` which can be initialized with `Selection` ranges automatically.
Then, we can making `HTMLEditor` simpler.
Note tha this tries to make it get editing host when the corresponding
public method is called (after dispatched `beforeinput` event if handling a
users' operation). However, as commented in
`HTMLEditor::SetParagraphFormatAsAction`, it breaks a tricky crash test.
Therefore, only the format block path computes it after the preparation.
Differential Revision: https://phabricator.services.mozilla.com/D149079
Its callers check `EditorBase::Destroyed()` with at least adding 4 lines, and
some callers do not check this important state. So, we should make it check
`Destroyed()` at last and omit the additional error check in the caller sites.
Note that it's a virtual method, but `HTMLEditor` checks whether it's a
removable node or not. So, we should can merge it into `EditorBase`. This
patch does it too.
Differential Revision: https://phabricator.services.mozilla.com/D148084
It's currently computes the corresponding editing host from the focus node of
`Selection` with climbing up the DOM tree. So, it does not just return a stored
element. Therefore, some callers use it multiple times. For avoiding it, we
should rename it to explain that it computes the editing host.
Note that I think that we should make it takes a node to compute editing host
without `Selection` for solving the case of no selection ranges. Therefore,
I don't like to include more information into the name.
Differential Revision: https://phabricator.services.mozilla.com/D147504
This patch allows methods which split some nodes to return new candidate
caret position and makes callers of them consider whether applying it to
the selection immediately or not.
Differential Revision: https://phabricator.services.mozilla.com/D144648
The strategy of this patch and most following patches is, returning candidate
caret position with `CreateNodeResultBase`, and make each caller choose whether
it updates `Selection` immediately, put it off until exiting from a loop, or
just ignore.
This patch makes `HTMLEditor::HandleInsertBRElement` return
`CreateElementResult` and makes its callers handle selection as same as the
method does.
And note that I've not realized that `NS_FAILED` and `NS_SUCCEEDED` include
`MOZ_(UN)LIKELY`. Therefore, they don't need to be wrapped with them. And
also `NS_WARN_IF` has it too (but it's not in opt build, see bug 1765909).
On the other hand, neither `Result::isErr` nor `Result::isOk` has them
(bug 1765916). Therefore, except in the case of `Result`, this and following
patches will remove unnecessary `MOZ_(UN)LIKELY` from editor.
Differential Revision: https://phabricator.services.mozilla.com/D144644
Aligning to `EditorBase::InsertTextWithTransaction`, these methods should return
`Result<EditorDOMPoint, nsresult>` rather than taking an out param.
Differential Revision: https://phabricator.services.mozilla.com/D143882
In theory, methods which touch the DOM tree should take `EditorDOMPoint` rather
than `EditorRawDOMPoint`. And now, we can return meaningful value if it
succeeded, with `Result`.
Therefore, this patch makes it return `Result<EditorDOMPoint, nsresult>` instead
of taking an out argument, and take only `EditorDOMPoint` rather than taking any
type of `EditorDOMPointBase` since it's always converted to `EditorDOMPoint`.
Differential Revision: https://phabricator.services.mozilla.com/D143881
The implicit copy constructors and `operator=` makes it harder to realize
that implicit conversion wastes the runtime cost. Therefore, this patch
replaces them with a template method to convert the `EditorDOMPointBase` type.
Differential Revision: https://phabricator.services.mozilla.com/D143878
Some of them were `HTMLEditor` so that we need to fix it to `EditorBase`, and
also this patch fixes `NS_ERROR_EDITOR_DESTROYED` handling around them.
Differential Revision: https://phabricator.services.mozilla.com/D143815
At initializing new element which has not been connected, undo transactions
are not necessary because just removing the new element gets same result for
users. Therefore, they should be able to work without transactions.
Differential Revision: https://phabricator.services.mozilla.com/D140468
The method caches a DOM point, but it is not tracked correctly.
This patch adds some validations into it and one of its callee,
`HTMLEditor::MoveOneHardLineContents`. Additionally, making
`EditorDOMPointBase::Offset` avoid accessing `Maybe`'s storage when it's
`Nothing` in release builds as the last resort.
Differential Revision: https://phabricator.services.mozilla.com/D136994
First, left/right node accessors are not used so that we can get rid of them.
However, we should have similar methods which can retrieve original node and
new node. Therefore, this adds `GetNewContent()` and `GetOriginalContent()`.
Next, `SplitPoint()` should return both `EditorDOMPoint` and `EditorRawDOMPoint`
for avoiding unnecessary conversion from `EditorRawDOMPoint` to
`EditorDOMPoint`. Therefore, this patch makes it a template method too.
Finally, this patch adds helper methods to get point of each related content.
E.g., `AtNewContent()` corresponding to `GetNewContent()`.
Differential Revision: https://phabricator.services.mozilla.com/D131748
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
`nsTextFragment` is a storage of data node and DOM offset is `uint32_t`, but
some methods of `nsTextFragment` takes `int32_t` for the offset/length in
its text. Therefore, callers need to cast from `uint32_t` to `int32_t` if
the offset value is offset in a DOM node. Therefore, all methods of it should
take `uint32_t` values as offset/length in its text.
Differential Revision: https://phabricator.services.mozilla.com/D127923
This does NOT add tests to `inserttext` command which includes linefeed
characters with other characters. It seems that Blink handles 2 or more
length string is handled as multiple calls for every character. So each
linefeed character is handled as `insertparagraph`, but Gecko treats the
linefeed characters as-is. We should add the tests later with changing
Gecko's behavior, but for now, we should keep current behavior because
this difference must not be trobule in the wild, but we need to improve
preformatted string handler of Gecko better against reported web-compat
issues.
Differential Revision: https://phabricator.services.mozilla.com/D124562
So, the careful point is, they shouldn't put ASCII white-space next to a
preformatted white-space, but should put ASCII white-space next to the NBSP
as far as possible for making line break opportunities.
Differential Revision: https://phabricator.services.mozilla.com/D124560
If caret is put at preformatted linefeed, we need to handle adjacent
collapsible white-spaces too if the style is `white-space: pre-line`.
Therefore, this patch makes the delete handler aware of the case only
linefeed characters are preformatted and `AutoDeleteRangesHandler` call it
when caret is around a preformatted line break.
Differential Revision: https://phabricator.services.mozilla.com/D124559
It currently replaces inserting string's white-spaces to an `NBSP` even if
preformatted linefeed characters. Additionally, collapsible white-spaces around
a linefeed are removed. Therefore, adjacent collapsible characters of every
linefeed needs to be an NBSP. This patch makes the method handle it correctly.
Differential Revision: https://phabricator.services.mozilla.com/D124558
If `white-space` is `pre-line`, only linefeed characters are preformatted, but
white-spaces are collapsible. And if collapsible white-spaces follow or
are followed by a preformatted linefeed, they are removed. Therefore,
these methods need to scan following or preceding white-spaces of first
linefeed if the caller wants to delete. Unless doing it, the removed
white-spaces would become visible due to no linefeed character containing
sequence.
Differential Revision: https://phabricator.services.mozilla.com/D124557
Currently, they don't assume that there is `white-space: pre-line` which
preserves only linefeed characters, but white-spaces are collapsible.
This patch makes them stop early return when white-spaces are preformatted,
and do additional checks for linefeed characters.
Differential Revision: https://phabricator.services.mozilla.com/D124556
This makes it support `white-space: pre-line` which only preserve linefeed
characters. However, the APIs are not all of what we need to change.
Therefore, this causes hitting assertion hits due to different result from
some other APIs. So patching only with this does not work. The automated
test results will be updated later.
Note that it's **not** the goal of this bug that we don't support white-space
handling in text nodes whose `white-space` is `-moz-pre-space`. It replaces
linefeed characters with white-spaces then, preserve all white-spaces.
However, it's not standardized, and it's available with `xml:space="preserve"`
in SVG if web developers don't use the vender prefixed value, and finally,
supporting it makes our white-space handling in editor more complicated
than applying the following patches. So, we don't need to do it at least
for now. Therefore, this and following patches does not assume that there
are no cases that only new lines are collapsible.
Differential Revision: https://phabricator.services.mozilla.com/D124555
It's should not cross preformatted line break, therefore, the better name
for it is, it means whether the preformatted white-space is found or not.
Differential Revision: https://phabricator.services.mozilla.com/D123875
Currently, it uses "normal text" and "normal white-spaces" for naming
`enum class` members and their accessors. However, this is unclear what
does the normal mean since the word depends on context.
Therefore, this patch replaces the former with "non-collapsible characters" and
the latter is "collapsible white-spaces".
Differential Revision: https://phabricator.services.mozilla.com/D123872
This patch adds `EditorUtils::IsNewLinePreformatted()` to check whether a
linefeed character is collapsible or not.
Then, a lot of users of `EditorDOMPointBase::Is*CharASCIISpace()` and
`EditorDOMPointBase::Is*CharASCIISpaceOrNBSP()` should check whether the
white-space at the point is collapsible or not. Therefore, this patch adds
`Is*CharCollapsibleASCIISpace()` and `Is*CharCollapsibleASCIISpaceOrNBSP()`
too.
Then, makes such callers use the new API instead.
Differential Revision: https://phabricator.services.mozilla.com/D123871
The method returns false even if linefeed characters are preformatted.
So, it should be renamed to explain what it does clearer.
And this renames `TextFragmentData::mIsPreformatted` and its accessors too.
Differential Revision: https://phabricator.services.mozilla.com/D123870
`Selection` can be collapsed in a non-splittable element like a void element
and data nodes such as a comment node. In this case, we should split the
parent block at before the void element (Blink almost does so, except
`<embed>`, `<hr>` and `<wbr>`).
Differential Revision: https://phabricator.services.mozilla.com/D123709
It does not check whether it meets a non-editable parent or not. Therefore,
it may cross another editing host boundary when `aContent` is in a nested
editing host.
So, this patch fixes some edge cases when editing hosts are nested and
scanning from inner editing host.
Differential Revision: https://phabricator.services.mozilla.com/D122940
There are a lot of ancestor scanners in `HTMLEditUtils`. This is good thing
for the performance, but it makes us hard to maintain. Therefore, we should
merge them as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D122939
They clean up the tail of descendant block first. At this time, running script
may change one of or both of the left block element and the right block element.
In such situation, they should stop handling to join the blocks because of
unexpected case.
Depends on D122562
Differential Revision: https://phabricator.services.mozilla.com/D122565
It tries to replace a following NBSP with an ASCII white-space if there is.
However, it calls the scan method with start of the replacing range. Therefore,
the assertion in `GetInclusiveNextNBSPPointIfNeedToReplaceWithASCIIWhiteSpace()`
detects this bug.
Note that this occurs only when updating composition string because it's
called with non-collapsed range only for doing it. Otherwise, selected range
has already been deleted by `HTMLEditor::DeleteSelectionAsSubAction()`.
Unfortunately, I don't have how to make this bug appear. It seems that the
path does nothing in the wild because it tries to replace a first character
of composition string from an NBSP to a normal white-space, but it'll be
replaced with new composition string anyway. Therefore, this patch does not
have new tests.
Differential Revision: https://phabricator.services.mozilla.com/D122182
It should be treated as `uint32_t` since DOM API does so. However, there are
some exceptions:
* Result of `nsINode::ComputeIndexOf()`
* Result of `nsAString` methods
They return `-1` as not found, and anyway, they cannot treat large integer
than `INT32_MAX`. Therefore, this patch does not touch around them.
Differential Revision: https://phabricator.services.mozilla.com/D118933
They may return a descendant, and now `HTMLEditUtils` has some methods whose
name ends with `Child` and they scan only direct children of given node.
So, we should rename these methods for avoiding misunderstanding.
Differential Revision: https://phabricator.services.mozilla.com/D115122
This must make the callers of `HTMLEditUtils::IsVisibleBRElement()` and
`HTMLEditUtils::IsInvisibleBRElement()` easier to read.
Depends on D114933
Differential Revision: https://phabricator.services.mozilla.com/D114934
