In `TextEditor::HandleDeleteSelection()`, we have only one path of returning
`EditActionIgnored()`. Therefore, it should call
`DeleteSelectionWithTransaction()` directly.
On the other hand, it's not clear in `HTMLEditor::HandleDeleteSelection()`
since it may be called recursively by its helper methods. Therefore,
this patch creates `HTMLEditor::HandleDeleteSelectionInternal()` for the
recursive calls and makes `HTMLEditor::HandleDeleteSelection()` call
`DeleteSelectionWithTransaction()` if nobody handled it and to the
`HTMLEditor` specific post-process in it.
Differential Revision: https://phabricator.services.mozilla.com/D45301
--HG--
extra : moz-landing-system : lando
`TextEditor::DeleteSelectionAsSubAction()` starts to handle all
"delete selection" sub-actions (i.e., even if the instance is `HTMLEditor`).
Therefore, `TextEditRules::WillDeleteSelection()` should be renamed to
`TextEditor::HandleDeleteSelection()` and we need to make it virtual.
Differential Revision: https://phabricator.services.mozilla.com/D45300
--HG--
extra : moz-landing-system : lando
Oddly, they are used only by `HTMLEditor`, but implemented by `TextEditRules`.
They cancels when the editor is in plaintext mode. So, actual things are
implemented by each caller. This patch cleans them up too.
Differential Revision: https://phabricator.services.mozilla.com/D45299
--HG--
extra : moz-landing-system : lando
And also this patch moves `TextEditRules::HandleNewLines()` and
`TextEditRules::DontEchoPassword()` to `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D45298
--HG--
extra : moz-landing-system : lando
There are only 3 callers and it does simple but different 2 things. One of
the callers is `HTMLEditRules::DidDeleteSelection()` so that if same things
are done by `TextEditor::DeleteSelectionAsSubAction()`, it does not need to
duplicate the code. Therefore, we need to duplicate the code into
`TextEditor::DeleteSelectionAsSubAction()` and `TextEditRules::WillSetText()`.
Then, `TextEditRules::WillSetText()` can avoid accessing `Selection` since
it still grabs the modified text node.
Note that only when it's called by `TextEditRules::DidDoAction()`,
`AutoTransactionsConserveSelection` has been set. However, neither
`DeleteNodeWithTransaction()` nor `DeleteNodeTransaction::DoTransaction()`
changes `Selection`. Therefore, it hasn't do anything. So, we can remove
it right now.
Differential Revision: https://phabricator.services.mozilla.com/D45294
--HG--
extra : moz-landing-system : lando
Only caller of it is `WillRemoveAbsolutePosition()` and it always sets
`*aHandled` to true before calling it. Therefore, it does not need to take
it as an argument.
Differential Revision: https://phabricator.services.mozilla.com/D45291
--HG--
extra : moz-landing-system : lando
Oddly, absolute position is handled as following steps.
1. `WillAbsolutePosition()` calls `PrepareToMakeElementAbsolutePosition()`
to consider the target element.
2. Set TopLevelEditSubActionData::mNewBlockElement to it.
3. `DidAbsolutePosition()` makes it absolute-positioned.
So that, all of them can be done in `WillAbsolutePosition()` like other
edit sub-action handling.
Differential Revision: https://phabricator.services.mozilla.com/D45290
--HG--
extra : moz-landing-system : lando
And also this splits large 2 blocks of
`HTMLEditRules::AlignContentsAtSelection()` to 2 methods.
Differential Revision: https://phabricator.services.mozilla.com/D44790
--HG--
extra : moz-landing-system : lando
With guaranteeing the argument element type with `MOZ_ASSERT()`, we can
make it really simpler.
Differential Revision: https://phabricator.services.mozilla.com/D44789
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::MakeSureElemStartsOrEndsOnCR()` is unclear what it does.
And fortunately, its job is simple if we split it to each mode. Therefore,
this patch splits it to `EnsureHardLineBeginsWithFirstChildOf()` and
`EnsureHardLineEndsWithLastChildOf()`. Finally, the batch caller of them,
`HTMLEditRules::MakeSureElemStartsAndEndsOnCR()` is removed since directly
calling both of them is clearer.
Differential Revision: https://phabricator.services.mozilla.com/D44787
--HG--
extra : moz-landing-system : lando
The caller of `HTMLEditRules::WillDoAction()` is shared with "outdent".
Therefore, this patch is a preparation of makes `HTMLEditor` stop calling it.
Be aware, `HTMLEditRules::WillIndent()` won't cancel the action, and also
always handles the action unless editor has already been destroyed. Therefore,
we can remove the dead code in `HTMLEditor::IndentOrOutdentAsSubAction()`
right now.
Differential Revision: https://phabricator.services.mozilla.com/D44781
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
It scans children and returns whether `<dt>` and `<dd>` are found or not.
So, we can make it a stack class and makes caller pick the necessary value
with getter methods.
Differential Revision: https://phabricator.services.mozilla.com/D44461
--HG--
extra : moz-landing-system : lando
The next simple case is using early-return style and does not refer modified
`firstRangeStart` nor `firstRangeEnd` so that it can do same thing without
`AutoTrackDOMPoint`.
Then, there is remaining the complicated case. We cannot split it anymore.
Note that we should not split `HandleDeleteNonCollapsedSelection()` anymore
because as you know, it does not make sense. It checks only first range
and consider how to treat all ranges. We should split it after we investigate
deeper with writing new WPT.
Differential Revision: https://phabricator.services.mozilla.com/D44459
--HG--
extra : moz-landing-system : lando
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
