It restores `Selection` with `AutoSelectionRestorer` instance created first.
Therefore it does not want the callers (currently, only
`HTMLEditor::HandleOutdentAtSelection` only) change `Selection` after doing it
without special reasons. Therefore, it shouldn't return last caret point
suggestion which is not a good point to put caret actually. Then, callers
do not need to handle it as they've never done.
Differential Revision: https://phabricator.services.mozilla.com/D159231
nsISupports.h includes nsISupportsBase.h, so it should be equivalent.
In the next patch, I'm changing things so that nsISupports is defined in
nsISupports.h instead of nsISupportsBase.h, and deleting the latter, so
this change will be needed anyways. I'm guessing people were using IWYU
or something like that.
Differential Revision: https://phabricator.services.mozilla.com/D159169
Between splitting a node and undoing it, web apps can move split nodes anywhere.
Therefore, it shouldn't assume they are always in same parent node, and
`RangeUpdater::SelAdjJoinNodes` needs to handle it correctly.
Unfortunately, `RangeUpdater::SelAdjJoinNodes` cannot handle nested cases
correctly, e.g., right node was in `aRemovedContent` or right node was in
the container of `aStartOfRightContent.GetContainer()`. However, it's not
a new regression, and such complicated situation breaks undoing anyway.
Therefore, I think that we don't need to care about it for now.
Differential Revision: https://phabricator.services.mozilla.com/D159230
It's the only method which is used outside of the editor module. Therefore,
we can stop exposing `EditorUtils.h` later.
Depends on D158634
Differential Revision: https://phabricator.services.mozilla.com/D158635
It's currently referred from outside only by `TextServicesDocument.cpp`.
It's not under `libeditor` but in the editor module. Therefore, let's allow
it to refer the header files under `libeditor` directly. Then, we can stop
exposing `HTMLEditUtils.h`.
Depends on D158633
Differential Revision: https://phabricator.services.mozilla.com/D158634
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
It's always called with `DeleteSelectedContent::Yes`. Therefore, the argument
is not required. Then, its name can be `InsertFromTransferableAtSelection`.
Differential Revision: https://phabricator.services.mozilla.com/D158483
It just creates `HTMLWithContextInserter` and calls its `Run()`. Then, `Run()`
works as a sub action handler. Therefore, we can make `DoInsertHTMLWithContext`
(which sounds like a helper class of a handler method) a sub action handler.
Then, it can handle the optional insertion point in it and
`HTMLWithContextInserter::Run` does not need to handle it.
Differential Revision: https://phabricator.services.mozilla.com/D158482
They use `bool` arguments a lot. Therefore, some call-sites are hard to read.
They should be replaced with `enum class`es. Note that this patch does not
make the raw value of new `enum class`es to `bool` unless they are used in the
heap.
Differential Revision: https://phabricator.services.mozilla.com/D158481
`nsIEditor.undo` and `nsIEditor.redo` are called with `1` except by the search
bar, and search bar wants to undo everything to reset the value. Therefore,
search bar needs an API to undo all, and the others do not need the number of
undoing/redoing transactions. Therefore, this patch adds `nsIEditor.undoAll`
for search bar, and remove the arguments from `nsIEditor.undo` and
`nsIEditor.redo`.
Differential Revision: https://phabricator.services.mozilla.com/D158338
They are methods to take 2 out params, and it's not convenient for light use.
I think that there should be 3 attributes, `undoRedoEnabled`, `canUndo` and
`canRedo`. Then, the findbar does not need to check number of transactions
with `nsITransactionManager`.
Differential Revision: https://phabricator.services.mozilla.com/D158337
`nsIEditor.transactionManager` is used only for some simple purposes, however,
`nsIEditor` exposes the rich API. That makes it harder to maintain internal
code around transactions. Instead, `nsIEditor` exposes only simple and
necessary APIs.
This patch creates a new API to clear undo/redo history and make the users in
mozilla-central use it instead of using `nsITransactionManager.clear()`.
Differential Revision: https://phabricator.services.mozilla.com/D158336
I misunderstood the traditional behavior before bug 1789967, that is,
`HTMLEditor` collapsed `Selection` to end of the deepest last child container
element **or text node** of the `<body>`, rather than to end of **only** the
deepest last child container element. This misunderstanding caused the backout
of the first landing, but I didn't realize this mistake.
Therefore, this patch makes the crashtests which are touched in bug 1789967 and
the collapsed point is at a text node (or failed to consider the collapsed
point) collapse `Selection` to end of the deepest last text node of their
`<body>` elements.
Differential Revision: https://phabricator.services.mozilla.com/D158177
If splitting element is a list item element,
`HandleInsertParagraphInListItemElement` may just move it into a list element
if it's followed by the list element, or may create new paragraph element if
the list item element is empty and last list item element.
If splitting element is a heading element,
`HandleInsertParagraphInHeadingElement` may create new paragraph element if
splitting at end of the heading element and not followed by `<br>`.
Therefore, neither `SplitNodeResult` nor `CreateElementResult` is proper for
their result type, and the caller `InsertParagraphSeparatorAsSubAction`, just
wants to know the right handle element which should contain caret and a caret
point suggestion.
For solving these issues, this gives an alias to `CreateElementResult`, makes
them return the right paragraph even if it's not newly created nor split
element, and replaces `blockElementToPutCaret` with the returned element.
Differential Revision: https://phabricator.services.mozilla.com/D158106
The test compares the node name of the split element and its previous sibling
element, so it should switch the scanning direction with the pref to switch
split node direction.
Note that the behavior is different from the other browsers in some cases.
Therefore, we cannot port this to WPT.
Differential Revision: https://phabricator.services.mozilla.com/D158105
The check assumes that the container of `aPointToInsert` is always right node.
However, its child is moved to new node if we switch the direction, so we should
make it check the edge case with `SplitNodeResult::GetNextContent()`.
Differential Revision: https://phabricator.services.mozilla.com/D158104
The reason why the changes of `SplitNodeTransaction` is smaller than
`JoinNodesTransaction` is, `HTMLEditor::DoSplitNode` does almost all things
instead.
Differential Revision: https://phabricator.services.mozilla.com/D158102
This patch adds new path to adjust selection for the new split node direction.
So this does not change any behavior of the existing path.
Differential Revision: https://phabricator.services.mozilla.com/D158100
This changes the existing path's behavior a bit. However, it should not affect
to web apps in the wild because it must be really rare case that web apps
inserting new nodes into the removing node while moving its children.
Differential Revision: https://phabricator.services.mozilla.com/D158099
This patch add new path to adjust selection for the new join nodes direction.
So this does not change any behavior of the existing path.
Differential Revision: https://phabricator.services.mozilla.com/D158098
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
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
Masayuki Nakano
Sandor Molnar
Tom Schuster
Andrew McCreight
Jan-Niklas Jaeschke
Cristian Tuns
Olli Pettay
Chengyu Sun
Butkovits Atila