gecko-dev/editor/libeditor/EditTransactionBase.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

94 строки
3.5 KiB
C++
Исходник Обычный вид История

/* -*- 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/. */
#include "mozilla/EditTransactionBase.h"
#include "mozilla/Logging.h"
#include "ChangeAttributeTransaction.h"
#include "ChangeStyleTransaction.h"
#include "CompositionTransaction.h"
#include "DeleteNodeTransaction.h"
#include "DeleteRangeTransaction.h"
#include "DeleteTextTransaction.h"
#include "EditAggregateTransaction.h"
#include "InsertNodeTransaction.h"
#include "InsertTextTransaction.h"
#include "JoinNodesTransaction.h"
Bug 1766355 - part 1: Add `MoveNodeTransaction` to handle delete node and insert node in a transaction class instance r=m_kato Creating both `DeleteNodeTransaction` and `InsertNodeTransaction` wastes memory. They should be done in an instance instead. Fortunately, no edit action listener checks whether the deleted node is still in the composed document or not, etc. Therefore, we can simply notify them of both deletion and insertion which were done in `EditorBase::InsertNodeWithTransaction` and `EditorBase::DeleteNodeWithTransaction`. Note that previously, the range updater needs to ignore the notifications from them while the node is being moved. However, it does not require anymore. Therefore, this patch makes it stop locking, and that would fix minor problem in the case of legacy mutation event listeners run another edit action. On the other hand, this changes some edge cases handling of `MoveNodeWithTransaction` which are detected by the WPT. According to the previous result of applying this patch, `nsINode::InsertBefore` fails and that leads some errors at updating the changed range. I guess that the cause is that there is some bugs at updating insertion point after deleting the node from the DOM tree around here: https://searchfox.org/mozilla-central/rev/0ffae75b690219858e5a45a39f8759a8aee7b9a2/editor/libeditor/HTMLEditor.cpp#5058-5071 However, it's safely fixed by the new code which does not remove the node from the DOM tree explicitly. So, I think that it's safe to accept this behavior change for web apps in the wild. Differential Revision: https://phabricator.services.mozilla.com/D146397
2022-05-20 11:28:08 +03:00
#include "MoveNodeTransaction.h"
#include "PlaceholderTransaction.h"
#include "ReplaceTextTransaction.h"
#include "SplitNodeTransaction.h"
#include "nsError.h"
#include "nsISupportsBase.h"
namespace mozilla {
NS_IMPL_CYCLE_COLLECTION_CLASS(EditTransactionBase)
NS_IMPL_CYCLE_COLLECTION_UNLINK_0(EditTransactionBase)
NS_IMPL_CYCLE_COLLECTION_TRAVERSE_BEGIN(EditTransactionBase)
// We don't have anything to traverse, but some of our subclasses do.
NS_IMPL_CYCLE_COLLECTION_TRAVERSE_END
NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION(EditTransactionBase)
NS_INTERFACE_MAP_ENTRY(nsITransaction)
NS_INTERFACE_MAP_ENTRY_AMBIGUOUS(nsISupports, nsITransaction)
NS_INTERFACE_MAP_END
NS_IMPL_CYCLE_COLLECTING_ADDREF(EditTransactionBase)
NS_IMPL_CYCLE_COLLECTING_RELEASE(EditTransactionBase)
NS_IMETHODIMP EditTransactionBase::RedoTransaction() {
MOZ_LOG(GetLogModule(), LogLevel::Info, ("%p %s", this, __FUNCTION__));
return DoTransaction();
}
NS_IMETHODIMP EditTransactionBase::GetIsTransient(bool* aIsTransient) {
MOZ_LOG(GetLogModule(), LogLevel::Verbose,
("%p %s returned false", this, __FUNCTION__));
*aIsTransient = false;
return NS_OK;
}
NS_IMETHODIMP EditTransactionBase::Merge(nsITransaction* aOtherTransaction,
bool* aDidMerge) {
MOZ_LOG(GetLogModule(), LogLevel::Info,
("%p %s(aOtherTransaction=%p) returned false", this, __FUNCTION__,
aOtherTransaction));
*aDidMerge = false;
return NS_OK;
}
// static
LogModule* EditTransactionBase::GetLogModule() {
static LazyLogModule sLog("EditorTransaction");
return static_cast<LogModule*>(sLog);
}
#define NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(aClass) \
aClass* EditTransactionBase::GetAs##aClass() { return nullptr; } \
const aClass* EditTransactionBase::GetAs##aClass() const { return nullptr; }
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(ChangeAttributeTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(ChangeStyleTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(CompositionTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(DeleteNodeTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(DeleteRangeTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(DeleteTextTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(EditAggregateTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(InsertNodeTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(InsertTextTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(JoinNodesTransaction)
Bug 1766355 - part 1: Add `MoveNodeTransaction` to handle delete node and insert node in a transaction class instance r=m_kato Creating both `DeleteNodeTransaction` and `InsertNodeTransaction` wastes memory. They should be done in an instance instead. Fortunately, no edit action listener checks whether the deleted node is still in the composed document or not, etc. Therefore, we can simply notify them of both deletion and insertion which were done in `EditorBase::InsertNodeWithTransaction` and `EditorBase::DeleteNodeWithTransaction`. Note that previously, the range updater needs to ignore the notifications from them while the node is being moved. However, it does not require anymore. Therefore, this patch makes it stop locking, and that would fix minor problem in the case of legacy mutation event listeners run another edit action. On the other hand, this changes some edge cases handling of `MoveNodeWithTransaction` which are detected by the WPT. According to the previous result of applying this patch, `nsINode::InsertBefore` fails and that leads some errors at updating the changed range. I guess that the cause is that there is some bugs at updating insertion point after deleting the node from the DOM tree around here: https://searchfox.org/mozilla-central/rev/0ffae75b690219858e5a45a39f8759a8aee7b9a2/editor/libeditor/HTMLEditor.cpp#5058-5071 However, it's safely fixed by the new code which does not remove the node from the DOM tree explicitly. So, I think that it's safe to accept this behavior change for web apps in the wild. Differential Revision: https://phabricator.services.mozilla.com/D146397
2022-05-20 11:28:08 +03:00
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(MoveNodeTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(PlaceholderTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(ReplaceTextTransaction)
NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS(SplitNodeTransaction)
#undef NS_IMPL_EDITTRANSACTIONBASE_GETASMETHODS
} // namespace mozilla