2001-09-26 02:53:13 +04:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
2012-05-21 15:12:37 +04:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
1999-01-14 21:02:45 +03:00
|
|
|
|
2016-07-07 09:08:33 +03:00
|
|
|
#include "DeleteNodeTransaction.h"
|
Bug 1627175 - part 2: Move `EditorBase::IsModifiableNode()`, `EditorBase::IsEditable()`, `EditorBase::IsTextElementOrText()` and `EditorBase::IsPaddingBRElementForEmptyEditor()` to `EditorUtils` r=m_kato
Due to the include hell, `EditorBase.h` cannot include `EditorUtils.h`.
Therefore we need these 3 methods once. Additionally, `IsModifiableNode()`
is really odd method and looks like that it's used for the following 2 purposes:
1. Simply can be editable.
2. Can be removed from parent.
For the former case, we should sort out it with
`EditorUtils::IsEditableContent()`, but for now, this patch moves it to
`HTMLEditUtils::IsSimplyEditable()`. On the other hand, for the latter case,
we obviously has a bug. Therefore, this patch creates
`HTMLEditUtils::IsRemovableFromParentNode()` and make it check whether the
removing node is also editable.
Unfortunately, `EditorUtils::IsEditableContent()` needs to take editor type.
But it's most callers are in `HTMLEditor` and most of remains are in
common methods of `EditorBase`. I guess we could remove this ugly argument
in the future.
Depends on D70874
Differential Revision: https://phabricator.services.mozilla.com/D70875
--HG--
extra : moz-landing-system : lando
2020-04-15 18:27:38 +03:00
|
|
|
|
Bug 1797247 - part 1: Add delete transaction classes to use build time type checks r=m_kato
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
2023-02-16 01:17:17 +03:00
|
|
|
#include "EditorBase.h"
|
|
|
|
#include "EditorDOMPoint.h"
|
Bug 1627175 - part 2: Move `EditorBase::IsModifiableNode()`, `EditorBase::IsEditable()`, `EditorBase::IsTextElementOrText()` and `EditorBase::IsPaddingBRElementForEmptyEditor()` to `EditorUtils` r=m_kato
Due to the include hell, `EditorBase.h` cannot include `EditorUtils.h`.
Therefore we need these 3 methods once. Additionally, `IsModifiableNode()`
is really odd method and looks like that it's used for the following 2 purposes:
1. Simply can be editable.
2. Can be removed from parent.
For the former case, we should sort out it with
`EditorUtils::IsEditableContent()`, but for now, this patch moves it to
`HTMLEditUtils::IsSimplyEditable()`. On the other hand, for the latter case,
we obviously has a bug. Therefore, this patch creates
`HTMLEditUtils::IsRemovableFromParentNode()` and make it check whether the
removing node is also editable.
Unfortunately, `EditorUtils::IsEditableContent()` needs to take editor type.
But it's most callers are in `HTMLEditor` and most of remains are in
common methods of `EditorBase`. I guess we could remove this ugly argument
in the future.
Depends on D70874
Differential Revision: https://phabricator.services.mozilla.com/D70875
--HG--
extra : moz-landing-system : lando
2020-04-15 18:27:38 +03:00
|
|
|
#include "HTMLEditUtils.h"
|
Bug 1797247 - part 1: Add delete transaction classes to use build time type checks r=m_kato
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
2023-02-16 01:17:17 +03:00
|
|
|
#include "SelectionState.h" // RangeUpdater
|
|
|
|
#include "TextEditor.h"
|
|
|
|
|
2021-04-05 14:35:48 +03:00
|
|
|
#include "mozilla/Logging.h"
|
|
|
|
#include "mozilla/ToString.h"
|
Bug 1797247 - part 1: Add delete transaction classes to use build time type checks r=m_kato
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
2023-02-16 01:17:17 +03:00
|
|
|
|
2012-07-13 10:33:42 +04:00
|
|
|
#include "nsDebug.h"
|
|
|
|
#include "nsError.h"
|
|
|
|
#include "nsAString.h"
|
1999-01-21 22:44:26 +03:00
|
|
|
|
2016-07-07 09:08:33 +03:00
|
|
|
namespace mozilla {
|
1999-01-21 04:51:09 +03:00
|
|
|
|
2017-12-15 15:24:33 +03:00
|
|
|
// static
|
|
|
|
already_AddRefed<DeleteNodeTransaction> DeleteNodeTransaction::MaybeCreate(
|
2020-04-03 11:30:37 +03:00
|
|
|
EditorBase& aEditorBase, nsIContent& aContentToDelete) {
|
2017-12-15 15:24:33 +03:00
|
|
|
RefPtr<DeleteNodeTransaction> transaction =
|
2020-04-03 11:30:37 +03:00
|
|
|
new DeleteNodeTransaction(aEditorBase, aContentToDelete);
|
2017-12-15 15:24:33 +03:00
|
|
|
if (NS_WARN_IF(!transaction->CanDoIt())) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
return transaction.forget();
|
|
|
|
}
|
|
|
|
|
2017-03-10 07:23:40 +03:00
|
|
|
DeleteNodeTransaction::DeleteNodeTransaction(EditorBase& aEditorBase,
|
2020-04-03 11:30:37 +03:00
|
|
|
nsIContent& aContentToDelete)
|
Bug 1797247 - part 1: Add delete transaction classes to use build time type checks r=m_kato
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
2023-02-16 01:17:17 +03:00
|
|
|
: DeleteContentTransactionBase(aEditorBase),
|
2020-04-03 11:30:37 +03:00
|
|
|
mContentToDelete(&aContentToDelete),
|
2021-08-25 03:39:41 +03:00
|
|
|
mParentNode(aContentToDelete.GetParentNode()) {
|
2021-09-15 03:20:19 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT_IF(
|
|
|
|
aEditorBase.IsHTMLEditor(),
|
|
|
|
HTMLEditUtils::IsRemovableNode(aContentToDelete) ||
|
|
|
|
// It's okay to delete text node if it's added by `HTMLEditor` since
|
|
|
|
// remaining it may be noisy for the users.
|
|
|
|
(aContentToDelete.IsText() &&
|
|
|
|
aContentToDelete.HasFlag(NS_MAYBE_MODIFIED_FREQUENTLY)));
|
|
|
|
NS_ASSERTION(
|
|
|
|
!aEditorBase.IsHTMLEditor() ||
|
|
|
|
HTMLEditUtils::IsRemovableNode(aContentToDelete),
|
|
|
|
"Deleting non-editable text node, please write a test for this!!");
|
2021-08-25 03:39:41 +03:00
|
|
|
}
|
1999-01-14 21:02:45 +03:00
|
|
|
|
2021-04-05 14:35:48 +03:00
|
|
|
std::ostream& operator<<(std::ostream& aStream,
|
|
|
|
const DeleteNodeTransaction& aTransaction) {
|
|
|
|
aStream << "{ mContentToDelete=" << aTransaction.mContentToDelete.get();
|
|
|
|
if (aTransaction.mContentToDelete) {
|
|
|
|
aStream << " (" << *aTransaction.mContentToDelete << ")";
|
|
|
|
}
|
|
|
|
aStream << ", mParentNode=" << aTransaction.mParentNode.get();
|
|
|
|
if (aTransaction.mParentNode) {
|
|
|
|
aStream << " (" << *aTransaction.mParentNode << ")";
|
|
|
|
}
|
|
|
|
aStream << ", mRefContent=" << aTransaction.mRefContent.get();
|
|
|
|
if (aTransaction.mRefContent) {
|
|
|
|
aStream << " (" << *aTransaction.mRefContent << ")";
|
|
|
|
}
|
|
|
|
aStream << ", mEditorBase=" << aTransaction.mEditorBase.get() << " }";
|
|
|
|
return aStream;
|
|
|
|
}
|
|
|
|
|
Bug 1797247 - part 1: Add delete transaction classes to use build time type checks r=m_kato
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
2023-02-16 01:17:17 +03:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_INHERITED(DeleteNodeTransaction,
|
|
|
|
DeleteContentTransactionBase,
|
|
|
|
mContentToDelete, mParentNode, mRefContent)
|
2009-05-09 08:59:25 +04:00
|
|
|
|
Bug 1797247 - part 1: Add delete transaction classes to use build time type checks r=m_kato
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
2023-02-16 01:17:17 +03:00
|
|
|
NS_IMPL_ADDREF_INHERITED(DeleteNodeTransaction, DeleteContentTransactionBase)
|
|
|
|
NS_IMPL_RELEASE_INHERITED(DeleteNodeTransaction, DeleteContentTransactionBase)
|
2016-07-07 09:08:33 +03:00
|
|
|
NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION(DeleteNodeTransaction)
|
Bug 1797247 - part 1: Add delete transaction classes to use build time type checks r=m_kato
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
2023-02-16 01:17:17 +03:00
|
|
|
NS_INTERFACE_MAP_END_INHERITING(DeleteContentTransactionBase)
|
2009-05-09 08:59:25 +04:00
|
|
|
|
2017-03-10 07:23:40 +03:00
|
|
|
bool DeleteNodeTransaction::CanDoIt() const {
|
2020-04-03 11:30:37 +03:00
|
|
|
if (NS_WARN_IF(!mContentToDelete) || NS_WARN_IF(!mEditorBase) ||
|
Bug 1627175 - part 2: Move `EditorBase::IsModifiableNode()`, `EditorBase::IsEditable()`, `EditorBase::IsTextElementOrText()` and `EditorBase::IsPaddingBRElementForEmptyEditor()` to `EditorUtils` r=m_kato
Due to the include hell, `EditorBase.h` cannot include `EditorUtils.h`.
Therefore we need these 3 methods once. Additionally, `IsModifiableNode()`
is really odd method and looks like that it's used for the following 2 purposes:
1. Simply can be editable.
2. Can be removed from parent.
For the former case, we should sort out it with
`EditorUtils::IsEditableContent()`, but for now, this patch moves it to
`HTMLEditUtils::IsSimplyEditable()`. On the other hand, for the latter case,
we obviously has a bug. Therefore, this patch creates
`HTMLEditUtils::IsRemovableFromParentNode()` and make it check whether the
removing node is also editable.
Unfortunately, `EditorUtils::IsEditableContent()` needs to take editor type.
But it's most callers are in `HTMLEditor` and most of remains are in
common methods of `EditorBase`. I guess we could remove this ugly argument
in the future.
Depends on D70874
Differential Revision: https://phabricator.services.mozilla.com/D70875
--HG--
extra : moz-landing-system : lando
2020-04-15 18:27:38 +03:00
|
|
|
!mParentNode) {
|
2017-03-10 07:23:40 +03:00
|
|
|
return false;
|
|
|
|
}
|
Bug 1627175 - part 2: Move `EditorBase::IsModifiableNode()`, `EditorBase::IsEditable()`, `EditorBase::IsTextElementOrText()` and `EditorBase::IsPaddingBRElementForEmptyEditor()` to `EditorUtils` r=m_kato
Due to the include hell, `EditorBase.h` cannot include `EditorUtils.h`.
Therefore we need these 3 methods once. Additionally, `IsModifiableNode()`
is really odd method and looks like that it's used for the following 2 purposes:
1. Simply can be editable.
2. Can be removed from parent.
For the former case, we should sort out it with
`EditorUtils::IsEditableContent()`, but for now, this patch moves it to
`HTMLEditUtils::IsSimplyEditable()`. On the other hand, for the latter case,
we obviously has a bug. Therefore, this patch creates
`HTMLEditUtils::IsRemovableFromParentNode()` and make it check whether the
removing node is also editable.
Unfortunately, `EditorUtils::IsEditableContent()` needs to take editor type.
But it's most callers are in `HTMLEditor` and most of remains are in
common methods of `EditorBase`. I guess we could remove this ugly argument
in the future.
Depends on D70874
Differential Revision: https://phabricator.services.mozilla.com/D70875
--HG--
extra : moz-landing-system : lando
2020-04-15 18:27:38 +03:00
|
|
|
return mEditorBase->IsTextEditor() ||
|
|
|
|
HTMLEditUtils::IsSimplyEditableNode(*mParentNode);
|
1999-01-14 21:02:45 +03:00
|
|
|
}
|
|
|
|
|
2020-03-09 17:57:23 +03:00
|
|
|
NS_IMETHODIMP DeleteNodeTransaction::DoTransaction() {
|
2021-04-05 14:35:48 +03:00
|
|
|
MOZ_LOG(GetLogModule(), LogLevel::Info,
|
|
|
|
("%p DeleteNodeTransaction::%s this=%s", this, __FUNCTION__,
|
|
|
|
ToString(*this).c_str()));
|
|
|
|
|
2017-03-10 07:23:40 +03:00
|
|
|
if (NS_WARN_IF(!CanDoIt())) {
|
2012-06-19 17:23:36 +04:00
|
|
|
return NS_OK;
|
1999-01-21 04:51:09 +03:00
|
|
|
}
|
1999-01-14 21:02:45 +03:00
|
|
|
|
2021-06-18 03:36:53 +03:00
|
|
|
MOZ_ASSERT_IF(mEditorBase->IsTextEditor(), !mContentToDelete->IsText());
|
2019-07-22 06:53:36 +03:00
|
|
|
|
2020-04-03 11:30:37 +03:00
|
|
|
// Remember which child mContentToDelete was (by remembering which child was
|
|
|
|
// next). Note that mRefContent can be nullptr.
|
|
|
|
mRefContent = mContentToDelete->GetNextSibling();
|
1999-01-14 21:02:45 +03:00
|
|
|
|
2012-06-19 17:23:36 +04:00
|
|
|
// give range updater a chance. SelAdjDeleteNode() needs to be called
|
2016-06-24 08:44:14 +03:00
|
|
|
// *before* we do the action, unlike some of the other RangeItem update
|
2012-06-19 17:23:36 +04:00
|
|
|
// methods.
|
2020-04-03 11:30:37 +03:00
|
|
|
mEditorBase->RangeUpdaterRef().SelAdjDeleteNode(*mContentToDelete);
|
2002-11-10 18:11:08 +03:00
|
|
|
|
2020-04-03 11:30:37 +03:00
|
|
|
OwningNonNull<nsINode> parentNode = *mParentNode;
|
|
|
|
OwningNonNull<nsIContent> contentToDelete = *mContentToDelete;
|
2012-10-09 16:31:24 +04:00
|
|
|
ErrorResult error;
|
2020-04-03 11:30:37 +03:00
|
|
|
parentNode->RemoveChild(contentToDelete, error);
|
2020-03-09 17:57:23 +03:00
|
|
|
NS_WARNING_ASSERTION(!error.Failed(), "nsINode::RemoveChild() failed");
|
2015-04-27 16:18:51 +03:00
|
|
|
return error.StealNSResult();
|
1999-01-14 21:02:45 +03:00
|
|
|
}
|
|
|
|
|
Bug 1797247 - part 1: Add delete transaction classes to use build time type checks r=m_kato
First, `EditorBase::CreateTransactionForDeleteSelection` returns an instance of
`EditAggregateTransaction`. It's a base class of `PlaceholderTransaction` and
`DeleteRangeTransaction` but it's also a concrete class. However, it's too
generic. Therefore, this patch creates `DeleteMultipleRangesTransaction` which
is a simple sub-class of it, and makes `EditAggregateTransaction` be an abstract
class. Then, add `AddChild` methods to each concrete class to restrict the
type of child transactions.
Next, `DeleteRangeTransaction` contains only `DeleteNodeTransaction` and
`DeleteTextTransaction`. Therefore, once they have a common base class,
we can check the type easier. Therefore, this patch also adds
`DeleteContentTransactionBase` and
`EditorBase::CreateTransactionForCollapsedRange` becomes clearer what it
returns.
With these changes, `DeleteRangeTransaction` obviously contains only
`DeleteContentTransactionBase`, `DeleteMultipleRangesTransaction` contains only
`DeleteRangeTransaction`, `DeleteNodeTransaction` and `DeleteTextTransaction`.
And they are guaranteed at build time (at least from outside the classes).
***
fix
Differential Revision: https://phabricator.services.mozilla.com/D169038
2023-02-16 01:17:17 +03:00
|
|
|
EditorDOMPoint DeleteNodeTransaction::SuggestPointToPutCaret() const {
|
|
|
|
return EditorDOMPoint();
|
|
|
|
}
|
|
|
|
|
2021-04-05 14:35:48 +03:00
|
|
|
NS_IMETHODIMP DeleteNodeTransaction::UndoTransaction() {
|
|
|
|
MOZ_LOG(GetLogModule(), LogLevel::Info,
|
|
|
|
("%p DeleteNodeTransaction::%s this=%s", this, __FUNCTION__,
|
|
|
|
ToString(*this).c_str()));
|
|
|
|
|
2017-03-10 07:23:40 +03:00
|
|
|
if (NS_WARN_IF(!CanDoIt())) {
|
|
|
|
// This is a legal state, the transaction is a no-op.
|
2012-06-19 17:23:36 +04:00
|
|
|
return NS_OK;
|
2010-01-18 02:11:04 +03:00
|
|
|
}
|
2012-10-09 16:31:24 +04:00
|
|
|
ErrorResult error;
|
2020-04-03 11:30:37 +03:00
|
|
|
OwningNonNull<EditorBase> editorBase = *mEditorBase;
|
|
|
|
OwningNonNull<nsINode> parentNode = *mParentNode;
|
|
|
|
OwningNonNull<nsIContent> contentToDelete = *mContentToDelete;
|
|
|
|
nsCOMPtr<nsIContent> refContent = mRefContent;
|
|
|
|
// XXX Perhaps, we should check `refContent` is a child of `parentNode`,
|
|
|
|
// and if it's not, we should stop undoing or something.
|
|
|
|
parentNode->InsertBefore(contentToDelete, refContent, error);
|
2020-07-01 16:13:13 +03:00
|
|
|
// InsertBefore() may call MightThrowJSException() even if there is no error.
|
|
|
|
// We don't need the flag here.
|
|
|
|
error.WouldReportJSException();
|
2020-03-09 17:57:23 +03:00
|
|
|
if (error.Failed()) {
|
|
|
|
NS_WARNING("nsINode::InsertBefore() failed");
|
2019-07-22 06:53:36 +03:00
|
|
|
return error.StealNSResult();
|
|
|
|
}
|
|
|
|
return NS_OK;
|
1999-01-14 21:02:45 +03:00
|
|
|
}
|
|
|
|
|
2020-03-09 17:57:23 +03:00
|
|
|
NS_IMETHODIMP DeleteNodeTransaction::RedoTransaction() {
|
2021-04-05 14:35:48 +03:00
|
|
|
MOZ_LOG(GetLogModule(), LogLevel::Info,
|
|
|
|
("%p DeleteNodeTransaction::%s this=%s", this, __FUNCTION__,
|
|
|
|
ToString(*this).c_str()));
|
|
|
|
|
2017-03-10 07:23:40 +03:00
|
|
|
if (NS_WARN_IF(!CanDoIt())) {
|
|
|
|
// This is a legal state, the transaction is a no-op.
|
2012-06-19 17:23:36 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
1999-01-14 21:02:45 +03:00
|
|
|
|
2020-04-03 11:30:37 +03:00
|
|
|
mEditorBase->RangeUpdaterRef().SelAdjDeleteNode(*mContentToDelete);
|
2002-11-10 18:11:08 +03:00
|
|
|
|
2020-04-03 11:30:37 +03:00
|
|
|
OwningNonNull<nsINode> parentNode = *mParentNode;
|
|
|
|
OwningNonNull<nsIContent> contentToDelete = *mContentToDelete;
|
2012-10-09 16:31:24 +04:00
|
|
|
ErrorResult error;
|
2020-04-03 11:30:37 +03:00
|
|
|
parentNode->RemoveChild(contentToDelete, error);
|
2020-03-09 17:57:23 +03:00
|
|
|
NS_WARNING_ASSERTION(!error.Failed(), "nsINode::RemoveChild() failed");
|
2015-04-27 16:18:51 +03:00
|
|
|
return error.StealNSResult();
|
1999-01-14 21:02:45 +03:00
|
|
|
}
|
|
|
|
|
2016-07-07 09:08:33 +03:00
|
|
|
} // namespace mozilla
|