When it's called, it just returns at the reached content node. However, this
does not make sense when it reached a character in the text node.
Depends on D207685
Differential Revision: https://phabricator.services.mozilla.com/D207686
When `WSScanResult::ReachedCurrentBlockBoundary()` returns `true`, it may have
reached inline editing host rather than editable block. Therefore, the
method name is definitely error-prone. This patch adds new state and all
users of `WSType::CurrentBlockBoundary` keeps checking the new type too for
keeping current behavior.
I think that we should make `WSRunScanner` aware of inline editing host next
to block boundary before removing odd check of
`ReachedInlineEditingHostBoundary()`, `StartsFromInlineEditingHostBoundary()`
and `EndsByInlineEditingHostBoundary()` to avoid unexpected regressions in the
wild.
Depends on D207683
Differential Revision: https://phabricator.services.mozilla.com/D207684
Different from the comment around setter of `WSType::CurrentBlockBoundary`,
neither `HTMLEditUtils::GetNextLeafContentOrNextBlockElement` nor
`HTMLEditUtils::GetPreviousLeafContentOrPreviousBlockElement` returns
`nullptr` when it reaches non-editable element, and the setters always set
`mContent` to `aEditableBlockParentOrTopmostEditableInlineElement`. Therefore,
`mContent` is always an editable element when `ReachedCurrentBlockBoundary()`
returns `true`.
Depends on D207682
Differential Revision: https://phabricator.services.mozilla.com/D207683
Currently, it checks whether `mContent` is `nullptr` or not even if the scanner
reached something. However, this makes the users of this object check whether
it has reasonable content or not and that makes the users messy. Therefore,
the scanning method should guarantee that it's always error if it does not reach
any content.
Depends on D207681
Differential Revision: https://phabricator.services.mozilla.com/D207682
This case should never happen because nobody can check proper editable state
in uncomposed tree unless the uncomposed tree has its own editing host.
Therefore, this patch adds assertions into the scanning methods too.
Differential Revision: https://phabricator.services.mozilla.com/D207681
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Blink [1] and WebKit [2] refers `display-outside` value when they consider whether an
element is a block or an inline.
However, our editor refers HTML default style instead. Therefore, our editor
cannot handle the following cases:
* If a container block is a non-HTML element whose `display` style is `block`.
* If a container `<div>` etc is styled as `inline` and typing `Enter` in it.
* If a container `<span>` is styled as `block` and it ends with spaces.
For making users get better result, we should follow the other browsers.
However, this is too risky change. Therefore, this patch enables new behavior
only in the Nightly channel and early beta builds to collect feedback from
testers.
The big rules of checking block vs. inline are:
* When we handle block level edit actions such as formatting block, indenting
or outdenting selection, making or removing list, we should keep referring
the HTML default style because the other browsers do so and the commands are
intended for modifying the HTML structure.
* Otherwise, we should refer the computed style of the block. However, if
working with non-connected elements, we may need a special handling that is
falling back to refer the HTML default style because `HTMLEditorDataTransfer`
work with non-connected document fragments.
* Finally, if we check visibility of collapsible white-spaces and `<br>`s, we
should refer computed style. However, in this case, we may need to treat
ancestor `inline-block`s as block too, but for siblings, we should refer only
`display-outside`.
1. https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/editing_utilities.cc;l=779;drc=31fb07c05718d671d96c227855bfe97af9e3fb20
2. https://searchfox.org/wubkat/rev/b054636fffeffa0314914a11ce39725a3057131e/Source/WebCore/editing/Editing.cpp#317
Differential Revision: https://phabricator.services.mozilla.com/D188598
It returns the result of
`MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()`, but it suggests
caret position only when it modifies the DOM tree since it does not take the
default caret position.
So, `DeleteContentNodeAndJoinTextNodesAroundIt()` does need to return
`aCaretPoint` with tracking it during DOM mutations if
`MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()` does not
suggest caret point.
I found this bug when I was trying to fix the unexpected failing of
forward delete at end of the last block in the editing host (bug 1850666)
because changing the error handling anyway cause another error at this line.
https://searchfox.org/mozilla-central/rev/bdd5b85b56885cd48bd91d262647e0d3499b3a27/editor/libeditor/HTMLEditorDeleteHandler.cpp#1652
Therefore, without fixing bug 1850666, I have no idea how to check this fix.
Differential Revision: https://phabricator.services.mozilla.com/D187196
The assertion was introduced in bug 1655988. However, the assertion assumes
that the given range ends before start of the deleting range (invisible
white-spaces), but that is wrong, the range may ends in middle of or end of
collapsible white-spaces. Therefore, this patch just fixes the assertion.
Depends on D180783
Differential Revision: https://phabricator.services.mozilla.com/D180785
With the preceding patch, comment nodes are also moved at deleting a block/line
boundary. However, this causes some WPT failures. Therefore, this adds an
option to the related methods.
Note that Chrome removes all comment nodes in moving nodes. However, I don't
have the motivation to do that because it requires additional cost and I have
no idea to improve the compatibility in usual web apps. So I believe that
doing it wastes the runtime performance unless we'd get a bug reports by the
difference.
Therefore, this patch does not update WPTs too.
Differential Revision: https://phabricator.services.mozilla.com/D176767
The Custom Highlight API allows a use case where a `Range` of a `Highlight`
is also used as `Selection`. Due to the decision to use the `Selection` mechanism
to display `Highlight`s, a `Range` can be part of several `Selection`s.
Since the `Range` has a pointer to its associated `Selection`
to notify about changes, this must be adapted to allow several `Selections`.
As a tradeoff of performance and memory usage, the `Selection`s are stored
as `mozilla::LinkedList`. A helper class `mozilla::SelectionListWrapper`
was implemented to allow `Selection`s to be in multiple of these lists
and without having to be derived from `LinkedListElement<T>`.
To simplify usage of the list, the use case "does this range belong to Selection x?"
is wrapped into the convenience method`IsInSelection(Selection&)`;
The method previously named like this was renamed to `IsInAnySelection()`
to be named more precisely.
Registering and unregistering of the closest common inclusive ancestor
of the `Range` is done when the first `Selection` is registered and
the last `Selection` is unregistered.
Differential Revision: https://phabricator.services.mozilla.com/D169597
And also this changes `HTMLEditor::ReplaceTextWithTransaction` which is the only
user of `ReplaceTextTransaction`.
Depends on D169745
Differential Revision: https://phabricator.services.mozilla.com/D169746
And also this patch makes its only user,
`EditorBase::InsertTextIntoTextNodeWithTransaction`, and its only caller,
`EditorBase::InsertTextWithTransaction`, return `InsertTextResult` for
returning both end of inserted text and caret point suggestion. Note that
if it's for IME composition, `CompositionTransaction` needs to update
`Selection` directly. Therefore, caret point may be unset under composition
to updating `Selection` to wrong point (it seems that
`TextEditor::HandleInsertText` can be simplified later because of this change).
Depends on D169044
Differential Revision: https://phabricator.services.mozilla.com/D169744
One of the crash reasons is, the destination is the parent `<video>` of the
`<ol>`. When `AutoRangeArray` considers the range of first line is, making
`<video><source/>{<ol><li>a</li></ol>}`. This is not intuitive, but extending
the range to outside of the block boundaries is required to collect editable
target nodes. However, this causes a problem. `AutoMoveOneLineHandler` splits
the parent `<video>` element at the range boundaries with
`AutoRangeArray::SplitTextNodesAtEndBoundariesAndParentInlineElementsAtBoundaries`
since it's treated as an inline element. However, the `<video>` element is the
container of destination, so this is one unexpected issue for
`AutoMoveOneLineHandler`. Then, it tries to move split empty nodes to same
or another `<video>` element (depending on the split node direction). However,
at this time, it fails to move the node and delete it instead because `<video>`
cannot have not all elements. If the source `<video>` and destination `<video>`
is same one, nodes disappear from `movedContentRange` in `Run()` and `Run()`
cannot track it. Therefore, the range becomes invalid.
Ideal approach to fix this issue is, we should redesign considering where is
a line and how to collect the target nodes. However, if I change the
`AutoRangeArray` methods to fix this case, a lot of regressions appeared because
they are shared in a lot of edit actions. Therefore, I give up to fix them.
Instead, this patch just prevents to split the destination container. This may
have not fixed the real point, However, for now, we should just patch this
case because this could be potentially a problem for web apps which use inline
elements with `display: block`.
Differential Revision: https://phabricator.services.mozilla.com/D168183
Now, the method does too many things. Therefore, touching it is hard to review.
I think that it should be handled in a stack class and split each chunk of the
method with sharing some data with members.
Differential Revision: https://phabricator.services.mozilla.com/D168180
This patch creates a base class of `EditorInlineStyle`, the name is
`EditorElementStyle`. It requires only attribute of HTML. However, it's
obviously different from `EditorInlineStyle`'s rule which is `mHTMLProperty`
cannot be `nullptr`. Therefore, the methods which can treat only
`EditorInlineStyle` do not want the data only whose attribute is not `nullptr`.
For solving this issue at build time, this approach is better than renaming
`EditorInlineStyle` and make it have the new mode.
Depends on D162513
Differential Revision: https://phabricator.services.mozilla.com/D162514
Due to the preceding `DeleteInvisibleASCIIWhiteSpaces` call, the destination
may be lost since `aLeftContentInBlock` may have already been removed from the
DOM tree. Therefore, it should stop handling the deletion when destination is
modified by the web app.
Depends on D161423
Differential Revision: https://phabricator.services.mozilla.com/D161424
They are used in public inline methods of `HTMLEditor`. Therefore, they should
be defined in an exposed header file without other internal use things for the
editor module. Then, we can stop exposing `HTMLEditHelpers.h`.
Depends on D158632
Differential Revision: https://phabricator.services.mozilla.com/D158633
Any callers do not refer "ignored", "handled" and "cancel" state without
checking whether the method returns error or not. Therefore, error state
can be (and should be) managed by `mozilla::Result`'s error state.
Perhaps, it should store a caret position later because deletion handlers
of `HTMLEditor` use it, but update `Selection` immediately.
Differential Revision: https://phabricator.services.mozilla.com/D158080
Similar to the previous patch, this changes a lot of lines. However, I think
that it's not so hard to investigate regression point in this patch because
`CreateNodeResultBase` is not used so many times at handling on edit action.
Differential Revision: https://phabricator.services.mozilla.com/D157575
Similar to the previous patch, this changes a lot of lines. However, I think
that it's not so hard to investigate regression point in this patch because
`CreateNodeResultBase` is not used so many times at handling on edit action.
Differential Revision: https://phabricator.services.mozilla.com/D157575
Unfortunately, it's hard to split this (and similar) patch because we need to
touch `MoveNodeResult` itself for making it available as the ok type of
`Result`. However, I guess that it's not so hard to investigate regression
point if something would be found later because `MoveNodeResult` is mainly
used by deletion which is the most complicated part of `HTMLEditor`, but
`MoveNodeResult` is used only in a few cases.
Differential Revision: https://phabricator.services.mozilla.com/D157574
It splits inline elements at the destination of first line in the right block.
However, it typically creates empty inline elements before the right block and
may be never used because it sets the insertion point to before the right node
of the splitting.
Therefore, it should stop creates empty inline elements (if they are required,
they should be created in `HTMLEditor::MoveNodeOrChildrenWithTransaction`
instead) and adjust split point after the element if it didn't split any nodes.
Differential Revision: https://phabricator.services.mozilla.com/D157418
Chrome and Safari preserve `white-space` with `style` attribute to keep
collapsible or preserved white-spaces as-is. If an HTML element is moved,
`style` attribute should be set to it. Otherwise, create `<span>` element
whose `style` attribute has the declaration for `white-space` and move
content into it.
Differential Revision: https://phabricator.services.mozilla.com/D157413
Gecko just joins 2 blocks when editable block parents are same element, e.g.,
both are `<div>`. However, Chrome and Safari moves only first line of the
right block into the left block, and Gecko does it when both blocks are
different elements.
Ideally, we should take same behavior as Chrome and Safari because it's
reasonable for both compatibility with the other browsers and consistency
when both blocks are different but has same style, then we don't need to
maintain different behavior paths.
However, doing it for all elements are too risky because right block will be
merged into left block if right block has no line break. On the other hand,
without doing it, preserving `white-space` is really hard because we need to
maintain the both paths.
Therefore, I'd like to change the behavior only when both blocks have different
`white-space` styles. Usually, web apps do not change `white-space` for each
block, so I think that this is safer than doing this in all elements,
additionally, we can revert the behavior easy since this patch is really small.
Differential Revision: https://phabricator.services.mozilla.com/D157412
This fixes bug 503838 partially. The new utility method scans unnecessary
`<br>` with strict check as far as possible. Then, we can delete the node or
the preformatted line break at end of the last text node.
Differential Revision: https://phabricator.services.mozilla.com/D157411
I've already made a caller of `HTMLEditor::ClearStyleAt`,
`HTMLEditor::CreateStyleForInsertText`, in bug 1770877, so this fixes a bug of
the patch.
`HTMLEditor::ClearStyleAt` is still updates `Selection` only in some cases.
And one of the caller has not handle the `Selection` update. Therefore, once
it completely stop touching `Selection`, `ComputeEditingHost` will fail and
the other paths update `Selection`, so it should do it too. (Without the
change, `test_dragdrop.html` fails.)
Finally, we don't need `EditResult` anymore because we have
`Result<EditorDOMPoint, nsresult>`.
Differential Revision: https://phabricator.services.mozilla.com/D154343
Similar to the previous patch, and for consistency between editor helper
classes, we should make result of getter methods of `EditorDOMPointBase` too.
Differential Revision: https://phabricator.services.mozilla.com/D153841
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
Masayuki Nakano