Before splitting the method, we should make it use `EditorDOMPoint` to
treat selection edges.
Differential Revision: https://phabricator.services.mozilla.com/D44455
--HG--
extra : moz-landing-system : lando
First, we can split it with 3 parts:
1. preparation with current selection part.
2. handling deletion with collapsed selection part.
3. handling deletion with non-collapsed selection part.
The first should leave in `WillDeleteSelection()`, but the others should be
moved to independent methods.
With this change, we need to fix an odd case when there is no visible node
and `GetFirstSelectedTableCellElement()` returned error due to crossing
the method boundary. The method returns error only when there is no selection
ranges. In such case, we cannot handle deletion of current selection anyway.
So, it must not be a problem to handle the error immediately after calling
`GetFirstSelectedTableCellElement()`. Note that this shouldn't occur in
normal cases since `WillDoAction()` checks it before calling
`WillDeleteSelection()`.
Differential Revision: https://phabricator.services.mozilla.com/D44453
--HG--
extra : moz-landing-system : lando
Before moving the largest method in our tree, we should split it. This is
first preparation of that.
Differential Revision: https://phabricator.services.mozilla.com/D44451
--HG--
extra : moz-landing-system : lando
And this patch makes the new method do not touch `Selection`, instead, return
new `StaticRange`. Although the creation cost may make damage to the
performance but let's keep using `StaticRange` for now. There should be
a stack only class which have 2 `RangeBoundaryBase` or `EditorDOMPointBase`.
Differential Revision: https://phabricator.services.mozilla.com/D44205
--HG--
extra : moz-landing-system : lando
Additionally, `WSRunObject::ScrabBlockBoundary()` and
`WSRunObject::PreparetToJoinBlocks()` are used only the it. Therefore, we
can clean them up.
Differential Revision: https://phabricator.services.mozilla.com/D44201
--HG--
extra : moz-landing-system : lando
Making them return next insertion point with `nsresult` makes the callers
easier to understand. Therefore, this patch declares `MoveNodeResult` class
newly and make them use it.
And also we can get rid of the case of setting `*aInOutDestOffset` to -1
because it's a hacky case of `HTMLEditRules::MoveBlock()`. If we keep it,
`MoveNodeSmart()` needs to compute new insertion point with different logic.
Therefore, this patch makes `HTMLEditRules::MoveBlock()` adjust new insertion
point with checking its argument.
Differential Revision: https://phabricator.services.mozilla.com/D44199
--HG--
extra : moz-landing-system : lando
This is defined as too complicated than what it does actually since there
was not `EditorDOMPointBase`.
If given point's offset is `0`, returns `nullptr`. If `aWhere` is
`BRLocation::blockEnd`, treats `aOffset` is length of `aBlock`. Otherwise,
using given point. Then, if the `WSRun` start reason is `br`, returns the
start reason node. This means that this method just retrieves invisible
`<br>` element if it starts `WSRun` at given point.
Now, callers can specify end of block with `EditorDOMPointBase::SetToEndOf()`
easier. Therefore, we can make it take only an `EditorDOMPointBase` instance.
Differential Revision: https://phabricator.services.mozilla.com/D44197
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::WillMakeDefinitionList()` just calls
`HTMLEditRules::WillMakeList()` and `HTMLEditRules::WillMakeList()` can be
called as `HTMLEditRules::MakeOrChangeListAndListItemAsSubAction()` so that
we should merge them and make `HTMLEditor` call it directly.
This patch also removes default action part of
`HTMLEditor::MakeOrChangeListAsAction()` because it runs only when
`HTMLEditRules::WillDoAction()` does not return canceled nor error but not
handled, however, it's won't occur since `HTMLEditRules::WillMakeList()`
always sets `aHandled` to `true` when it returns `NS_OK`.
Differential Revision: https://phabricator.services.mozilla.com/D44195
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes it use early-return style with `continue` as
far as making number of changing line minimized.
Differential Revision: https://phabricator.services.mozilla.com/D44194
--HG--
extra : moz-landing-system : lando
Meaningful job of `HTMLEditor::InsertParagraphSeparatorAsSubAction()` is only
calling `HTMLEditRules::WillInsertParagraph()` via
`HTMLEditRules::WillDoAction()`. Therefore, we can move all jobs in them
into `HTMLEditRules::WillInsertParagraph()` and rename it to
`HTMLEditor::InsertParagraphSeparatorAsSubAction()`.
Differential Revision: https://phabricator.services.mozilla.com/D44190
--HG--
extra : moz-landing-system : lando
It's used both by `TextEditRules` and `HTMLEditRules` so that `EditorBase`
should have it instead.
Differential Revision: https://phabricator.services.mozilla.com/D44188
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::WillMakeBasicBlock()` just calls
`HTMLEditor::FormatBlockContainer()` and it's called only for
`EditSubAction::eCreateOrRemoveBlock` and it's used only in
`HTMLEditor::InsertBasicBlockWithTransaction()`. Therefore, we can replace
calling `HTMLEditRules::WillDoAction()` in it with what
`HTMLEditRules::WIllMakeBasicBlock()` does.
First, `HTMLEditRules::WillDoAction()` checks whether first selection range
is editable. If it's not so, it returns `NS_OK` with setting `aCancel` to
`true`. Therefore, this patch moves this part to
`HTMLEditor::CanHandleHTMLEditSubAction()` for making
`HTMLEditor::InsertBasicBlockWithTransaction()` can check it easier.
Next, `HTMLEditor::InsertBasicBlockWithTransaction()` does something if
`HTMLEditRules::WillDoAction()` returns as not handled nor canceled.
However, this special handling requires at least one selection range:
https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/editor/libeditor/HTMLEditor.cpp#2284-2288
Surprisingly, `handled` is set to `false` only when there is an error or
there is no selection range. Therefore, this long block has already been
dead code so that we can remove this. Removing this block causes that we
become not throwing exception when `Document.execCommand("formatblock")`
without selection ranges. But this is better since Chrome does not throw
excption.
Finally, this patch renames some related methods:
- `HTMLEditor::FormatBlockContainer()` -> `HTMLEditor::FormatBlockContainerWithTransaction()`
- `HTMLEditor::InsertBasicBlockWithTransaction()` -> `HTMLEditor::FormatBlockContainerAsSubAction()`
Differential Revision: https://phabricator.services.mozilla.com/D44179
--HG--
extra : moz-landing-system : lando
And this fixes the caller which has not guaranteed the lifetime of the
start container.
Differential Revision: https://phabricator.services.mozilla.com/D44175
--HG--
extra : moz-landing-system : lando
Since bug 1577443 is landed in comm-central, no one uses `nsIHTMLEditor.getLinkedObject`.
Differential Revision: https://phabricator.services.mozilla.com/D44361
--HG--
extra : moz-landing-system : lando
This patch fixes an existing bug with this clean up.
Except `HTMLEditRules::MoveBlock()`, `GetListActionNodes()` is called after
calling `SplitInlinesAndCollectEditTargetNodesInExtendedSelectionRanges()`
or `CollectEditTargetNodesInExtendedSelectionRanges()` **with**
`EditSubAction::eCreateOrChangeList`. I think that `HTMLEditRules::MoveBlock()`
using the edit sub-action is a simple mistake. Perhaps, it should be
`EditSubAction::eCreateOrRemvoeBlock`. However, I'm not 100% sure because
`HTMLEditor::CollectEditTargetNodes()` does special handling for
`EditSubAction::eCreateOrRemvoeBlock` but not so for
`EditSubAction::eCreateOrChangeList`. The behavior of difference between
those edit sub-actions are only here. Therefore, this patch creates new
`EditSubAction` `eMergeBlockContents` for `MoveBlock()`.
Then, this patch makes `HTMLEditor::CollectEditTargetNodes()` handle
`EditSubAction::eCreateOrChangeList` insead of `GetListActionNodes()`.
This causes one logic change in `SplitInlinesAndCollectEditTargetNodes()`.
It calls `MaybeSplitElementsAtEveryBRElement()` after `CollectEditTargetNodes()`
so that this change makes calling `MaybeSplitElementsAtEveryBRElement()` at
last. According to my tests, new behavior must be expected since `<br>`
elements outside and in `<table>` should be handled consistently. Therefore,
this patch adds some simple testcases into WPT.
Differential Revision: https://phabricator.services.mozilla.com/D43190
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::GetListActionNodes()` removes non-editable element. However,
this should've been done by collector methods.
Differential Revision: https://phabricator.services.mozilla.com/D43026
--HG--
extra : moz-landing-system : lando
First half of `HTMLEditoRules::GetListActionNodes()` does 2 things. One is
trying to get parent list element of `Selection` ranges if `aEntireList` is
`EntireList::yes`. If it found a list element, it does nothing anymore.
Otherwise, falls backs to `EntireList::no` case. So, if each caller which
calls it with `EntireList::yes`, `GetListActionNodes()` does not need the
argument. Therefore, this patch does it first.
Then, `GetListActionNodes()` calls
`CollectEditTargetNodesInExtendedSelectionRanges()` or
`SplitInlinesAndCollectEditTargetNodesInExtendedSelectionRanges()`. It's
considered with `aTouchContent` is `yes` or `no`. So, this should be done
by each caller for making it clearer.
Differential Revision: https://phabricator.services.mozilla.com/D43024
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::LookInsideDivBQandList()` does complicated things and I cannot
explain with a method name what it does. Fortunately, there are only 2 callers.
Therefore, this patch duplicates the part of modifying the range and creates
a method to retrieve "deepest and only editable child of `<div>`, `<blockquote>`
and one of list items".
Differential Revision: https://phabricator.services.mozilla.com/D43023
--HG--
extra : moz-landing-system : lando
It just collects all children of given node so that it can be a static method
in `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D43022
--HG--
extra : moz-landing-system : lando
It's called only from `HTMLEditRules::MoveBlock()`. Even though it has 4
patters to call different methods, we need only one of them. Therefore,
this patch moves it into `HTMLEditor.h` as
`SplitInlinesAndCollectEditTargetNodesInOneHardLine()`.
Differential Revision: https://phabricator.services.mozilla.com/D43021
--HG--
extra : moz-landing-system : lando
