Similarly, we can implement it with `LeafNodeOptions` to ignore
unnecessary nodes. Then, we can get rid of `WalkTreeOption` and
`WalkTreeOptions` completely.
Differential Revision: https://phabricator.services.mozilla.com/D277524
`HTMLEditUtils::GetNextContent()` and
`HTMLEditUtils::GetPreviousContent()` are wrappers of
`HTMLEditUtils::GetAdjacentContent()` and
`HTMLEditUtils::GetAdjacentLeafContent()`. The behavior is similar to
`HTMLEditUtils::GetNextLeafContentOrNextBlockElement()` or
`HTMLEditUtils::GetPreviousLeafContentOrPreviousBlockElement()` but
they won't stop at block inclusive ancestor or a block sibling of an
inclusive ancestor. Therefore, we can get rid of them and use the new
and better implementation.
Differential Revision: https://phabricator.services.mozilla.com/D277522
This reverts commit 5ccf392dce.
Revert "Bug 1998077 - part 6: Reimplement `HTMLEditUtils::Get(First|Last)Child()` and `HTMLEditUtils::Get(Next|Previous)Sibling()` with `LeafNodeOptions` r=m_kato"
This reverts commit 12eb928cb5.
Revert "Bug 1998077 - part 5: Replace the remaining `HTMLEditUtils::Get(Next|Previous)Content()` with new ones based on `Get(Next|Previous)LeafNodeOr(Next|Previous)BlockElement()` r=m_kato"
This reverts commit 58b4243d10.
Revert "Bug 1998077 - part 4: Replace some callers of `HTMLEditUtils::Get(Next|Previous)Content()` with `HTMLEditUtils::Get(Next|Previous)LeafContentOr(Next|Previous)BlockElement()` r=m_kato"
This reverts commit dd46967eb4.
Revert "Bug 1998077 - part 3: Add new options to ignore empty/invisible leaf nodes r=m_kato"
This reverts commit ca50a4a628.
Revert "Bug 1998077 - part 2: Add `WSType::EmptyInlineContainerElement` r=m_kato"
This reverts commit 4a5d93d631.
Revert "Bug 1998077 - part 1: Make `HTMLEditUtils::IsVisibleElementEvenIfLeafNode` work better if primary frame is available r=m_kato"
This reverts commit b42dc9d35f.
Similarly, we can implement it with `LeafNodeOptions` to ignore
unnecessary nodes. Then, we can get rid of `WalkTreeOption` and
`WalkTreeOptions` completely.
Differential Revision: https://phabricator.services.mozilla.com/D277524
`HTMLEditUtils::GetNextContent()` and
`HTMLEditUtils::GetPreviousContent()` are wrappers of
`HTMLEditUtils::GetAdjacentContent()` and
`HTMLEditUtils::GetAdjacentLeafContent()`. The behavior is similar to
`HTMLEditUtils::GetNextLeafContentOrNextBlockElement()` or
`HTMLEditUtils::GetPreviousLeafContentOrPreviousBlockElement()` but
they won't stop at block inclusive ancestor or a block sibling of an
inclusive ancestor. Therefore, we can get rid of them and use the new
and better implementation.
Differential Revision: https://phabricator.services.mozilla.com/D277522
In the historical reason, some of them still take `nsINode*`. In these
days, converting from `nsINode` to `nsIContent` or `Element` is faster
than before and most callers already use `nsIContent`. Therefore, we
should make them take `const nsIContent&`.
Only some methods, allowing callers use pointer makes them simpler.
Therefore, only some methods have overloads which take
`const nsIContent*` instead.
Differential Revision: https://phabricator.services.mozilla.com/D265525
In the historical reason, some of them still take `nsINode*`. In these
days, converting from `nsINode` to `nsIContent` or `Element` is faster
than before and most callers already use `nsIContent`. Therefore, we
should make them take `const nsIContent&`.
Only some methods, allowing callers use pointer makes them simpler.
Therefore, only some methods have overloads which take
`const nsIContent*` instead.
Differential Revision: https://phabricator.services.mozilla.com/D265525
`AutoRangeArray` is created for making some handlers of the editor classes free
from `Selection` and `nsFrameSelection` while handling the edit actions.
However, the method still depends on `nsFrameSelection` instance since its
callees are instance methods of `nsFrameSelection`.
However, `EditContext` requires completely free methods to compute target
ranges of `beforeinput`. Therefore, we need to make it not depend on
`Selection` nor `nsFrameSelection`.
The common method, `nsFrameSelection::CreateRangeExtendedToSomewhere`, requires
`PresShell`, selection limiter which is set only when the selection is an
independent selection like in a selection for a text control, selection
ancestor limiter which is set only when an editing host has focus, caret
association hint to put caret to end of preceding line or start of following
line if selection range is collapsed at a line break and caret bidi level for
considering caret position around line break in bidi text. They are now stored
by `nsFrameSelection` and modified when selection range is changed in some
cases. Basically, the method is called without updating its ranges and if and
only if it's initialized with `Selection`. So, simply caching the
`nsFrameSelection`'s values solves the issues in the most cases, but this
patch makes `AutoRangeArray` adjust the value only when its `Collapse` is
called because `Selection` automatically updates it and we can compute the
value without `Selection` nor `nsFrameSelection`.
After applying this patch, `AutoRangeArray` has two meanings, one is the
instance is a proxy for `Selection`. The other is a container for a range to
call methods which take pointer or reference to it. To make this differences
checked at build time, this patch creates a new subclass of it, and renamed to
`AutoClonedRangeArray` to make it clearer that what are stored in the array.
Oddly, `AutoRangeArray(nsRange&)` constructor has not been cloned. Therefore,
I make it and its subclass version clone before storing into the array. Then,
one caller needs to change which range should be tracked.
Differential Revision: https://phabricator.services.mozilla.com/D232174
`AutoMoveOneLineHandler` uses `AutoRangeArray` API for block level edit
sub-actions. Therefore, the source line is computed with
`BlockInlineCheck::UseHTMLDefaultStyle`. However, the deletion handler works
with `BlockInlineCheck::UseComputedDisplayOutsideStyle`. Therefore,
`AutoMoveOneLineHandler` may try to move different range. In the reported
test case, it tries to move all content under the `<body>` into the
`<a display="table-header-group">` which is contained in the range. Therefore,
the `movedContentRange` check fails after the destination becomes into an
orphan node which was removed to move.
This patch renames the API and adds a `BlockInlineCheck` parameter to work
with both ways and makes `AutoMoveOneLineHandler` specify
`BlockInlineCheck::UseComputedDisplayOutsideStyle` as same as the other delete
handlers.
Finally, same thing may happen in
`HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal`. This patch makes it
check whether the top-level edit sub-action is a block level one or not and
consider `BlockInlineCheck` with the result.
Depends on D194180
Differential Revision: https://phabricator.services.mozilla.com/D194181
Now, all callers of them do not require to check `<dl>`, `<dt>` and `<dd>` check
if it's in the HTML format block mode. Therefore, we can move the check into
`HTMLEditor::IsFormatElement` to make the caller side simpler.
Additionally, this patch replaces some places with
`HTMLEditUtils::IsFormatElementForParagraphState` because the paths handle only
XUL paragraph state command with assertion check.
Depends on D190902
Differential Revision: https://phabricator.services.mozilla.com/D191604
Currently, we extend selection to outside block boundaries if selection starts
and/or ends very start/end of block boundaries. Then, replace most-distant
ancestor format node, but this is odd because the innermost format is applied
to the text and the other browsers targets the innermost ancestor formant node.
Therefore, we should align to them.
Additionally, our replacing code for `<dd>` and `<dt>` has not been implemented
yet. I guess that the old `HTMLEditUtils::IsFormatNode` returned `false` for
`<dd>`, `<dl>` and `<dt>` and it requires additional work for splitting parent
`<dl>` too. Now, we can do it with simple code.
Finally, we created new format block element if `<br>` element appears, but
the other browsers moves it into the new format node simply. Therefore, we
should follow them (about `<blockquote>`, we've already done this within
the different path).
Differential Revision: https://phabricator.services.mozilla.com/D190902
`Document.execCommand` accepts `dl`, `dt` and `dd` as a format block. However,
`ParagraphStateAtSelection` ignores them as not a format block element.
Therefore, it causes odd result of `queryCommandValue` after applying the
format. E.g., `execCommand("dd")` to `<p>[foobar]</p>` correctly updates the
HTML to `<dl><dd>foobar</dd></dl>`, however, `queryCommandValue("dd")` returns
empty string rather than `dd`.
Note that Chromium returns inclusive ancestor format element of common ancestor
of the range. However, the behavior is odd because it makes the indeterm
state never `true` and the result is not used as the target of format block
command. So, this patch does not follow them at least for now.
On the other hand, this patch adds special case for `dl`. With user's
operation in valid HTML structure, selection range never selects `<dl>`
children directly. However, may cross `<dt>` and `<dd>` elements.
Then, let's return `dl` for compatibility with Chromium because `<dl>`
ancestor may be the format block target.
Differential Revision: https://phabricator.services.mozilla.com/D190901
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
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Currently, Gecko does not support updating `font-size` style even in the CSS
mode. Therefore, `CSSEditUtils` claims that `<font size="...">` style is not
CSS editable. Supporting it requires a lot of new code but currently we don't
have any reports about this poor support. Therefore, we should only try to
make the style editor remove `font-size` properties around selection at setting
`<font size="...">` style for now.
Additionally, Blink and WebKit does not allow to nest multiple `<font>` elements
and `<span>` elements which specify `font-size`, `font-family` or `color`. When
setting one of the styles, they split ancestors which are related to the style
at range boundaries. Then, unwrap the unnecessary elements. This makes the
DOM tree simpler, thus, the later handling will be simpler. Therefore, it's
worthwhile to follow them.
Unfortunately, there are some logic differences when handling styles in elements
having `id` attribute. Therefore, there are some new test failures, but I guess
that it does not cause any problems in web apps in the wild because it's hard to
manage editable identified elements in cross browsers and I have no idea of
motivations to do it.
Depends on D166617
Differential Revision: https://phabricator.services.mozilla.com/D167011
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
`AutoRangeArran` uses `OwningNonNull`. So making the following patch simpler
and smaller, all places should use array of `OwningNonNull<nsRange>` instead of
`RefPtr<nsRange>`.
Differential Revision: https://phabricator.services.mozilla.com/D149076
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
The "state" is not limited by editing host nor editable nodes. Therefore, it
should keep scanning ancestor block element without checking editable state.
Differential Revision: https://phabricator.services.mozilla.com/D122948
The lifetime of it is guaranteed by `AutoEditActionDataSetter` which grabs
`Selection` until it's destroyed, and it's a stack only class and created
at first step of all public method calls. Therefore, we can mark it as
`MOZ_KNOWN_LIVE` and we can change it returning reference of `Selection`
instead of reference of `RefPtr<Selection>`.
Differential Revision: https://phabricator.services.mozilla.com/D110896
It's too big (+15k lines) and there are 2 groups which does not depend on the
others. One is getting current state for `Document.queryCommandState` etc.
This is copied to `HTMLEditorState.cpp`. And the other is delete handlers.
This is copied to `HTMLEditorDeleteHandler.cpp`.
Differential Revision: https://phabricator.services.mozilla.com/D94934
Sylvestre Ledru