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
After this change, it's possible to set the pref, or use editor.document.execCommand("styleWithCSS", false, "true") to enable css in mail compose.
Differential Revision: https://phabricator.services.mozilla.com/D157276
Additionally,
* `PropItem` -> `PendingStyle`
* `StyleCache` -> `PendingStyleCache`
* `AutoStyleCacheArray` -> `AutoPendingStyleCacheArray`
And finally, `PendingStyle` (formally `PropItem`) is changed to `class` and
its members are encapsuled.
Differential Revision: https://phabricator.services.mozilla.com/D155318
For consistency with the previous patch, we should rename them too. Then, we're
getting rid of unclear word "Prop" from the public methods.
Differential Revision: https://phabricator.services.mozilla.com/D155316
I usually retry to understand what they mean. Therefore, I'd like to give new
names for them (and rename `TypeInState` class in a following patch).
Differential Revision: https://phabricator.services.mozilla.com/D155315
It's always a pointer to `nsStaticAtom` instance or `nullptr`. Therefore,
it can be `nsStaticAtom*` and we can make its users treat `nsStaticAtom`
instead of `nsAtom`.
Additionally, this patch changes some pointer parameters to references if
they are never `nullptr`.
Differential Revision: https://phabricator.services.mozilla.com/D155310
`HTMLEditor::RelativeFontChange()` and its helpers are based on
`SetInlinePropertiesAsSubAction()` and its helpers. Therefore, they may have
similar problem to switch join/split direction. Therefore, this and the
following patches clean them up too.
Depends on D154350
Differential Revision: https://phabricator.services.mozilla.com/D154351
I think that `HTMLEditor::SetInlinePropertyAsSubAction` and
`HTMLEditor::RemoveInlinePropertyAsSubAction` should not be called multiple
times in one edit action. Therefore, I'd like to make them take multiple
styles once. Then, we could collect all targets before touching the DOM tree
in the future.
Depends on D154348
Differential Revision: https://phabricator.services.mozilla.com/D154349
This is a pre-fix for bug 1735608. Currently, the loop assumes that collected
nodes are always right node, but it'll be changed, therefore, it creates
new array for the follow up loops handle expected nodes.
Depends on D154346
Differential Revision: https://phabricator.services.mozilla.com/D154347
I'd like to get rid of `AutoSelectionRangeArray` and `AutoRestoreSelection`,
and I'd like to make it stop touching `Selection` while it is removing style
of each content nodes in the range. Therefore, this patch rewrites it with
`AutoRangeArray`. Then, we can reduce the indent level of the nested `for`
loops.
Note that it creates `AutoEditSubActionNotifier`, so it's a sub-edit action
handler. Therefore, this patch renames it.
Depends on D154345
Differential Revision: https://phabricator.services.mozilla.com/D154346
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
Currently, `HTMLEditor` assumes that padding `<br>` element for empty last line
is outside of inline elements, but it may happen because of both:
* starting from bug 1778091, `HTMLEditor` move `<br>` element into new empty
inline elements at inserting new paragraph.
* web apps can put it into inline elements.
After splitting inline elements and which do not have meaningful content, users
cannot put caret into the empty inline elements so that the elements stay unless
delete around there.
For avoiding the leak due to meaningless elements, we should delete them at
splitting inline elements at inserting new text.
Note that Chrome does not pass the new tests of resetting ancestor bold style
because Chrome wraps the `<b>` with `<i>`, however, the `<i>` has odd
`style=""`. Perhaps, the test framework should ignore it because it's not
important for the web-compatibility.
On the other hand, Chrome completely fails only the last testcase since it
unwraps the `<b>` from the last `<br>`, so the bold style which was applied by
the web app to the last `<br>` is lost. This is not reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D152616
Currently I'm think that the split/join node direction should be managed per
`HTMLEditor` instance because per transaction makes undo/redo handling
complicated and may require additional space to save it in each transaction
instance. However, the direction should be changeable with new Gecko specific
`execCommand` to support both direction until creating first split/join node
transaction or anytime with clearing the transactions.
Differential Revision: https://phabricator.services.mozilla.com/D149192
Note that `CSSEditUtils` does not change `Selection` except
`RemoveCSSInlineStyleWithTransaction` which is used only by aligning in a block.
Therefore, this patch does not touch `CSSEditUtils`.
Differential Revision: https://phabricator.services.mozilla.com/D149106
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
`CSSEditUtils` will refer the composed document of the element to compute the
style of it. However, it'll fail if `RemoveStyleInside` has already removed
the element from the DOM tree. Therefore, `RemoveInlinePropertyInternal`
should stop handling the element immediately after calling `RemoveStyleInside`
if the element is removed.
Depends on D145303
Differential Revision: https://phabricator.services.mozilla.com/D145304
`CSSEditUtils::GetCSSEquivalentToHTMLInlineStyleSetInternal` may return error
which is unexpected. And the methods changed by this patch may cause destroying
editor if and only if they treat computed style. Therefore, they should be
non-static members and they should return error to make each caller avoid the
unexpected cases if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D145303
Now, it does not require to update selection, and its result may have a point
to put caret it is used to doing. This patch makes it stop collapsing selection
after each split, and instead, makes all callers of it collapse selection if
it's (probably) necessary.
Note that the method may not split any nodes but return it as "handled".
Therefore, the callers do not check whether a splitting node occurred **but**
suggesting point to put caret is invalid or the other cases. Therefore, in
strictly speaking, this patch changes the existing behavior, but it should not
affects web apps in the wild because of the low usage of the legacy mutation
event listeners.
Differential Revision: https://phabricator.services.mozilla.com/D144650
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
Like `JoinNodesResult`, `SplitNodeResult` should take 2 content nodes as
"new one" and "original one" instead of "previous one" and "next one".
Then, the creators is easier to read.
Additionally, this patch creates some static methods and converter method
to create a result with explaining the result meaning.
Differential Revision: https://phabricator.services.mozilla.com/D141930
Masayuki Nakano