2001-09-25 22:53:13 +00:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
2012-05-21 11:12:37 +00: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/. */
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
#include "mozilla/TextEditor.h"
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2019-09-23 11:43:59 +00:00
|
|
|
#include <algorithm>
|
|
|
|
|
2018-04-11 08:37:49 +00:00
|
|
|
#include "EditAggregateTransaction.h"
|
2016-07-07 09:00:19 +00:00
|
|
|
#include "InternetCiter.h"
|
2015-10-26 10:47:16 +00:00
|
|
|
#include "gfxFontUtils.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "mozilla/Assertions.h"
|
2019-01-11 01:50:19 +00:00
|
|
|
#include "mozilla/ContentIterator.h"
|
2018-01-12 10:01:04 +00:00
|
|
|
#include "mozilla/EditAction.h"
|
2017-11-07 10:50:25 +00:00
|
|
|
#include "mozilla/EditorDOMPoint.h"
|
2017-03-09 09:38:41 +00:00
|
|
|
#include "mozilla/HTMLEditor.h"
|
2018-04-18 15:31:51 +00:00
|
|
|
#include "mozilla/IMEStateManager.h"
|
2019-07-22 03:55:13 +00:00
|
|
|
#include "mozilla/LookAndFeel.h"
|
2016-07-09 02:34:41 +00:00
|
|
|
#include "mozilla/mozalloc.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "mozilla/Preferences.h"
|
2019-03-15 05:01:10 +00:00
|
|
|
#include "mozilla/PresShell.h"
|
2019-07-26 01:10:23 +00:00
|
|
|
#include "mozilla/StaticPrefs_editor.h"
|
2014-04-03 04:18:37 +00:00
|
|
|
#include "mozilla/TextComposition.h"
|
2013-09-25 11:21:19 +00:00
|
|
|
#include "mozilla/TextEvents.h"
|
2018-04-11 08:37:49 +00:00
|
|
|
#include "mozilla/TextServicesDocument.h"
|
2019-07-22 03:53:36 +00:00
|
|
|
#include "mozilla/dom/DocumentInlines.h"
|
2016-07-09 02:34:41 +00:00
|
|
|
#include "mozilla/dom/Event.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "mozilla/dom/Element.h"
|
2019-07-22 03:53:36 +00:00
|
|
|
#include "mozilla/dom/Selection.h"
|
2020-03-03 03:39:26 +00:00
|
|
|
#include "mozilla/dom/StaticRange.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsAString.h"
|
|
|
|
#include "nsCRT.h"
|
2008-07-16 10:52:01 +00:00
|
|
|
#include "nsCaret.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsCharTraits.h"
|
|
|
|
#include "nsComponentManagerUtils.h"
|
|
|
|
#include "nsContentCID.h"
|
2017-12-20 05:46:01 +00:00
|
|
|
#include "nsContentList.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsCopySupport.h"
|
|
|
|
#include "nsDebug.h"
|
|
|
|
#include "nsDependentSubstring.h"
|
|
|
|
#include "nsError.h"
|
|
|
|
#include "nsGkAtoms.h"
|
2018-04-18 15:31:51 +00:00
|
|
|
#include "nsIAbsorbingTransaction.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsIClipboard.h"
|
2001-01-28 20:13:07 +00:00
|
|
|
#include "nsIContent.h"
|
|
|
|
#include "nsIDocumentEncoder.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsINode.h"
|
2019-06-10 10:27:07 +00:00
|
|
|
#include "nsIPrincipal.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsISelectionController.h"
|
2001-01-28 20:13:07 +00:00
|
|
|
#include "nsISupportsPrimitives.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsITransferable.h"
|
|
|
|
#include "nsIWeakReferenceUtils.h"
|
2016-07-07 10:33:32 +00:00
|
|
|
#include "nsNameSpaceManager.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsLiteralString.h"
|
2003-07-28 13:13:50 +00:00
|
|
|
#include "nsReadableUtils.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsServiceManagerUtils.h"
|
|
|
|
#include "nsString.h"
|
|
|
|
#include "nsStringFwd.h"
|
2019-07-22 03:56:33 +00:00
|
|
|
#include "nsTextFragment.h"
|
2017-08-24 10:53:34 +00:00
|
|
|
#include "nsTextNode.h"
|
2002-03-19 06:46:56 +00:00
|
|
|
#include "nsUnicharUtils.h"
|
2012-07-13 06:33:42 +00:00
|
|
|
#include "nsXPCOM.h"
|
2001-04-05 23:48:01 +00:00
|
|
|
|
2012-07-13 06:33:42 +00:00
|
|
|
class nsIOutputStream;
|
|
|
|
class nsISupports;
|
2010-05-19 23:22:19 +00:00
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
namespace mozilla {
|
2011-05-25 06:32:00 +00:00
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
using namespace dom;
|
|
|
|
|
|
|
|
TextEditor::TextEditor()
|
2020-01-24 08:33:42 +00:00
|
|
|
: mMaxTextLength(-1),
|
2006-10-10 16:50:50 +00:00
|
|
|
#ifdef XP_WIN
|
2019-07-22 03:53:36 +00:00
|
|
|
mCaretStyle(1),
|
2006-10-10 16:50:50 +00:00
|
|
|
#else
|
2019-07-22 03:53:36 +00:00
|
|
|
mCaretStyle(0),
|
2006-10-10 16:50:50 +00:00
|
|
|
#endif
|
2019-07-22 03:53:36 +00:00
|
|
|
mUnmaskedStart(UINT32_MAX),
|
|
|
|
mUnmaskedLength(0),
|
|
|
|
mIsMaskingPassword(true) {
|
2018-11-26 06:33:28 +00:00
|
|
|
// printf("Size of TextEditor: %zu\n", sizeof(TextEditor));
|
|
|
|
static_assert(
|
|
|
|
sizeof(TextEditor) <= 512,
|
|
|
|
"TextEditor instance should be allocatable in the quantum class bins");
|
|
|
|
|
2014-05-22 22:06:44 +00:00
|
|
|
// check the "single line editor newline handling"
|
|
|
|
// and "caret behaviour in selection" prefs
|
|
|
|
GetDefaultEditorPrefs(mNewlineHandling, mCaretStyle);
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
TextEditor::~TextEditor() {
|
2002-11-12 23:30:29 +00:00
|
|
|
// Remove event listeners. Note that if we had an HTML editor,
|
|
|
|
// it installed its own instead of these
|
2005-12-11 09:26:29 +00:00
|
|
|
RemoveEventListeners();
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_CLASS(TextEditor)
|
2013-08-02 01:29:05 +00:00
|
|
|
|
2016-07-08 04:10:13 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_UNLINK_BEGIN_INHERITED(TextEditor, EditorBase)
|
2019-07-22 03:53:36 +00:00
|
|
|
if (tmp->mMaskTimer) {
|
|
|
|
tmp->mMaskTimer->Cancel();
|
|
|
|
}
|
2017-04-17 08:29:46 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_UNLINK(mCachedDocumentEncoder)
|
2019-07-22 03:53:36 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_UNLINK(mMaskTimer)
|
2009-05-09 04:59:25 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_UNLINK_END
|
|
|
|
|
2016-07-08 04:10:13 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_TRAVERSE_BEGIN_INHERITED(TextEditor, EditorBase)
|
2017-04-17 08:29:46 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_TRAVERSE(mCachedDocumentEncoder)
|
2019-07-22 03:53:36 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_TRAVERSE(mMaskTimer)
|
2009-05-09 04:59:25 +00:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_TRAVERSE_END
|
|
|
|
|
2016-07-08 04:10:13 +00:00
|
|
|
NS_IMPL_ADDREF_INHERITED(TextEditor, EditorBase)
|
|
|
|
NS_IMPL_RELEASE_INHERITED(TextEditor, EditorBase)
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2017-08-29 23:02:48 +00:00
|
|
|
NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION(TextEditor)
|
2019-07-22 03:53:36 +00:00
|
|
|
NS_INTERFACE_MAP_ENTRY(nsITimerCallback)
|
|
|
|
NS_INTERFACE_MAP_ENTRY(nsINamed)
|
2016-07-08 04:10:13 +00:00
|
|
|
NS_INTERFACE_MAP_END_INHERITING(EditorBase)
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2019-01-02 13:05:23 +00:00
|
|
|
nsresult TextEditor::Init(Document& aDoc, Element* aRoot,
|
2016-07-09 02:54:50 +00:00
|
|
|
nsISelectionController* aSelCon, uint32_t aFlags,
|
|
|
|
const nsAString& aInitialValue) {
|
2019-09-18 10:14:40 +00:00
|
|
|
MOZ_ASSERT(!AsHTMLEditor());
|
|
|
|
MOZ_ASSERT(!mInitSucceeded,
|
|
|
|
"TextEditor::Init() called again without calling PreDestroy()?");
|
2015-05-28 15:58:42 +00:00
|
|
|
|
2019-09-18 10:14:40 +00:00
|
|
|
// Init the base editor
|
|
|
|
nsresult rv = EditorBase::Init(aDoc, aRoot, aSelCon, aFlags, aInitialValue);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("EditorBase::Init() failed");
|
2019-09-18 10:14:40 +00:00
|
|
|
return rv;
|
|
|
|
}
|
2015-05-28 15:58:42 +00:00
|
|
|
|
2019-09-18 10:14:40 +00:00
|
|
|
// XXX `eNotEditing` is a lie since InitEditorContentAndSelection() may
|
|
|
|
// insert padding `<br>`.
|
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eNotEditing);
|
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
2020-04-13 08:55:41 +00:00
|
|
|
// We set mInitSucceeded here rather than at the end of the function,
|
|
|
|
// since InitEditorContentAndSelection() can perform some transactions
|
|
|
|
// and can warn if mInitSucceeded is still false.
|
|
|
|
MOZ_ASSERT(!mInitSucceeded, "TextEditor::Init() shouldn't be nested");
|
|
|
|
mInitSucceeded = true;
|
|
|
|
|
2019-09-18 10:14:40 +00:00
|
|
|
rv = InitEditorContentAndSelection();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("TextEditor::InitEditorContentAndSelection() failed");
|
2019-09-18 10:14:40 +00:00
|
|
|
// XXX Sholdn't we expose `NS_ERROR_EDITOR_DESTROYED` even though this
|
|
|
|
// is a public method?
|
2020-04-13 08:55:41 +00:00
|
|
|
mInitSucceeded = false;
|
2019-09-18 10:14:40 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
2019-09-18 10:14:40 +00:00
|
|
|
|
|
|
|
// Throw away the old transaction manager if this is not the first time that
|
|
|
|
// we're initializing the editor.
|
|
|
|
ClearUndoRedo();
|
|
|
|
EnableUndoRedo();
|
|
|
|
return NS_OK;
|
2010-02-01 18:12:31 +00:00
|
|
|
}
|
|
|
|
|
2012-08-22 15:56:38 +00:00
|
|
|
static int32_t sNewlineHandlingPref = -1, sCaretStylePref = -1;
|
2010-04-13 17:44:17 +00:00
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
static void EditorPrefsChangedCallback(const char* aPrefName, void*) {
|
2016-10-24 02:27:45 +00:00
|
|
|
if (!nsCRT::strcmp(aPrefName, "editor.singleLine.pasteNewlines")) {
|
2020-01-24 08:33:42 +00:00
|
|
|
sNewlineHandlingPref = Preferences::GetInt(
|
|
|
|
"editor.singleLine.pasteNewlines", nsIEditor::eNewlinesPasteToFirst);
|
|
|
|
if (NS_WARN_IF(sNewlineHandlingPref < nsIEditor::eNewlinesPasteIntact ||
|
|
|
|
sNewlineHandlingPref >
|
|
|
|
nsIEditor::eNewlinesStripSurroundingWhitespace)) {
|
|
|
|
sNewlineHandlingPref = nsIEditor::eNewlinesPasteToFirst;
|
|
|
|
}
|
2016-10-24 02:27:45 +00:00
|
|
|
} else if (!nsCRT::strcmp(aPrefName, "layout.selection.caret_style")) {
|
2011-05-25 06:32:00 +00:00
|
|
|
sCaretStylePref = Preferences::GetInt("layout.selection.caret_style",
|
2010-02-01 18:12:31 +00:00
|
|
|
#ifdef XP_WIN
|
2010-04-13 17:44:17 +00:00
|
|
|
1);
|
2016-10-24 02:27:45 +00:00
|
|
|
if (!sCaretStylePref) {
|
2010-04-13 17:44:17 +00:00
|
|
|
sCaretStylePref = 1;
|
2016-10-24 02:27:45 +00:00
|
|
|
}
|
2010-02-01 18:12:31 +00:00
|
|
|
#else
|
2010-04-13 17:44:17 +00:00
|
|
|
0);
|
2010-02-01 18:12:31 +00:00
|
|
|
#endif
|
2010-04-13 17:44:17 +00:00
|
|
|
}
|
|
|
|
}
|
2010-02-01 18:12:31 +00:00
|
|
|
|
2010-04-13 17:44:17 +00:00
|
|
|
// static
|
2016-07-09 02:54:50 +00:00
|
|
|
void TextEditor::GetDefaultEditorPrefs(int32_t& aNewlineHandling,
|
|
|
|
int32_t& aCaretStyle) {
|
2010-04-13 17:44:17 +00:00
|
|
|
if (sNewlineHandlingPref == -1) {
|
2017-03-21 18:59:02 +00:00
|
|
|
Preferences::RegisterCallbackAndCall(EditorPrefsChangedCallback,
|
|
|
|
"editor.singleLine.pasteNewlines");
|
|
|
|
Preferences::RegisterCallbackAndCall(EditorPrefsChangedCallback,
|
|
|
|
"layout.selection.caret_style");
|
2006-10-10 16:50:50 +00:00
|
|
|
}
|
2010-04-13 17:44:17 +00:00
|
|
|
|
|
|
|
aNewlineHandling = sNewlineHandlingPref;
|
|
|
|
aCaretStyle = sCaretStylePref;
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_IMETHODIMP TextEditor::SetDocumentCharacterSet(
|
|
|
|
const nsACString& characterSet) {
|
2018-10-30 09:59:33 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eSetCharacterSet);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsresult rv = editActionData.CanHandleAndMaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"CanHandleAndMaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-10-30 09:59:33 +00:00
|
|
|
}
|
|
|
|
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
rv = EditorBase::SetDocumentCharacterSet(characterSet);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("EditorBase::SetDocumentCharacterSet() failed");
|
2019-02-25 09:07:54 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
2012-02-01 10:54:22 +00:00
|
|
|
|
|
|
|
// Update META charset element.
|
2020-03-18 01:14:42 +00:00
|
|
|
RefPtr<Document> document = GetDocument();
|
|
|
|
if (NS_WARN_IF(!document)) {
|
2017-03-17 07:32:06 +00:00
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
2012-02-01 10:54:22 +00:00
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
if (UpdateMetaCharset(*document, characterSet)) {
|
2012-02-01 10:54:22 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
RefPtr<nsContentList> headElementList =
|
|
|
|
document->GetElementsByTagName(NS_LITERAL_STRING("head"));
|
|
|
|
if (NS_WARN_IF(!headElementList)) {
|
2017-03-17 07:32:06 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
nsCOMPtr<nsIContent> primaryHeadElement = headElementList->Item(0);
|
|
|
|
if (NS_WARN_IF(!primaryHeadElement)) {
|
2017-03-17 07:32:06 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
2012-02-01 10:54:22 +00:00
|
|
|
|
|
|
|
// Create a new meta charset tag
|
2020-03-18 01:14:42 +00:00
|
|
|
RefPtr<Element> metaElement = CreateNodeWithTransaction(
|
|
|
|
*nsGkAtoms::meta, EditorDOMPoint(primaryHeadElement, 0));
|
|
|
|
if (!metaElement) {
|
|
|
|
NS_WARNING(
|
|
|
|
"EditorBase::CreateNodeWithTransaction(nsGkAtoms::meta) failed, but "
|
|
|
|
"ignored");
|
2012-02-01 10:54:22 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2017-03-17 07:32:06 +00:00
|
|
|
// Set attributes to the created element
|
|
|
|
if (characterSet.IsEmpty()) {
|
2012-02-01 10:54:22 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2018-04-09 16:17:26 +00:00
|
|
|
// not undoable, undo should undo CreateNodeWithTransaction().
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored = NS_OK;
|
|
|
|
rvIgnored = metaElement->SetAttr(kNameSpaceID_None, nsGkAtoms::httpEquiv,
|
|
|
|
NS_LITERAL_STRING("Content-Type"), true);
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"Element::SetAttr(nsGkAtoms::httpEquiv, Content-Type) "
|
|
|
|
"failed, but ignored");
|
|
|
|
rvIgnored = metaElement->SetAttr(kNameSpaceID_None, nsGkAtoms::content,
|
|
|
|
NS_LITERAL_STRING("text/html;charset=") +
|
|
|
|
NS_ConvertASCIItoUTF16(characterSet),
|
|
|
|
true);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"Element::SetAttr(nsGkAtoms::content) failed, but ignored");
|
2012-02-01 10:54:22 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2019-01-02 13:05:23 +00:00
|
|
|
bool TextEditor::UpdateMetaCharset(Document& aDocument,
|
2016-07-09 02:54:50 +00:00
|
|
|
const nsACString& aCharacterSet) {
|
2012-02-01 10:54:22 +00:00
|
|
|
// get a list of META tags
|
2020-03-18 01:14:42 +00:00
|
|
|
RefPtr<nsContentList> metaElementList =
|
2017-03-17 07:32:06 +00:00
|
|
|
aDocument.GetElementsByTagName(NS_LITERAL_STRING("meta"));
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_WARN_IF(!metaElementList)) {
|
2017-03-17 07:32:06 +00:00
|
|
|
return false;
|
|
|
|
}
|
2012-02-01 10:54:22 +00:00
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
for (uint32_t i = 0; i < metaElementList->Length(true); ++i) {
|
|
|
|
RefPtr<Element> metaElement = metaElementList->Item(i)->AsElement();
|
|
|
|
MOZ_ASSERT(metaElement);
|
2012-02-01 10:54:22 +00:00
|
|
|
|
|
|
|
nsAutoString currentValue;
|
2020-03-18 01:14:42 +00:00
|
|
|
metaElement->GetAttr(kNameSpaceID_None, nsGkAtoms::httpEquiv, currentValue);
|
2012-02-01 10:54:22 +00:00
|
|
|
|
|
|
|
if (!FindInReadable(NS_LITERAL_STRING("content-type"), currentValue,
|
|
|
|
nsCaseInsensitiveStringComparator())) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
metaElement->GetAttr(kNameSpaceID_None, nsGkAtoms::content, currentValue);
|
2012-02-01 10:54:22 +00:00
|
|
|
|
|
|
|
NS_NAMED_LITERAL_STRING(charsetEquals, "charset=");
|
|
|
|
nsAString::const_iterator originalStart, start, end;
|
|
|
|
originalStart = currentValue.BeginReading(start);
|
|
|
|
currentValue.EndReading(end);
|
|
|
|
if (!FindInReadable(charsetEquals, start, end,
|
|
|
|
nsCaseInsensitiveStringComparator())) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// set attribute to <original prefix> charset=text/html
|
2018-04-12 07:58:33 +00:00
|
|
|
nsresult rv = SetAttributeWithTransaction(
|
|
|
|
*metaElement, *nsGkAtoms::content,
|
|
|
|
Substring(originalStart, start) + charsetEquals +
|
|
|
|
NS_ConvertASCIItoUTF16(aCharacterSet));
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"EditorBase::SetAttributeWithTransaction(nsGkAtoms::content) failed");
|
2012-02-01 10:54:22 +00:00
|
|
|
return NS_SUCCEEDED(rv);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2017-02-08 11:18:17 +00:00
|
|
|
nsresult TextEditor::HandleKeyPressEvent(WidgetKeyboardEvent* aKeyboardEvent) {
|
2010-06-10 01:16:58 +00:00
|
|
|
// NOTE: When you change this method, you should also change:
|
2014-08-19 00:59:37 +00:00
|
|
|
// * editor/libeditor/tests/test_texteditor_keyevent_handling.html
|
2014-08-18 21:28:17 +00:00
|
|
|
// * editor/libeditor/tests/test_htmleditor_keyevent_handling.html
|
2010-06-10 01:16:58 +00:00
|
|
|
//
|
|
|
|
// And also when you add new key handling, you need to change the subclass's
|
|
|
|
// HandleKeyPressEvent()'s switch statement.
|
|
|
|
|
2020-03-19 13:18:16 +00:00
|
|
|
if (IsReadonly()) {
|
2016-07-08 04:10:13 +00:00
|
|
|
// When we're not editable, the events handled on EditorBase.
|
2017-02-08 11:18:17 +00:00
|
|
|
return EditorBase::HandleKeyPressEvent(aKeyboardEvent);
|
2010-06-10 01:16:58 +00:00
|
|
|
}
|
2010-06-02 07:24:56 +00:00
|
|
|
|
2017-02-08 11:18:17 +00:00
|
|
|
if (NS_WARN_IF(!aKeyboardEvent)) {
|
|
|
|
return NS_ERROR_UNEXPECTED;
|
|
|
|
}
|
|
|
|
MOZ_ASSERT(aKeyboardEvent->mMessage == eKeyPress,
|
|
|
|
"HandleKeyPressEvent gets non-keypress event");
|
2010-06-10 01:16:58 +00:00
|
|
|
|
2017-02-08 11:18:17 +00:00
|
|
|
switch (aKeyboardEvent->mKeyCode) {
|
2016-05-12 08:13:49 +00:00
|
|
|
case NS_VK_META:
|
|
|
|
case NS_VK_WIN:
|
|
|
|
case NS_VK_SHIFT:
|
|
|
|
case NS_VK_CONTROL:
|
|
|
|
case NS_VK_ALT:
|
2016-07-08 04:10:13 +00:00
|
|
|
// These keys are handled on EditorBase
|
2017-02-08 11:18:17 +00:00
|
|
|
return EditorBase::HandleKeyPressEvent(aKeyboardEvent);
|
2019-06-10 10:27:07 +00:00
|
|
|
case NS_VK_BACK: {
|
2018-04-11 08:37:49 +00:00
|
|
|
if (aKeyboardEvent->IsControl() || aKeyboardEvent->IsAlt() ||
|
|
|
|
aKeyboardEvent->IsMeta() || aKeyboardEvent->IsOS()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
DeleteSelectionAsAction(nsIEditor::ePrevious, nsIEditor::eStrip);
|
|
|
|
aKeyboardEvent->PreventDefault(); // consumed
|
|
|
|
return NS_OK;
|
2019-06-10 10:27:07 +00:00
|
|
|
}
|
|
|
|
case NS_VK_DELETE: {
|
2018-04-11 08:37:49 +00:00
|
|
|
// on certain platforms (such as windows) the shift key
|
|
|
|
// modifies what delete does (cmd_cut in this case).
|
|
|
|
// bailing here to allow the keybindings to do the cut.
|
|
|
|
if (aKeyboardEvent->IsShift() || aKeyboardEvent->IsControl() ||
|
|
|
|
aKeyboardEvent->IsAlt() || aKeyboardEvent->IsMeta() ||
|
|
|
|
aKeyboardEvent->IsOS()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
DeleteSelectionAsAction(nsIEditor::eNext, nsIEditor::eStrip);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"TextEditor::DeleteSelectionAsAction() failed, but ignored");
|
2018-04-11 08:37:49 +00:00
|
|
|
aKeyboardEvent->PreventDefault(); // consumed
|
|
|
|
return NS_OK;
|
2019-06-10 10:27:07 +00:00
|
|
|
}
|
2016-05-12 08:13:49 +00:00
|
|
|
case NS_VK_TAB: {
|
2010-06-10 01:16:58 +00:00
|
|
|
if (IsTabbable()) {
|
|
|
|
return NS_OK; // let it be used for focus switching
|
|
|
|
}
|
2010-06-04 01:28:03 +00:00
|
|
|
|
2017-02-08 11:18:17 +00:00
|
|
|
if (aKeyboardEvent->IsShift() || aKeyboardEvent->IsControl() ||
|
|
|
|
aKeyboardEvent->IsAlt() || aKeyboardEvent->IsMeta() ||
|
|
|
|
aKeyboardEvent->IsOS()) {
|
2010-06-10 01:16:58 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
// else we insert the tab straight through
|
2017-02-08 11:18:17 +00:00
|
|
|
aKeyboardEvent->PreventDefault();
|
2020-03-18 01:14:42 +00:00
|
|
|
nsresult rv = OnInputText(NS_LITERAL_STRING("\t"));
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::OnInputText(\\t) failed");
|
|
|
|
return rv;
|
2010-06-04 01:28:03 +00:00
|
|
|
}
|
2020-03-18 01:14:42 +00:00
|
|
|
case NS_VK_RETURN: {
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
if (!aKeyboardEvent->IsInputtingLineBreak()) {
|
2010-06-10 01:16:58 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
if (!IsSingleLineEditor()) {
|
|
|
|
aKeyboardEvent->PreventDefault();
|
|
|
|
}
|
|
|
|
// We need to dispatch "beforeinput" event at least even if we're a
|
|
|
|
// single line text editor.
|
2020-03-18 01:14:42 +00:00
|
|
|
nsresult rv = InsertLineBreakAsAction();
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::InsertLineBreakAsAction() failed");
|
|
|
|
return rv;
|
|
|
|
}
|
2010-06-10 01:16:58 +00:00
|
|
|
}
|
|
|
|
|
2018-01-25 14:27:07 +00:00
|
|
|
if (!aKeyboardEvent->IsInputtingText()) {
|
2010-06-10 01:16:58 +00:00
|
|
|
// we don't PreventDefault() here or keybindings like control-x won't work
|
|
|
|
return NS_OK;
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
2019-11-28 05:51:41 +00:00
|
|
|
// Our widget shouldn't set `\r` to `mCharCode`, but it may be synthesized
|
|
|
|
// keyboard event and its value may be `\r`. In such case, we should treat
|
|
|
|
// it as `\n` for the backward compatibility because we stopped converting
|
|
|
|
// `\r` and `\r\n` to `\n` at getting `HTMLInputElement.value` and
|
|
|
|
// `HTMLTextAreaElement.value` for the performance (i.e., we don't need to
|
|
|
|
// take care in `HTMLEditor`).
|
|
|
|
char16_t charCode =
|
|
|
|
static_cast<char16_t>(aKeyboardEvent->mCharCode) == nsCRT::CR
|
|
|
|
? nsCRT::LF
|
|
|
|
: static_cast<char16_t>(aKeyboardEvent->mCharCode);
|
2017-02-08 11:18:17 +00:00
|
|
|
aKeyboardEvent->PreventDefault();
|
2019-11-28 05:51:41 +00:00
|
|
|
nsAutoString str(charCode);
|
2020-03-18 01:14:42 +00:00
|
|
|
nsresult rv = OnInputText(str);
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "TextEditor::OnInputText() failed");
|
|
|
|
return rv;
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2018-04-16 14:43:36 +00:00
|
|
|
nsresult TextEditor::OnInputText(const nsAString& aStringToInsert) {
|
2018-10-30 09:59:33 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eInsertText);
|
2019-02-19 06:28:19 +00:00
|
|
|
MOZ_ASSERT(!aStringToInsert.IsVoid());
|
|
|
|
editActionData.SetData(aStringToInsert);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
// FYI: For conforming to current UI Events spec, we should dispatch
|
|
|
|
// "beforeinput" event before "keypress" event, but here is in a
|
|
|
|
// "keypress" event listener. However, the other browsers dispatch
|
|
|
|
// "beforeinput" event after "keypress" event. Therefore, it makes
|
|
|
|
// sense to follow the other browsers. Spec issue:
|
|
|
|
// https://github.com/w3c/uievents/issues/220
|
|
|
|
nsresult rv = editActionData.CanHandleAndMaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"CanHandleAndMaybeDispatchBeforeInputEvent() failed");
|
2020-01-14 02:41:15 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
|
|
|
|
AutoPlaceholderBatch treatAsOneTransaction(*this, *nsGkAtoms::TypingTxnName);
|
|
|
|
rv = InsertTextAsSubAction(aStringToInsert);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"EditorBase::InsertTextAsSubAction() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-04-16 14:43:36 +00:00
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
nsresult TextEditor::InsertLineBreakAsAction(nsIPrincipal* aPrincipal) {
|
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eInsertLineBreak,
|
|
|
|
aPrincipal);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsresult rv = editActionData.CanHandleAndMaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"CanHandleAndMaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IsSingleLineEditor()) {
|
|
|
|
return NS_OK;
|
2018-11-03 11:22:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// XXX This may be called by execCommand() with "insertParagraph".
|
|
|
|
// In such case, naming the transaction "TypingTxnName" is odd.
|
|
|
|
AutoPlaceholderBatch treatAsOneTransaction(*this, *nsGkAtoms::TypingTxnName);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
rv = InsertLineBreakAsSubAction();
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"EditorBase::InsertLineBreakAsSubAction() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-11-03 11:22:13 +00:00
|
|
|
}
|
|
|
|
|
2019-11-20 05:09:18 +00:00
|
|
|
static bool UseFrameSelectionToExtendSelection(nsIEditor::EDirection aAction,
|
|
|
|
const Selection& aSelection) {
|
|
|
|
bool bCollapsed = aSelection.IsCollapsed();
|
|
|
|
return (aAction == nsIEditor::eNextWord ||
|
|
|
|
aAction == nsIEditor::ePreviousWord ||
|
|
|
|
(aAction == nsIEditor::eNext && bCollapsed) ||
|
|
|
|
(aAction == nsIEditor::ePrevious && bCollapsed) ||
|
|
|
|
aAction == nsIEditor::eToBeginningOfLine ||
|
|
|
|
aAction == nsIEditor::eToEndOfLine);
|
|
|
|
}
|
|
|
|
|
2018-10-30 10:01:38 +00:00
|
|
|
nsresult TextEditor::ExtendSelectionForDelete(nsIEditor::EDirection* aAction) {
|
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
if (!UseFrameSelectionToExtendSelection(*aAction, *SelectionRefPtr())) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
2010-06-04 17:28:19 +00:00
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
nsCOMPtr<nsISelectionController> selectionController =
|
|
|
|
GetSelectionController();
|
|
|
|
if (NS_WARN_IF(!selectionController)) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (*aAction) {
|
|
|
|
case eNextWord: {
|
|
|
|
nsresult rv = selectionController->WordExtendForDelete(true);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"nsISelectionController::WordExtendForDelete(true) failed");
|
|
|
|
// DeleteSelectionWithTransaction() doesn't handle these actions
|
|
|
|
// because it's inside batching, so don't confuse it:
|
|
|
|
*aAction = eNone;
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
case ePreviousWord: {
|
|
|
|
nsresult rv = selectionController->WordExtendForDelete(false);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"nsISelectionController::WordExtendForDelete(false) failed");
|
|
|
|
*aAction = eNone;
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
case eNext: {
|
|
|
|
nsresult rv = selectionController->CharacterExtendForDelete();
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"nsISelectionController::CharacterExtendForDelete() failed");
|
|
|
|
// Don't set aAction to eNone (see Bug 502259)
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
case ePrevious: {
|
|
|
|
// Only extend the selection where the selection is after a UTF-16
|
|
|
|
// surrogate pair or a variation selector.
|
|
|
|
// For other cases we don't want to do that, in order
|
|
|
|
// to make sure that pressing backspace will only delete the last
|
|
|
|
// typed character.
|
|
|
|
EditorRawDOMPoint atStartOfSelection =
|
|
|
|
EditorBase::GetStartPoint(*SelectionRefPtr());
|
|
|
|
if (NS_WARN_IF(!atStartOfSelection.IsSet())) {
|
|
|
|
return NS_ERROR_FAILURE;
|
2010-06-04 17:28:19 +00:00
|
|
|
}
|
2020-03-18 01:14:42 +00:00
|
|
|
|
|
|
|
// node might be anonymous DIV, so we find better text node
|
|
|
|
EditorRawDOMPoint insertionPoint =
|
|
|
|
FindBetterInsertionPoint(atStartOfSelection);
|
|
|
|
if (!insertionPoint.IsSet()) {
|
|
|
|
NS_WARNING(
|
|
|
|
"EditorBase::FindBetterInsertionPoint() failed, but ignored");
|
2017-11-08 12:55:10 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
2020-03-18 01:14:42 +00:00
|
|
|
|
|
|
|
if (insertionPoint.IsInTextNode()) {
|
|
|
|
const nsTextFragment* data =
|
|
|
|
&insertionPoint.GetContainerAsText()->TextFragment();
|
|
|
|
uint32_t offset = insertionPoint.Offset();
|
|
|
|
if ((offset > 1 &&
|
|
|
|
data->IsLowSurrogateFollowingHighSurrogateAt(offset - 1)) ||
|
|
|
|
(offset > 0 &&
|
|
|
|
gfxFontUtils::IsVarSelector(data->CharAt(offset - 1)))) {
|
|
|
|
nsresult rv = selectionController->CharacterExtendForBackspace();
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"nsISelectionController::CharacterExtendForBackspace() failed");
|
2017-11-08 12:55:10 +00:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
}
|
2020-03-18 01:14:42 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
case eToBeginningOfLine: {
|
|
|
|
// Select to beginning
|
|
|
|
nsresult rv = selectionController->IntraLineMove(false, true);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"nsISelectionController::IntraLineMove(false, true) failed");
|
|
|
|
*aAction = eNone;
|
|
|
|
return rv;
|
2008-10-16 07:44:32 +00:00
|
|
|
}
|
2020-03-18 01:14:42 +00:00
|
|
|
case eToEndOfLine: {
|
|
|
|
nsresult rv = selectionController->IntraLineMove(true, true);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"nsISelectionController::IntraLineMove(true, true) failed");
|
|
|
|
*aAction = eNext;
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
// For avoiding several compiler warnings
|
|
|
|
default:
|
|
|
|
return NS_OK;
|
2008-10-16 07:44:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_IMETHODIMP TextEditor::DeleteSelection(EDirection aAction,
|
|
|
|
EStripWrappers aStripWrappers) {
|
2018-04-11 08:37:49 +00:00
|
|
|
nsresult rv = DeleteSelectionAsAction(aAction, aStripWrappers);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::DeleteSelectionAsAction() failed");
|
2019-06-10 10:27:07 +00:00
|
|
|
return rv;
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
nsresult TextEditor::DeleteSelectionAsAction(EDirection aDirection,
|
2019-06-10 10:27:07 +00:00
|
|
|
EStripWrappers aStripWrappers,
|
|
|
|
nsIPrincipal* aPrincipal) {
|
2012-05-10 14:54:33 +00:00
|
|
|
MOZ_ASSERT(aStripWrappers == eStrip || aStripWrappers == eNoStrip);
|
Bug 1467794 - Split TextEditor::DeleteSelectionAsAction() to itself and TextEditor::DeleteSelectionAsSubAction() r=m_kato
TextEditor::DeleteSelectionAsAction() is called even if it's a part of edit
action. For example, it's called to prepare for inserting text.
For bug 1465702, editor itself and edit rules classes should not call
public DeleteSelectionAsAction() directly. Therefore, this patch creates
DeleteSelectionAsSubAction() for internal use.
Note that this patch adds NS_ASSERTION() to detect wrong caller. However,
it cannot distinguish if the call is valid, for example, it's allowed to
call DeleteSelectionAsSelection() even if it's handling an edit action but
the method is called via mutation event listener. So, we need to allow
some assertions with some tests. But unfortunately, 1405747.html uses
mutation event listener too many times (about 1,000 times) and the number
of assertion isn't stable. Therefore, this patch makes the test stop using
the mutation event listener 2nd time since I can reproduce the crash with
ESR 52 at the 2nd time.
MozReview-Commit-ID: 1TWaypmnoCC
--HG--
extra : rebase_source : a6a4fb1cbcaf2ab6f10c5f3e7168a6bc0fcb02ed
2018-06-29 11:16:50 +00:00
|
|
|
// Showing this assertion is fine if this method is called by outside via
|
|
|
|
// mutation event listener or something. Otherwise, this is called by
|
|
|
|
// wrong method.
|
|
|
|
NS_ASSERTION(!mPlaceholderBatch,
|
|
|
|
"Should be called only when this is the only edit action of the "
|
|
|
|
"operation "
|
|
|
|
"unless mutation event listener nests some operations");
|
|
|
|
|
2018-10-30 09:59:33 +00:00
|
|
|
EditAction editAction = EditAction::eDeleteSelection;
|
|
|
|
switch (aDirection) {
|
|
|
|
case nsIEditor::ePrevious:
|
|
|
|
editAction = EditAction::eDeleteBackward;
|
|
|
|
break;
|
|
|
|
case nsIEditor::eNext:
|
|
|
|
editAction = EditAction::eDeleteForward;
|
|
|
|
break;
|
|
|
|
case nsIEditor::ePreviousWord:
|
|
|
|
editAction = EditAction::eDeleteWordBackward;
|
|
|
|
break;
|
|
|
|
case nsIEditor::eNextWord:
|
|
|
|
editAction = EditAction::eDeleteWordForward;
|
|
|
|
break;
|
|
|
|
case nsIEditor::eToBeginningOfLine:
|
|
|
|
editAction = EditAction::eDeleteToBeginningOfSoftLine;
|
|
|
|
break;
|
|
|
|
case nsIEditor::eToEndOfLine:
|
|
|
|
editAction = EditAction::eDeleteToEndOfSoftLine;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, editAction, aPrincipal);
|
2018-10-30 09:59:33 +00:00
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
Bug 1503231 - Make TextEditor::DeleteSelectionAsAction() removes removing range information from EditAction when Selection is NOT collapsed r=m_kato
When Selection is NOT collapsed, we remove selected content. Therefore,
web apps don't need to know range information of user operation. However, web
apps may want to know direction of the operation (backward or forward). E.g.,
web apps may just mark selected range as "deleted" and move caret before or
after the range.
Therefore, when computed EditAction is eDeleteWordBackward or
eDeleteToBeginningOfSoftLine, we should use eDeleteBackward instead. When it
is eDeleteWordForward or eDeleteToEndOfSoftLine, we should use eDeleteForward
instead.
Note that only on Windows, we follow behavior of richtext control (and Word).
That is, Ctrl + Backspace/Delete collapse from start of selected range to
start/end of current word. I.e., collapsing Selection to start first and
removing to start or end of current word is Windows's standard behavior.
Currently, we do this in DeleteSelectionAsSubAction() but every caller
specifies eNone to aDirection except DeleteSelectionAsAction(). So, we can
move this before re-computing EditAction in DeleteSelectionAsAction().
Differential Revision: https://phabricator.services.mozilla.com/D10992
--HG--
extra : moz-landing-system : lando
2018-11-07 08:38:15 +00:00
|
|
|
// If there is an existing selection when an extended delete is requested,
|
|
|
|
// platforms that use "caret-style" caret positioning collapse the
|
|
|
|
// selection to the start and then create a new selection.
|
|
|
|
// Platforms that use "selection-style" caret positioning just delete the
|
|
|
|
// existing selection without extending it.
|
|
|
|
if (!SelectionRefPtr()->IsCollapsed()) {
|
|
|
|
switch (aDirection) {
|
|
|
|
case eNextWord:
|
|
|
|
case ePreviousWord:
|
|
|
|
case eToBeginningOfLine:
|
|
|
|
case eToEndOfLine: {
|
|
|
|
if (mCaretStyle != 1) {
|
|
|
|
aDirection = eNone;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
ErrorResult error;
|
|
|
|
SelectionRefPtr()->CollapseToStart(error);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (error.Failed()) {
|
|
|
|
NS_WARNING("Selection::CollapseToStart() failed");
|
2019-02-25 09:07:54 +00:00
|
|
|
return EditorBase::ToGenericNSResult(error.StealNSResult());
|
Bug 1503231 - Make TextEditor::DeleteSelectionAsAction() removes removing range information from EditAction when Selection is NOT collapsed r=m_kato
When Selection is NOT collapsed, we remove selected content. Therefore,
web apps don't need to know range information of user operation. However, web
apps may want to know direction of the operation (backward or forward). E.g.,
web apps may just mark selected range as "deleted" and move caret before or
after the range.
Therefore, when computed EditAction is eDeleteWordBackward or
eDeleteToBeginningOfSoftLine, we should use eDeleteBackward instead. When it
is eDeleteWordForward or eDeleteToEndOfSoftLine, we should use eDeleteForward
instead.
Note that only on Windows, we follow behavior of richtext control (and Word).
That is, Ctrl + Backspace/Delete collapse from start of selected range to
start/end of current word. I.e., collapsing Selection to start first and
removing to start or end of current word is Windows's standard behavior.
Currently, we do this in DeleteSelectionAsSubAction() but every caller
specifies eNone to aDirection except DeleteSelectionAsAction(). So, we can
move this before re-computing EditAction in DeleteSelectionAsAction().
Differential Revision: https://phabricator.services.mozilla.com/D10992
--HG--
extra : moz-landing-system : lando
2018-11-07 08:38:15 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If Selection is still NOT collapsed, it does not important removing
|
|
|
|
// range of the operation since we'll remove the selected content. However,
|
|
|
|
// information of direction (backward or forward) may be important for
|
|
|
|
// web apps. E.g., web apps may want to mark selected range as "deleted"
|
|
|
|
// and move caret before or after the range. Therefore, we should forget
|
|
|
|
// only the range information but keep range information. See discussion
|
|
|
|
// of the spec issue for the detail:
|
|
|
|
// https://github.com/w3c/input-events/issues/82
|
|
|
|
if (!SelectionRefPtr()->IsCollapsed()) {
|
|
|
|
switch (editAction) {
|
|
|
|
case EditAction::eDeleteWordBackward:
|
|
|
|
case EditAction::eDeleteToBeginningOfSoftLine:
|
|
|
|
editActionData.UpdateEditAction(EditAction::eDeleteBackward);
|
|
|
|
break;
|
|
|
|
case EditAction::eDeleteWordForward:
|
|
|
|
case EditAction::eDeleteToEndOfSoftLine:
|
|
|
|
editActionData.UpdateEditAction(EditAction::eDeleteForward);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-20 05:09:18 +00:00
|
|
|
if (UseFrameSelectionToExtendSelection(aDirection, *SelectionRefPtr())) {
|
|
|
|
// Although ExtendSelectionForDelete will use nsFrameSelection, if it
|
|
|
|
// still has dirty frame, nsFrameSelection doesn't extend selection
|
|
|
|
// since we block script.
|
2020-03-18 01:14:42 +00:00
|
|
|
if (RefPtr<PresShell> presShell = GetPresShell()) {
|
2019-11-20 05:09:18 +00:00
|
|
|
presShell->FlushPendingNotifications(FlushType::Layout);
|
|
|
|
if (NS_WARN_IF(Destroyed())) {
|
|
|
|
return NS_ERROR_EDITOR_DESTROYED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-03 03:39:26 +00:00
|
|
|
// TODO: If we're an HTMLEditor instance, we need to compute delete ranges
|
|
|
|
// here. However, it means that we need to pick computation codes
|
|
|
|
// which are in `HandleDeleteSelection()`, its helper methods and
|
|
|
|
// `WSRunObject` so that we need to redesign `HandleDeleteSelection()`
|
|
|
|
// in bug 1618457.
|
|
|
|
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsresult rv = editActionData.MaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"MaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
|
|
|
|
Bug 1467794 - Split TextEditor::DeleteSelectionAsAction() to itself and TextEditor::DeleteSelectionAsSubAction() r=m_kato
TextEditor::DeleteSelectionAsAction() is called even if it's a part of edit
action. For example, it's called to prepare for inserting text.
For bug 1465702, editor itself and edit rules classes should not call
public DeleteSelectionAsAction() directly. Therefore, this patch creates
DeleteSelectionAsSubAction() for internal use.
Note that this patch adds NS_ASSERTION() to detect wrong caller. However,
it cannot distinguish if the call is valid, for example, it's allowed to
call DeleteSelectionAsSelection() even if it's handling an edit action but
the method is called via mutation event listener. So, we need to allow
some assertions with some tests. But unfortunately, 1405747.html uses
mutation event listener too many times (about 1,000 times) and the number
of assertion isn't stable. Therefore, this patch makes the test stop using
the mutation event listener 2nd time since I can reproduce the crash with
ESR 52 at the 2nd time.
MozReview-Commit-ID: 1TWaypmnoCC
--HG--
extra : rebase_source : a6a4fb1cbcaf2ab6f10c5f3e7168a6bc0fcb02ed
2018-06-29 11:16:50 +00:00
|
|
|
// delete placeholder txns merge.
|
2018-10-24 09:42:06 +00:00
|
|
|
AutoPlaceholderBatch treatAsOneTransaction(*this, *nsGkAtoms::DeleteTxnName);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
rv = DeleteSelectionAsSubAction(aDirection, aStripWrappers);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::DeleteSelectionAsSubAction() failed");
|
2019-09-13 02:49:43 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
Bug 1467794 - Split TextEditor::DeleteSelectionAsAction() to itself and TextEditor::DeleteSelectionAsSubAction() r=m_kato
TextEditor::DeleteSelectionAsAction() is called even if it's a part of edit
action. For example, it's called to prepare for inserting text.
For bug 1465702, editor itself and edit rules classes should not call
public DeleteSelectionAsAction() directly. Therefore, this patch creates
DeleteSelectionAsSubAction() for internal use.
Note that this patch adds NS_ASSERTION() to detect wrong caller. However,
it cannot distinguish if the call is valid, for example, it's allowed to
call DeleteSelectionAsSelection() even if it's handling an edit action but
the method is called via mutation event listener. So, we need to allow
some assertions with some tests. But unfortunately, 1405747.html uses
mutation event listener too many times (about 1,000 times) and the number
of assertion isn't stable. Therefore, this patch makes the test stop using
the mutation event listener 2nd time since I can reproduce the crash with
ESR 52 at the 2nd time.
MozReview-Commit-ID: 1TWaypmnoCC
--HG--
extra : rebase_source : a6a4fb1cbcaf2ab6f10c5f3e7168a6bc0fcb02ed
2018-06-29 11:16:50 +00:00
|
|
|
}
|
|
|
|
|
2019-09-13 02:49:43 +00:00
|
|
|
nsresult TextEditor::DeleteSelectionAsSubAction(EDirection aDirectionAndAmount,
|
Bug 1467794 - Split TextEditor::DeleteSelectionAsAction() to itself and TextEditor::DeleteSelectionAsSubAction() r=m_kato
TextEditor::DeleteSelectionAsAction() is called even if it's a part of edit
action. For example, it's called to prepare for inserting text.
For bug 1465702, editor itself and edit rules classes should not call
public DeleteSelectionAsAction() directly. Therefore, this patch creates
DeleteSelectionAsSubAction() for internal use.
Note that this patch adds NS_ASSERTION() to detect wrong caller. However,
it cannot distinguish if the call is valid, for example, it's allowed to
call DeleteSelectionAsSelection() even if it's handling an edit action but
the method is called via mutation event listener. So, we need to allow
some assertions with some tests. But unfortunately, 1405747.html uses
mutation event listener too many times (about 1,000 times) and the number
of assertion isn't stable. Therefore, this patch makes the test stop using
the mutation event listener 2nd time since I can reproduce the crash with
ESR 52 at the 2nd time.
MozReview-Commit-ID: 1TWaypmnoCC
--HG--
extra : rebase_source : a6a4fb1cbcaf2ab6f10c5f3e7168a6bc0fcb02ed
2018-06-29 11:16:50 +00:00
|
|
|
EStripWrappers aStripWrappers) {
|
2018-10-30 10:02:58 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
Bug 1467794 - Split TextEditor::DeleteSelectionAsAction() to itself and TextEditor::DeleteSelectionAsSubAction() r=m_kato
TextEditor::DeleteSelectionAsAction() is called even if it's a part of edit
action. For example, it's called to prepare for inserting text.
For bug 1465702, editor itself and edit rules classes should not call
public DeleteSelectionAsAction() directly. Therefore, this patch creates
DeleteSelectionAsSubAction() for internal use.
Note that this patch adds NS_ASSERTION() to detect wrong caller. However,
it cannot distinguish if the call is valid, for example, it's allowed to
call DeleteSelectionAsSelection() even if it's handling an edit action but
the method is called via mutation event listener. So, we need to allow
some assertions with some tests. But unfortunately, 1405747.html uses
mutation event listener too many times (about 1,000 times) and the number
of assertion isn't stable. Therefore, this patch makes the test stop using
the mutation event listener 2nd time since I can reproduce the crash with
ESR 52 at the 2nd time.
MozReview-Commit-ID: 1TWaypmnoCC
--HG--
extra : rebase_source : a6a4fb1cbcaf2ab6f10c5f3e7168a6bc0fcb02ed
2018-06-29 11:16:50 +00:00
|
|
|
MOZ_ASSERT(mPlaceholderBatch);
|
2012-05-10 14:54:33 +00:00
|
|
|
|
2018-10-30 10:02:58 +00:00
|
|
|
MOZ_ASSERT(aStripWrappers == eStrip || aStripWrappers == eNoStrip);
|
|
|
|
|
2019-09-18 08:40:08 +00:00
|
|
|
if (NS_WARN_IF(!mInitSucceeded)) {
|
2016-10-24 02:27:45 +00:00
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2019-09-18 03:01:28 +00:00
|
|
|
IgnoredErrorResult ignoredError;
|
2019-08-20 01:52:50 +00:00
|
|
|
AutoEditSubActionNotifier startToHandleEditSubAction(
|
2019-09-18 03:01:28 +00:00
|
|
|
*this, EditSubAction::eDeleteSelectedContent, aDirectionAndAmount,
|
|
|
|
ignoredError);
|
|
|
|
if (NS_WARN_IF(ignoredError.ErrorCodeIs(NS_ERROR_EDITOR_DESTROYED))) {
|
|
|
|
return ignoredError.StealNSResult();
|
|
|
|
}
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
!ignoredError.Failed(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"TextEditor::OnStartToHandleTopLevelEditSubAction() failed, but ignored");
|
2019-09-13 02:49:43 +00:00
|
|
|
|
|
|
|
EditActionResult result =
|
|
|
|
HandleDeleteSelection(aDirectionAndAmount, aStripWrappers);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (result.Failed() || result.Canceled()) {
|
|
|
|
NS_WARNING_ASSERTION(result.Succeeded(),
|
|
|
|
"TextEditor::HandleDeleteSelection() failed");
|
2019-09-13 02:49:43 +00:00
|
|
|
return result.Rv();
|
Bug 1463985 - part 1: Rename EditAction to EditSubAction and related stuff r=m_kato
When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
2018-05-28 11:12:34 +00:00
|
|
|
}
|
2019-09-12 06:51:26 +00:00
|
|
|
|
|
|
|
// XXX This is odd. We just tries to remove empty text node here but we
|
|
|
|
// refer `Selection`. It may be modified by mutation event listeners
|
|
|
|
// so that we should remove the empty text node when we make it empty.
|
|
|
|
EditorDOMPoint atNewStartOfSelection(
|
|
|
|
EditorBase::GetStartPoint(*SelectionRefPtr()));
|
|
|
|
if (NS_WARN_IF(!atNewStartOfSelection.IsSet())) {
|
|
|
|
// XXX And also it seems that we don't need to return error here.
|
|
|
|
// Why don't we just ignore? `Selection::RemoveAllRanges()` may
|
|
|
|
// have been called by mutation event listeners.
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
if (atNewStartOfSelection.IsInTextNode() &&
|
|
|
|
!atNewStartOfSelection.GetContainer()->Length()) {
|
|
|
|
nsresult rv = DeleteNodeWithTransaction(
|
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 15:27:38 +00:00
|
|
|
MOZ_KnownLive(*atNewStartOfSelection.ContainerAsText()));
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("EditorBase::DeleteNodeWithTransaction() failed");
|
2019-09-12 06:51:26 +00:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// XXX I don't think that this is necessary in anonymous `<div>` element of
|
|
|
|
// TextEditor since there should be at most one text node and at most
|
|
|
|
// one padding `<br>` element so that `<br>` element won't be before
|
|
|
|
// caret.
|
|
|
|
if (!TopLevelEditSubActionDataRef().mDidExplicitlySetInterLine) {
|
|
|
|
// We prevent the caret from sticking on the left of previous `<br>`
|
|
|
|
// element (i.e. the end of previous line) after this deletion. Bug 92124.
|
|
|
|
ErrorResult error;
|
|
|
|
SelectionRefPtr()->SetInterlinePosition(true, error);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (error.Failed()) {
|
|
|
|
NS_WARNING("Selection::SetInterlinePosition(true) failed");
|
2019-09-12 06:51:26 +00:00
|
|
|
return error.StealNSResult();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NS_OK;
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2018-04-11 10:11:15 +00:00
|
|
|
nsresult TextEditor::DeleteSelectionWithTransaction(
|
|
|
|
EDirection aDirection, EStripWrappers aStripWrappers) {
|
2018-10-30 10:02:58 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
2018-04-11 08:37:49 +00:00
|
|
|
|
2018-10-30 10:02:58 +00:00
|
|
|
MOZ_ASSERT(aStripWrappers == eStrip || aStripWrappers == eNoStrip);
|
2018-04-11 08:37:49 +00:00
|
|
|
|
|
|
|
RefPtr<EditAggregateTransaction> deleteSelectionTransaction;
|
|
|
|
nsCOMPtr<nsINode> deleteNode;
|
|
|
|
int32_t deleteCharOffset = 0, deleteCharLength = 0;
|
2018-10-30 10:02:58 +00:00
|
|
|
if (!SelectionRefPtr()->IsCollapsed() || aDirection != eNone) {
|
2018-04-11 08:37:49 +00:00
|
|
|
deleteSelectionTransaction =
|
|
|
|
CreateTxnForDeleteSelection(aDirection, getter_AddRefs(deleteNode),
|
|
|
|
&deleteCharOffset, &deleteCharLength);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (!deleteSelectionTransaction) {
|
|
|
|
NS_WARNING("EditorBase::CreateTxnForDeleteSelection() failed");
|
2018-04-11 08:37:49 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
RefPtr<CharacterData> deleteCharData =
|
|
|
|
CharacterData::FromNodeOrNull(deleteNode);
|
2019-09-18 03:01:28 +00:00
|
|
|
IgnoredErrorResult ignoredError;
|
2019-08-20 01:52:50 +00:00
|
|
|
AutoEditSubActionNotifier startToHandleEditSubAction(
|
2019-09-18 03:01:28 +00:00
|
|
|
*this, EditSubAction::eDeleteSelectedContent, aDirection, ignoredError);
|
|
|
|
if (NS_WARN_IF(ignoredError.ErrorCodeIs(NS_ERROR_EDITOR_DESTROYED))) {
|
|
|
|
return ignoredError.StealNSResult();
|
|
|
|
}
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
!ignoredError.Failed(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"TextEditor::OnStartToHandleTopLevelEditSubAction() failed, but ignored");
|
2018-04-11 08:37:49 +00:00
|
|
|
|
2019-09-17 04:27:59 +00:00
|
|
|
if (AsHTMLEditor()) {
|
2018-04-11 08:37:49 +00:00
|
|
|
if (!deleteNode) {
|
2019-09-17 04:27:59 +00:00
|
|
|
// XXX We may remove multiple ranges in the following. Therefore,
|
|
|
|
// this must have a bug since we only add the first range into
|
|
|
|
// the changed range.
|
|
|
|
TopLevelEditSubActionDataRef().WillDeleteRange(
|
|
|
|
*this, EditorBase::GetStartPoint(*SelectionRefPtr()),
|
|
|
|
EditorBase::GetEndPoint(*SelectionRefPtr()));
|
2018-04-11 08:37:49 +00:00
|
|
|
} else if (!deleteCharData) {
|
2019-09-17 04:27:59 +00:00
|
|
|
MOZ_ASSERT(deleteNode->IsContent());
|
|
|
|
TopLevelEditSubActionDataRef().WillDeleteContent(
|
|
|
|
*this, *deleteNode->AsContent());
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Notify nsIEditActionListener::WillDelete[Selection|Text]
|
|
|
|
if (!mActionListeners.IsEmpty()) {
|
|
|
|
if (!deleteNode) {
|
|
|
|
AutoActionListenerArray listeners(mActionListeners);
|
|
|
|
for (auto& listener : listeners) {
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
listener->WillDeleteSelection(SelectionRefPtr());
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsIEditActionListener::WillDeleteSelection() failed, but ignored");
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
} else if (deleteCharData) {
|
|
|
|
AutoActionListenerArray listeners(mActionListeners);
|
|
|
|
for (auto& listener : listeners) {
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
listener->WillDeleteText(deleteCharData, deleteCharOffset, 1);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsIEditActionListener::WillDeleteText() failed, but ignored");
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Delete the specified amount
|
2018-10-30 10:01:38 +00:00
|
|
|
nsresult rv = DoTransactionInternal(deleteSelectionTransaction);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"EditorBase::DoTransactionInternal() failed");
|
2018-04-11 08:37:49 +00:00
|
|
|
|
2019-09-17 04:27:59 +00:00
|
|
|
if (AsHTMLEditor() && deleteCharData) {
|
2018-04-26 14:27:50 +00:00
|
|
|
MOZ_ASSERT(deleteNode);
|
2019-09-17 04:27:59 +00:00
|
|
|
TopLevelEditSubActionDataRef().DidDeleteText(*this,
|
|
|
|
EditorRawDOMPoint(deleteNode));
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (mTextServicesDocument && NS_SUCCEEDED(rv) && deleteNode &&
|
|
|
|
!deleteCharData) {
|
|
|
|
RefPtr<TextServicesDocument> textServicesDocument = mTextServicesDocument;
|
|
|
|
textServicesDocument->DidDeleteNode(deleteNode);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Notify nsIEditActionListener::DidDelete[Selection|Text|Node]
|
2020-03-18 01:14:42 +00:00
|
|
|
AutoActionListenerArray listeners(mActionListeners);
|
|
|
|
if (!deleteNode) {
|
|
|
|
for (auto& listener : mActionListeners) {
|
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
listener->DidDeleteSelection(SelectionRefPtr());
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsIEditActionListener::DidDeleteSelection() failed, but ignored");
|
|
|
|
}
|
|
|
|
} else if (deleteCharData) {
|
|
|
|
for (auto& listener : mActionListeners) {
|
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
listener->DidDeleteText(deleteCharData, deleteCharOffset, 1, rv);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsIEditActionListener::DidDeleteText() failed, but ignored");
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
for (auto& listener : mActionListeners) {
|
|
|
|
DebugOnly<nsresult> rvIgnored = listener->DidDeleteNode(deleteNode, rv);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsIEditActionListener::DidDeleteNode() failed, but ignored");
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
already_AddRefed<Element> TextEditor::DeleteSelectionAndCreateElement(
|
|
|
|
nsAtom& aTag) {
|
2018-10-30 10:04:08 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
2018-04-11 08:37:49 +00:00
|
|
|
nsresult rv = DeleteSelectionAndPrepareToCreateNode();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("TextEditor::DeleteSelectionAndPrepareToCreateNode() failed");
|
2018-04-11 08:37:49 +00:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2019-05-08 09:40:17 +00:00
|
|
|
EditorDOMPoint pointToInsert(SelectionRefPtr()->AnchorRef());
|
2018-04-11 08:37:49 +00:00
|
|
|
if (!pointToInsert.IsSet()) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
RefPtr<Element> newElement = CreateNodeWithTransaction(aTag, pointToInsert);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (!newElement) {
|
|
|
|
NS_WARNING("EditorBase::CreateNodeWithTransaction() failed");
|
|
|
|
return nullptr;
|
|
|
|
}
|
2018-04-11 08:37:49 +00:00
|
|
|
|
|
|
|
// We want the selection to be just after the new node
|
2020-03-18 01:14:42 +00:00
|
|
|
EditorRawDOMPoint afterNewElement(EditorRawDOMPoint::After(newElement));
|
2018-04-11 08:37:49 +00:00
|
|
|
MOZ_ASSERT(afterNewElement.IsSetAndValid());
|
2020-03-18 01:14:42 +00:00
|
|
|
IgnoredErrorResult ignoredError;
|
|
|
|
SelectionRefPtr()->Collapse(afterNewElement, ignoredError);
|
|
|
|
if (ignoredError.Failed()) {
|
|
|
|
NS_WARNING("Selection::Collapse() failed");
|
2018-04-11 08:37:49 +00:00
|
|
|
// XXX Even if it succeeded to create new element, this returns error
|
|
|
|
// when Selection.Collapse() fails something. This could occur with
|
|
|
|
// mutation observer or mutation event listener.
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
return newElement.forget();
|
|
|
|
}
|
|
|
|
|
|
|
|
nsresult TextEditor::DeleteSelectionAndPrepareToCreateNode() {
|
2018-10-30 10:04:08 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
2018-04-11 08:37:49 +00:00
|
|
|
|
2018-10-30 10:04:08 +00:00
|
|
|
if (NS_WARN_IF(!SelectionRefPtr()->GetAnchorFocusRange())) {
|
2018-04-11 08:37:49 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2018-10-30 10:04:08 +00:00
|
|
|
if (!SelectionRefPtr()->GetAnchorFocusRange()->Collapsed()) {
|
Bug 1467794 - Split TextEditor::DeleteSelectionAsAction() to itself and TextEditor::DeleteSelectionAsSubAction() r=m_kato
TextEditor::DeleteSelectionAsAction() is called even if it's a part of edit
action. For example, it's called to prepare for inserting text.
For bug 1465702, editor itself and edit rules classes should not call
public DeleteSelectionAsAction() directly. Therefore, this patch creates
DeleteSelectionAsSubAction() for internal use.
Note that this patch adds NS_ASSERTION() to detect wrong caller. However,
it cannot distinguish if the call is valid, for example, it's allowed to
call DeleteSelectionAsSelection() even if it's handling an edit action but
the method is called via mutation event listener. So, we need to allow
some assertions with some tests. But unfortunately, 1405747.html uses
mutation event listener too many times (about 1,000 times) and the number
of assertion isn't stable. Therefore, this patch makes the test stop using
the mutation event listener 2nd time since I can reproduce the crash with
ESR 52 at the 2nd time.
MozReview-Commit-ID: 1TWaypmnoCC
--HG--
extra : rebase_source : a6a4fb1cbcaf2ab6f10c5f3e7168a6bc0fcb02ed
2018-06-29 11:16:50 +00:00
|
|
|
nsresult rv = DeleteSelectionAsSubAction(eNone, eStrip);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("TextEditor::DeleteSelectionAsSubAction() failed");
|
2018-04-11 08:37:49 +00:00
|
|
|
return rv;
|
|
|
|
}
|
2018-10-30 10:04:08 +00:00
|
|
|
MOZ_ASSERT(SelectionRefPtr()->GetAnchorFocusRange() &&
|
|
|
|
SelectionRefPtr()->GetAnchorFocusRange()->Collapsed(),
|
2018-04-11 08:37:49 +00:00
|
|
|
"Selection not collapsed after delete");
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the selection is a chardata node, split it if necessary and compute
|
|
|
|
// where to put the new node
|
2018-10-30 10:04:08 +00:00
|
|
|
EditorDOMPoint atAnchor(SelectionRefPtr()->AnchorRef());
|
2018-04-11 08:37:49 +00:00
|
|
|
if (NS_WARN_IF(!atAnchor.IsSet()) || !atAnchor.IsInDataNode()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_WARN_IF(!atAnchor.GetContainerParent())) {
|
2018-04-11 08:37:49 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (atAnchor.IsStartOfContainer()) {
|
|
|
|
EditorRawDOMPoint atAnchorContainer(atAnchor.GetContainer());
|
|
|
|
if (NS_WARN_IF(!atAnchorContainer.IsSetAndValid())) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
ErrorResult error;
|
2018-10-30 10:04:08 +00:00
|
|
|
SelectionRefPtr()->Collapse(atAnchorContainer, error);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(!error.Failed(), "Selection::Collapse() failed");
|
|
|
|
return error.StealNSResult();
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (atAnchor.IsEndOfContainer()) {
|
|
|
|
EditorRawDOMPoint afterAnchorContainer(atAnchor.GetContainer());
|
|
|
|
if (NS_WARN_IF(!afterAnchorContainer.AdvanceOffset())) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
ErrorResult error;
|
2018-10-30 10:04:08 +00:00
|
|
|
SelectionRefPtr()->Collapse(afterAnchorContainer, error);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(!error.Failed(), "Selection::Collapse() failed");
|
|
|
|
return error.StealNSResult();
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ErrorResult error;
|
|
|
|
nsCOMPtr<nsIContent> newLeftNode = SplitNodeWithTransaction(atAnchor, error);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (error.Failed()) {
|
|
|
|
NS_WARNING("EditorBase::SplitNodeWithTransaction() failed");
|
2018-04-11 08:37:49 +00:00
|
|
|
return error.StealNSResult();
|
|
|
|
}
|
|
|
|
|
|
|
|
EditorRawDOMPoint atRightNode(atAnchor.GetContainer());
|
|
|
|
if (NS_WARN_IF(!atRightNode.IsSet())) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
MOZ_ASSERT(atRightNode.IsSetAndValid());
|
2018-10-30 10:04:08 +00:00
|
|
|
SelectionRefPtr()->Collapse(atRightNode, error);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(!error.Failed(), "Selection::Collapse() failed");
|
|
|
|
return error.StealNSResult();
|
2018-04-11 08:37:49 +00:00
|
|
|
}
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
nsresult TextEditor::SetTextAsAction(const nsAString& aString,
|
|
|
|
nsIPrincipal* aPrincipal) {
|
2019-11-28 05:51:41 +00:00
|
|
|
MOZ_ASSERT(aString.FindChar(nsCRT::CR) == kNotFound);
|
2020-03-03 03:39:26 +00:00
|
|
|
MOZ_ASSERT(!AsHTMLEditor());
|
2018-07-24 08:46:12 +00:00
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eSetText,
|
|
|
|
aPrincipal);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsresult rv = editActionData.CanHandleAndMaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"CanHandleAndMaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-10-30 09:59:33 +00:00
|
|
|
}
|
|
|
|
|
2018-10-24 09:42:06 +00:00
|
|
|
AutoPlaceholderBatch treatAsOneTransaction(*this);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
rv = SetTextAsSubAction(aString);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::SetTextAsSubAction() failed");
|
2019-09-17 02:21:35 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-07-03 13:25:52 +00:00
|
|
|
}
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
nsresult TextEditor::ReplaceTextAsAction(const nsAString& aString,
|
|
|
|
nsRange* aReplaceRange,
|
|
|
|
nsIPrincipal* aPrincipal) {
|
2019-11-28 05:51:41 +00:00
|
|
|
MOZ_ASSERT(aString.FindChar(nsCRT::CR) == kNotFound);
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eReplaceText,
|
|
|
|
aPrincipal);
|
2020-03-03 03:39:26 +00:00
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
Bug 998941 - part 1-3: Make TextEditor (only when not HTMLEditor instance) set InputEvent.data to inserting string when InputEvent.inputType is "insertFromPaste", "insertFromDrop" or "insertReplacementText" r=smaug,m_kato
https://rawgit.com/w3c/input-events/v1/index.html#dfn-data
https://w3c.github.io/input-events/#dfn-data
Both Input Events Level 1 and Level 2 declare that InputEvent.data should be
set to inserting string only on TextEditor when InputEvent.inputType is
"insertFromPaste", "insertFromPasteAsQuotation", "insertFromDrop",
"insertTranspose", "insertReplacementText" or "insertFromYank".
Currently, we support only "insertFromPaste", "insertFromDrop",
"insertReplacementText". Therefore, this patch makes TextEditor set
EditorBase::mEditActionData::mData only for them (and the instance is not
HTMLEditor's).
Differential Revision: https://phabricator.services.mozilla.com/D19287
--HG--
extra : moz-landing-system : lando
2019-02-19 06:28:57 +00:00
|
|
|
if (!AsHTMLEditor()) {
|
|
|
|
editActionData.SetData(aString);
|
2019-02-19 06:33:42 +00:00
|
|
|
} else {
|
|
|
|
editActionData.InitializeDataTransfer(aString);
|
2020-03-03 03:39:26 +00:00
|
|
|
RefPtr<StaticRange> targetRange;
|
|
|
|
if (aReplaceRange) {
|
|
|
|
// Compute offset of the range before dispatching `beforeinput` event
|
|
|
|
// because it may be referred after the DOM tree is changed and the
|
|
|
|
// range may have not computed the offset yet.
|
|
|
|
targetRange = StaticRange::Create(
|
|
|
|
aReplaceRange->GetStartContainer(), aReplaceRange->StartOffset(),
|
|
|
|
aReplaceRange->GetEndContainer(), aReplaceRange->EndOffset(),
|
|
|
|
IgnoreErrors());
|
|
|
|
NS_WARNING_ASSERTION(targetRange && targetRange->IsPositioned(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"StaticRange::Create() failed");
|
2020-03-03 03:39:26 +00:00
|
|
|
} else {
|
|
|
|
Element* editingHost = AsHTMLEditor()->GetActiveEditingHost();
|
|
|
|
NS_WARNING_ASSERTION(editingHost,
|
|
|
|
"No active editing host, no target ranges");
|
|
|
|
if (editingHost) {
|
|
|
|
targetRange = StaticRange::Create(
|
|
|
|
editingHost, 0, editingHost, editingHost->Length(), IgnoreErrors());
|
|
|
|
NS_WARNING_ASSERTION(targetRange && targetRange->IsPositioned(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"StaticRange::Create() failed");
|
2020-03-03 03:39:26 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (targetRange && targetRange->IsPositioned()) {
|
|
|
|
editActionData.AppendTargetRange(*targetRange);
|
|
|
|
}
|
Bug 998941 - part 1-3: Make TextEditor (only when not HTMLEditor instance) set InputEvent.data to inserting string when InputEvent.inputType is "insertFromPaste", "insertFromDrop" or "insertReplacementText" r=smaug,m_kato
https://rawgit.com/w3c/input-events/v1/index.html#dfn-data
https://w3c.github.io/input-events/#dfn-data
Both Input Events Level 1 and Level 2 declare that InputEvent.data should be
set to inserting string only on TextEditor when InputEvent.inputType is
"insertFromPaste", "insertFromPasteAsQuotation", "insertFromDrop",
"insertTranspose", "insertReplacementText" or "insertFromYank".
Currently, we support only "insertFromPaste", "insertFromDrop",
"insertReplacementText". Therefore, this patch makes TextEditor set
EditorBase::mEditActionData::mData only for them (and the instance is not
HTMLEditor's).
Differential Revision: https://phabricator.services.mozilla.com/D19287
--HG--
extra : moz-landing-system : lando
2019-02-19 06:28:57 +00:00
|
|
|
}
|
2020-03-03 03:39:26 +00:00
|
|
|
|
|
|
|
nsresult rv = editActionData.MaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"MaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
2018-10-30 09:59:33 +00:00
|
|
|
|
2018-10-24 09:42:06 +00:00
|
|
|
AutoPlaceholderBatch treatAsOneTransaction(*this);
|
2018-07-03 13:25:52 +00:00
|
|
|
|
|
|
|
// This should emulates inserting text for better undo/redo behavior.
|
2019-09-18 03:01:28 +00:00
|
|
|
IgnoredErrorResult ignoredError;
|
2019-08-20 01:52:50 +00:00
|
|
|
AutoEditSubActionNotifier startToHandleEditSubAction(
|
2019-09-18 03:01:28 +00:00
|
|
|
*this, EditSubAction::eInsertText, nsIEditor::eNext, ignoredError);
|
|
|
|
if (NS_WARN_IF(ignoredError.ErrorCodeIs(NS_ERROR_EDITOR_DESTROYED))) {
|
|
|
|
return EditorBase::ToGenericNSResult(ignoredError.StealNSResult());
|
|
|
|
}
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
!ignoredError.Failed(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"TextEditor::OnStartToHandleTopLevelEditSubAction() failed, but ignored");
|
2018-07-03 13:25:52 +00:00
|
|
|
|
2018-07-04 13:51:55 +00:00
|
|
|
if (!aReplaceRange) {
|
|
|
|
nsresult rv = SetTextAsSubAction(aString);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::SetTextAsSubAction() failed");
|
2019-09-17 02:21:35 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-07-04 13:51:55 +00:00
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
if (aString.IsEmpty() && aReplaceRange->Collapsed()) {
|
|
|
|
NS_WARNING("Setting value was empty and replaced range was empty");
|
2018-07-04 13:51:55 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Note that do not notify selectionchange caused by selecting all text
|
|
|
|
// because it's preparation of our delete implementation so web apps
|
|
|
|
// shouldn't receive such selectionchange before the first mutation.
|
2018-10-24 09:42:06 +00:00
|
|
|
AutoUpdateViewBatch preventSelectionChangeEvent(*this);
|
2018-07-04 13:51:55 +00:00
|
|
|
|
|
|
|
// Select the range but as far as possible, we should not create new range
|
|
|
|
// even if it's part of special Selection.
|
|
|
|
ErrorResult error;
|
2020-01-30 12:44:33 +00:00
|
|
|
SelectionRefPtr()->RemoveAllRanges(error);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (error.Failed()) {
|
|
|
|
NS_WARNING("Selection::RemoveAllRanges() failed");
|
2020-01-30 12:44:33 +00:00
|
|
|
return error.StealNSResult();
|
|
|
|
}
|
2020-03-13 15:46:13 +00:00
|
|
|
MOZ_KnownLive(SelectionRefPtr())
|
|
|
|
->AddRangeAndSelectFramesAndNotifyListeners(*aReplaceRange, error);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (error.Failed()) {
|
|
|
|
NS_WARNING("Selection::AddRangeAndSelectFramesAndNotifyListeners() failed");
|
2018-07-04 13:51:55 +00:00
|
|
|
return error.StealNSResult();
|
|
|
|
}
|
|
|
|
|
|
|
|
rv = ReplaceSelectionAsSubAction(aString);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
2020-03-18 01:14:42 +00:00
|
|
|
"TextEditor::ReplaceSelectionAsSubAction() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-07-03 13:25:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
nsresult TextEditor::SetTextAsSubAction(const nsAString& aString) {
|
2018-10-30 10:02:58 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
2018-07-03 13:25:52 +00:00
|
|
|
MOZ_ASSERT(mPlaceholderBatch);
|
|
|
|
|
2019-09-17 06:58:06 +00:00
|
|
|
if (NS_WARN_IF(!mInitSucceeded)) {
|
2017-05-25 05:30:50 +00:00
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
2019-09-18 03:01:28 +00:00
|
|
|
IgnoredErrorResult ignoredError;
|
2019-08-20 01:52:50 +00:00
|
|
|
AutoEditSubActionNotifier startToHandleEditSubAction(
|
2019-09-18 03:01:28 +00:00
|
|
|
*this, EditSubAction::eSetText, nsIEditor::eNext, ignoredError);
|
|
|
|
if (NS_WARN_IF(ignoredError.ErrorCodeIs(NS_ERROR_EDITOR_DESTROYED))) {
|
|
|
|
return ignoredError.StealNSResult();
|
|
|
|
}
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
!ignoredError.Failed(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"TextEditor::OnStartToHandleTopLevelEditSubAction() failed, but ignored");
|
2017-05-25 05:30:50 +00:00
|
|
|
|
2019-09-17 02:21:35 +00:00
|
|
|
if (IsPlaintextEditor() && !IsIMEComposing() && !IsUndoRedoEnabled() &&
|
|
|
|
GetEditAction() != EditAction::eReplaceText && mMaxTextLength < 0) {
|
|
|
|
EditActionResult result = SetTextWithoutTransaction(aString);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (result.Failed() || result.Canceled() || result.Handled()) {
|
|
|
|
NS_WARNING_ASSERTION(result.Succeeded(),
|
|
|
|
"TextEditor::SetTextWithoutTransaction() failed");
|
2019-09-17 02:21:35 +00:00
|
|
|
return result.Rv();
|
|
|
|
}
|
2019-09-14 23:32:09 +00:00
|
|
|
}
|
2019-09-17 02:21:35 +00:00
|
|
|
|
|
|
|
{
|
2018-07-03 13:25:52 +00:00
|
|
|
// Note that do not notify selectionchange caused by selecting all text
|
|
|
|
// because it's preparation of our delete implementation so web apps
|
|
|
|
// shouldn't receive such selectionchange before the first mutation.
|
2018-10-24 09:42:06 +00:00
|
|
|
AutoUpdateViewBatch preventSelectionChangeEvent(*this);
|
2018-07-03 13:25:52 +00:00
|
|
|
|
2019-03-26 10:06:43 +00:00
|
|
|
Element* rootElement = GetRoot();
|
|
|
|
if (NS_WARN_IF(!rootElement)) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
2019-09-17 02:21:35 +00:00
|
|
|
// We want to select trailing `<br>` element to remove all nodes to replace
|
|
|
|
// all, but TextEditor::SelectEntireDocument() doesn't select such `<br>`
|
|
|
|
// elements.
|
|
|
|
// XXX We should make ReplaceSelectionAsSubAction() take range. Then,
|
|
|
|
// we can saving the expensive cost of modifying `Selection` here.
|
|
|
|
nsresult rv;
|
2019-09-17 06:58:06 +00:00
|
|
|
if (IsEmpty()) {
|
2018-10-30 10:02:58 +00:00
|
|
|
rv = SelectionRefPtr()->Collapse(rootElement, 0);
|
2019-09-17 02:21:35 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"Selection::Collapse() failed, but ignored");
|
2017-05-25 05:30:50 +00:00
|
|
|
} else {
|
2019-09-17 06:58:06 +00:00
|
|
|
// XXX Oh, we shouldn't select padding `<br>` element for empty last
|
|
|
|
// line here since we will need to recreate it in multiline
|
|
|
|
// text editor.
|
2019-03-26 10:06:43 +00:00
|
|
|
ErrorResult error;
|
|
|
|
SelectionRefPtr()->SelectAllChildren(*rootElement, error);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
!error.Failed(),
|
2019-09-17 02:21:35 +00:00
|
|
|
"Selection::SelectAllChildren() failed, but ignored");
|
2019-03-26 10:06:43 +00:00
|
|
|
rv = error.StealNSResult();
|
2017-05-25 05:30:50 +00:00
|
|
|
}
|
|
|
|
if (NS_SUCCEEDED(rv)) {
|
2019-09-17 02:21:35 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored = ReplaceSelectionAsSubAction(aString);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"TextEditor::ReplaceSelectionAsSubAction() failed, but ignored");
|
2017-05-25 05:30:50 +00:00
|
|
|
}
|
|
|
|
}
|
2019-09-17 02:21:35 +00:00
|
|
|
|
|
|
|
// Destroying AutoUpdateViewBatch may cause destroying us.
|
2020-03-18 01:14:42 +00:00
|
|
|
return NS_WARN_IF(Destroyed()) ? NS_ERROR_EDITOR_DESTROYED : NS_OK;
|
2017-05-25 05:30:50 +00:00
|
|
|
}
|
|
|
|
|
2018-07-04 13:51:55 +00:00
|
|
|
nsresult TextEditor::ReplaceSelectionAsSubAction(const nsAString& aString) {
|
|
|
|
if (aString.IsEmpty()) {
|
|
|
|
nsresult rv = DeleteSelectionAsSubAction(eNone, eStrip);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::DeleteSelectionAsSubAction(eNone, eStrip) failed");
|
|
|
|
return rv;
|
2018-07-04 13:51:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
nsresult rv = InsertTextAsSubAction(aString);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"EditorBase::InsertTextAsSubAction() failed");
|
|
|
|
return rv;
|
2018-07-04 13:51:55 +00:00
|
|
|
}
|
|
|
|
|
2018-04-18 15:31:51 +00:00
|
|
|
bool TextEditor::EnsureComposition(WidgetCompositionEvent& aCompositionEvent) {
|
|
|
|
if (mComposition) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
// The compositionstart event must cause creating new TextComposition
|
|
|
|
// instance at being dispatched by IMEStateManager.
|
|
|
|
mComposition = IMEStateManager::GetTextCompositionFor(&aCompositionEvent);
|
|
|
|
if (!mComposition) {
|
|
|
|
// However, TextComposition may be committed before the composition
|
|
|
|
// event comes here.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
mComposition->StartHandlingComposition(this);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsresult TextEditor::OnCompositionStart(
|
|
|
|
WidgetCompositionEvent& aCompositionStartEvent) {
|
2020-03-18 01:14:42 +00:00
|
|
|
if (mComposition) {
|
|
|
|
NS_WARNING("There was a composition at receiving compositionstart event");
|
2018-04-18 15:31:51 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
2005-03-07 12:25:26 +00:00
|
|
|
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
// "beforeinput" event shouldn't be fired before "compositionstart".
|
2018-10-30 09:59:33 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eStartComposition);
|
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
2018-04-18 15:31:51 +00:00
|
|
|
EnsureComposition(aCompositionStartEvent);
|
|
|
|
NS_WARNING_ASSERTION(mComposition, "Failed to get TextComposition instance?");
|
|
|
|
return NS_OK;
|
2010-06-30 04:05:12 +00:00
|
|
|
}
|
|
|
|
|
2018-11-01 08:07:04 +00:00
|
|
|
nsresult TextEditor::OnCompositionChange(
|
|
|
|
WidgetCompositionEvent& aCompositionChangeEvent) {
|
|
|
|
MOZ_ASSERT(aCompositionChangeEvent.mMessage == eCompositionChange,
|
2017-01-17 08:01:17 +00:00
|
|
|
"The event should be eCompositionChange");
|
2014-02-12 13:02:55 +00:00
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
if (!mComposition) {
|
|
|
|
NS_WARNING(
|
|
|
|
"There is no composition, but receiving compositionchange event");
|
2018-11-01 08:07:04 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
|
|
|
AutoEditActionDataSetter editActionData(*this,
|
|
|
|
EditAction::eUpdateComposition);
|
2018-10-30 09:59:33 +00:00
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
2018-11-01 08:07:04 +00:00
|
|
|
// If:
|
|
|
|
// - new composition string is not empty,
|
|
|
|
// - there is no composition string in the DOM tree,
|
|
|
|
// - and there is non-collapsed Selection,
|
|
|
|
// the selected content will be removed by this composition.
|
|
|
|
if (aCompositionChangeEvent.mData.IsEmpty() &&
|
|
|
|
mComposition->String().IsEmpty() && !SelectionRefPtr()->IsCollapsed()) {
|
|
|
|
editActionData.UpdateEditAction(EditAction::eDeleteByComposition);
|
|
|
|
}
|
|
|
|
|
2019-02-19 06:28:19 +00:00
|
|
|
// If Input Events Level 2 is enabled, EditAction::eDeleteByComposition is
|
|
|
|
// mapped to EditorInputType::eDeleteByComposition and it requires null
|
|
|
|
// for InputEvent.data. Therefore, only otherwise, we should set data.
|
|
|
|
if (ToInputType(editActionData.GetEditAction()) !=
|
|
|
|
EditorInputType::eDeleteByComposition) {
|
|
|
|
MOZ_ASSERT(ToInputType(editActionData.GetEditAction()) ==
|
|
|
|
EditorInputType::eInsertCompositionText);
|
|
|
|
MOZ_ASSERT(!aCompositionChangeEvent.mData.IsVoid());
|
|
|
|
editActionData.SetData(aCompositionChangeEvent.mData);
|
|
|
|
}
|
|
|
|
|
2020-03-03 03:39:26 +00:00
|
|
|
// If we're an `HTMLEditor` and this is second or later composition change,
|
|
|
|
// we should set target range to the range of composition string.
|
|
|
|
// Otherwise, set target ranges to selection ranges (will be done by
|
|
|
|
// editActionData itself before dispatching `beforeinput` event).
|
|
|
|
if (AsHTMLEditor() && mComposition->GetContainerTextNode()) {
|
|
|
|
RefPtr<StaticRange> targetRange = StaticRange::Create(
|
|
|
|
mComposition->GetContainerTextNode(),
|
|
|
|
mComposition->XPOffsetInTextNode(),
|
|
|
|
mComposition->GetContainerTextNode(),
|
|
|
|
mComposition->XPEndOffsetInTextNode(), IgnoreErrors());
|
|
|
|
NS_WARNING_ASSERTION(targetRange && targetRange->IsPositioned(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"StaticRange::Create() failed");
|
2020-03-03 03:39:26 +00:00
|
|
|
if (targetRange && targetRange->IsPositioned()) {
|
|
|
|
editActionData.AppendTargetRange(*targetRange);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
// TODO: We need to use different EditAction value for beforeinput event
|
|
|
|
// if the event is followed by "compositionend" because corresponding
|
|
|
|
// "input" event will be fired from OnCompositionEnd() later with
|
|
|
|
// different EditAction value.
|
|
|
|
// TODO: If Input Events Level 2 is enabled, "beforeinput" event may be
|
|
|
|
// actually canceled if edit action is eDeleteByComposition. In such
|
|
|
|
// case, we might need to keep selected text, but insert composition
|
|
|
|
// string before or after the selection. However, the spec is still
|
|
|
|
// unstable. We should keep handling the composition since other
|
|
|
|
// parts including widget may not be ready for such complicated
|
|
|
|
// behavior.
|
|
|
|
nsresult rv = editActionData.MaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (rv != NS_ERROR_EDITOR_ACTION_CANCELED && NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("MaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
if (!EnsureComposition(aCompositionChangeEvent)) {
|
|
|
|
NS_WARNING("TextEditor::EnsureComposition() failed");
|
2019-02-19 06:28:19 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2019-03-15 05:01:10 +00:00
|
|
|
if (NS_WARN_IF(!GetPresShell())) {
|
2018-04-18 15:31:51 +00:00
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
2010-06-30 04:05:12 +00:00
|
|
|
|
2014-09-26 00:05:13 +00:00
|
|
|
// NOTE: TextComposition should receive selection change notification before
|
2014-10-07 10:01:49 +00:00
|
|
|
// CompositionChangeEventHandlingMarker notifies TextComposition of the
|
|
|
|
// end of handling compositionchange event because TextComposition may
|
|
|
|
// need to ignore selection changes caused by composition. Therefore,
|
|
|
|
// CompositionChangeEventHandlingMarker must be destroyed after a call
|
|
|
|
// of NotifiyEditorObservers(eNotifyEditorObserversOfEnd) or
|
2014-09-26 00:05:13 +00:00
|
|
|
// NotifiyEditorObservers(eNotifyEditorObserversOfCancel) which notifies
|
|
|
|
// TextComposition of a selection change.
|
2017-06-14 10:05:48 +00:00
|
|
|
MOZ_ASSERT(
|
|
|
|
!mPlaceholderBatch,
|
2014-09-26 00:05:13 +00:00
|
|
|
"UpdateIMEComposition() must be called without place holder batch");
|
2014-10-07 10:01:49 +00:00
|
|
|
TextComposition::CompositionChangeEventHandlingMarker
|
2018-11-01 08:07:04 +00:00
|
|
|
compositionChangeEventHandlingMarker(mComposition,
|
|
|
|
&aCompositionChangeEvent);
|
2014-09-26 00:05:13 +00:00
|
|
|
|
2019-03-15 05:01:10 +00:00
|
|
|
RefPtr<nsCaret> caret = GetCaret();
|
2010-06-30 04:05:12 +00:00
|
|
|
|
2014-02-12 13:02:57 +00:00
|
|
|
{
|
2018-10-24 09:42:06 +00:00
|
|
|
AutoPlaceholderBatch treatAsOneTransaction(*this, *nsGkAtoms::IMETxnName);
|
2010-11-24 22:57:32 +00:00
|
|
|
|
Bug 1463985 - part 1: Rename EditAction to EditSubAction and related stuff r=m_kato
When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
2018-05-28 11:12:34 +00:00
|
|
|
MOZ_ASSERT(
|
|
|
|
mIsInEditSubAction,
|
2017-08-14 05:56:39 +00:00
|
|
|
"AutoPlaceholderBatch should've notified the observes of before-edit");
|
2019-11-28 05:51:41 +00:00
|
|
|
nsString data(aCompositionChangeEvent.mData);
|
|
|
|
if (!AsTextEditor()) {
|
|
|
|
nsContentUtils::PlatformToDOMLineBreaks(data);
|
|
|
|
}
|
|
|
|
rv = InsertTextAsSubAction(data);
|
2018-04-16 14:43:36 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
2020-03-18 01:14:42 +00:00
|
|
|
"EditorBase::InsertTextAsSubAction() failed");
|
2010-05-28 01:18:48 +00:00
|
|
|
|
2019-03-15 05:01:10 +00:00
|
|
|
if (caret) {
|
|
|
|
caret->SetSelection(SelectionRefPtr());
|
2001-06-06 01:21:05 +00:00
|
|
|
}
|
2012-01-13 06:19:22 +00:00
|
|
|
}
|
|
|
|
|
2012-02-15 01:38:07 +00:00
|
|
|
// If still composing, we should fire input event via observer.
|
2015-09-08 03:54:14 +00:00
|
|
|
// Note that if the composition will be committed by the following
|
|
|
|
// compositionend event, we don't need to notify editor observes of this
|
|
|
|
// change.
|
2012-02-15 01:38:07 +00:00
|
|
|
// NOTE: We must notify after the auto batch will be gone.
|
2018-11-01 08:07:04 +00:00
|
|
|
if (!aCompositionChangeEvent.IsFollowedByCompositionEnd()) {
|
2014-07-31 04:37:59 +00:00
|
|
|
NotifyEditorObservers(eNotifyEditorObserversOfEnd);
|
2001-06-06 01:21:05 +00:00
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2001-06-06 01:21:05 +00:00
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2018-04-18 15:31:51 +00:00
|
|
|
void TextEditor::OnCompositionEnd(
|
|
|
|
WidgetCompositionEvent& aCompositionEndEvent) {
|
2020-03-18 01:14:42 +00:00
|
|
|
if (!mComposition) {
|
|
|
|
NS_WARNING("There is no composition, but receiving compositionend event");
|
2018-04-18 15:31:51 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-11-01 08:07:04 +00:00
|
|
|
EditAction editAction = aCompositionEndEvent.mData.IsEmpty()
|
|
|
|
? EditAction::eCancelComposition
|
|
|
|
: EditAction::eCommitComposition;
|
|
|
|
AutoEditActionDataSetter editActionData(*this, editAction);
|
2019-02-19 06:28:19 +00:00
|
|
|
// If Input Events Level 2 is enabled, EditAction::eCancelComposition is
|
|
|
|
// mapped to EditorInputType::eDeleteCompositionText and it requires null
|
|
|
|
// for InputEvent.data. Therefore, only otherwise, we should set data.
|
|
|
|
if (ToInputType(editAction) != EditorInputType::eDeleteCompositionText) {
|
|
|
|
MOZ_ASSERT(
|
|
|
|
ToInputType(editAction) == EditorInputType::eInsertCompositionText ||
|
|
|
|
ToInputType(editAction) == EditorInputType::eInsertFromComposition);
|
|
|
|
MOZ_ASSERT(!aCompositionEndEvent.mData.IsVoid());
|
|
|
|
editActionData.SetData(aCompositionEndEvent.mData);
|
|
|
|
}
|
2018-10-30 09:59:33 +00:00
|
|
|
|
2018-04-18 15:31:51 +00:00
|
|
|
// commit the IME transaction..we can get at it via the transaction mgr.
|
|
|
|
// Note that this means IME won't work without an undo stack!
|
|
|
|
if (mTransactionManager) {
|
|
|
|
nsCOMPtr<nsITransaction> txn = mTransactionManager->PeekUndoStack();
|
|
|
|
nsCOMPtr<nsIAbsorbingTransaction> plcTxn = do_QueryInterface(txn);
|
|
|
|
if (plcTxn) {
|
2020-03-11 02:11:52 +00:00
|
|
|
plcTxn->Commit();
|
2018-04-18 15:31:51 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
// Note that this just marks as that we've already handled "beforeinput" for
|
|
|
|
// preventing assertions in FireInputEvent(). Note that corresponding
|
|
|
|
// "beforeinput" event for the following "input" event should've already
|
|
|
|
// been dispatched from `OnCompositionChange()`.
|
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
editActionData.MaybeDispatchBeforeInputEvent();
|
|
|
|
MOZ_ASSERT(rvIgnored != NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"Why beforeinput event was canceled in this case?");
|
|
|
|
MOZ_ASSERT(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"MaybeDispatchBeforeInputEvent() should just mark the instance as "
|
|
|
|
"handled it");
|
|
|
|
|
2018-04-18 15:31:51 +00:00
|
|
|
// Composition string may have hidden the caret. Therefore, we need to
|
|
|
|
// cancel it here.
|
|
|
|
HideCaret(false);
|
|
|
|
|
|
|
|
// FYI: mComposition still keeps storing container text node of committed
|
|
|
|
// string, its offset and length. However, they will be invalidated
|
|
|
|
// soon since its Destroy() will be called by IMEStateManager.
|
|
|
|
mComposition->EndHandlingComposition(this);
|
|
|
|
mComposition = nullptr;
|
|
|
|
|
|
|
|
// notify editor observers of action
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
// FYI: With current draft, "input" event should be fired from
|
|
|
|
// OnCompositionChange(), however, it requires a lot of our UI code
|
|
|
|
// change and does not make sense. See spec issue:
|
|
|
|
// https://github.com/w3c/uievents/issues/202
|
2018-04-18 15:31:51 +00:00
|
|
|
NotifyEditorObservers(eNotifyEditorObserversOfEnd);
|
|
|
|
}
|
|
|
|
|
2020-04-13 01:43:41 +00:00
|
|
|
already_AddRefed<Element> TextEditor::GetInputEventTargetElement() const {
|
2018-11-21 03:59:02 +00:00
|
|
|
nsCOMPtr<Element> target = do_QueryInterface(mEventTarget);
|
2012-03-27 01:36:44 +00:00
|
|
|
return target.forget();
|
|
|
|
}
|
|
|
|
|
2019-09-17 06:58:06 +00:00
|
|
|
bool TextEditor::IsEmpty() const {
|
2019-08-09 07:03:29 +00:00
|
|
|
if (mPaddingBRElementForEmptyEditor) {
|
2019-09-17 06:58:06 +00:00
|
|
|
return true;
|
2017-08-24 10:53:34 +00:00
|
|
|
}
|
|
|
|
|
2019-08-02 05:44:40 +00:00
|
|
|
// Even if there is no padding <br> element for empty editor, we should be
|
|
|
|
// detected as empty editor if all the children are text nodes and these
|
|
|
|
// have no content.
|
2019-09-17 06:58:06 +00:00
|
|
|
Element* anonymousDivElement = GetRoot();
|
|
|
|
if (!anonymousDivElement) {
|
|
|
|
return true; // Don't warn it, this is possible, e.g., 997805.html
|
2017-08-24 10:53:34 +00:00
|
|
|
}
|
|
|
|
|
2019-09-17 06:58:06 +00:00
|
|
|
// Only when there is non-empty text node, we are not empty.
|
|
|
|
return !anonymousDivElement->GetFirstChild() ||
|
|
|
|
!anonymousDivElement->GetFirstChild()->IsText() ||
|
|
|
|
!anonymousDivElement->GetFirstChild()->Length();
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_IMETHODIMP TextEditor::GetDocumentIsEmpty(bool* aDocumentIsEmpty) {
|
2019-09-17 06:58:06 +00:00
|
|
|
MOZ_ASSERT(aDocumentIsEmpty);
|
|
|
|
*aDocumentIsEmpty = IsEmpty();
|
2018-07-18 08:44:14 +00:00
|
|
|
return NS_OK;
|
2017-08-24 10:53:34 +00:00
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_IMETHODIMP TextEditor::GetTextLength(int32_t* aCount) {
|
2018-07-18 08:51:49 +00:00
|
|
|
MOZ_ASSERT(aCount);
|
2005-10-17 00:54:02 +00:00
|
|
|
|
2001-01-28 20:13:07 +00:00
|
|
|
// initialize out params
|
|
|
|
*aCount = 0;
|
2015-05-28 15:58:42 +00:00
|
|
|
|
2019-08-02 05:44:40 +00:00
|
|
|
// special-case for empty document, to account for the padding <br> element
|
|
|
|
// for empty editor.
|
2019-09-17 06:58:06 +00:00
|
|
|
// XXX This should be overridden by `HTMLEditor` and we should return the
|
|
|
|
// first text node's length from `TextEditor` instead. The following
|
|
|
|
// code is too expensive.
|
|
|
|
if (IsEmpty()) {
|
2001-01-28 20:13:07 +00:00
|
|
|
return NS_OK;
|
2016-10-24 02:27:45 +00:00
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2018-07-18 08:51:49 +00:00
|
|
|
Element* rootElement = GetRoot();
|
|
|
|
if (NS_WARN_IF(!rootElement)) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
2005-10-17 00:54:02 +00:00
|
|
|
|
2012-08-22 15:56:38 +00:00
|
|
|
uint32_t totalLength = 0;
|
2019-01-11 01:52:26 +00:00
|
|
|
PostContentIterator postOrderIter;
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored = postOrderIter.Init(rootElement);
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"PostContentIterator::Init() failed, but ignored");
|
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 15:27:38 +00:00
|
|
|
EditorType editorType = GetEditorType();
|
2019-01-11 01:52:26 +00:00
|
|
|
for (; !postOrderIter.IsDone(); postOrderIter.Next()) {
|
2020-01-24 08:33:42 +00:00
|
|
|
nsINode* currentNode = postOrderIter.GetCurrentNode();
|
2020-04-15 16:05:30 +00:00
|
|
|
if (currentNode && currentNode->IsText() &&
|
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 15:27:38 +00:00
|
|
|
EditorUtils::IsEditableContent(*currentNode->AsText(), editorType)) {
|
2017-01-23 05:14:30 +00:00
|
|
|
totalLength += currentNode->Length();
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
}
|
2005-10-17 00:54:02 +00:00
|
|
|
|
|
|
|
*aCount = totalLength;
|
|
|
|
return NS_OK;
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
nsresult TextEditor::UndoAsAction(uint32_t aCount, nsIPrincipal* aPrincipal) {
|
2020-03-19 13:18:16 +00:00
|
|
|
if (aCount == 0 || IsReadonly()) {
|
2019-08-09 08:57:00 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2018-03-22 16:21:17 +00:00
|
|
|
// If we don't have transaction in the undo stack, we shouldn't notify
|
|
|
|
// anybody of trying to undo since it's not useful notification but we
|
|
|
|
// need to pay some runtime cost.
|
|
|
|
if (!CanUndo()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If there is composition, we shouldn't allow to undo with committing
|
|
|
|
// composition since Chrome doesn't allow it and it doesn't make sense
|
|
|
|
// because committing composition causes one transaction and Undo(1)
|
|
|
|
// undoes the committing composition.
|
|
|
|
if (GetComposition()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eUndo, aPrincipal);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsresult rv = editActionData.CanHandleAndMaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"CanHandleAndMaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-10-30 09:59:33 +00:00
|
|
|
}
|
|
|
|
|
2018-10-24 09:42:06 +00:00
|
|
|
AutoUpdateViewBatch preventSelectionChangeEvent(*this);
|
2011-01-20 00:25:03 +00:00
|
|
|
|
2014-07-31 04:37:59 +00:00
|
|
|
NotifyEditorObservers(eNotifyEditorObserversOfBefore);
|
2018-03-22 16:21:17 +00:00
|
|
|
if (NS_WARN_IF(!CanUndo()) || NS_WARN_IF(Destroyed())) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
2014-07-31 04:37:59 +00:00
|
|
|
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
rv = NS_OK;
|
2018-03-22 16:21:17 +00:00
|
|
|
{
|
2019-09-18 03:01:28 +00:00
|
|
|
IgnoredErrorResult ignoredError;
|
2019-08-20 01:52:50 +00:00
|
|
|
AutoEditSubActionNotifier startToHandleEditSubAction(
|
2019-09-18 03:01:28 +00:00
|
|
|
*this, EditSubAction::eUndo, nsIEditor::eNone, ignoredError);
|
|
|
|
if (NS_WARN_IF(ignoredError.ErrorCodeIs(NS_ERROR_EDITOR_DESTROYED))) {
|
|
|
|
return EditorBase::ToGenericNSResult(ignoredError.StealNSResult());
|
|
|
|
}
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(!ignoredError.Failed(),
|
|
|
|
"TextEditor::OnStartToHandleTopLevelEditSubAction() "
|
|
|
|
"failed, but ignored");
|
2018-03-22 16:21:17 +00:00
|
|
|
|
2019-08-09 08:57:00 +00:00
|
|
|
RefPtr<TransactionManager> transactionManager(mTransactionManager);
|
|
|
|
for (uint32_t i = 0; i < aCount; ++i) {
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(transactionManager->Undo())) {
|
|
|
|
NS_WARNING("TransactionManager::Undo() failed");
|
2019-08-09 08:57:00 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
DoAfterUndoTransaction();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (NS_WARN_IF(!mRootElement)) {
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
NS_WARNING("Failed to handle padding BR Element due to no root element");
|
2019-08-09 08:57:00 +00:00
|
|
|
rv = NS_ERROR_FAILURE;
|
|
|
|
} else {
|
|
|
|
// The idea here is to see if the magic empty node has suddenly
|
|
|
|
// reappeared as the result of the undo. If it has, set our state
|
|
|
|
// so we remember it. There is a tradeoff between doing here and
|
|
|
|
// at redo, or doing it everywhere else that might care. Since undo
|
|
|
|
// and redo are relatively rare, it makes sense to take the (small)
|
|
|
|
// performance hit here.
|
|
|
|
nsIContent* leftMostChild = GetLeftmostChild(mRootElement);
|
|
|
|
if (leftMostChild &&
|
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 15:27:38 +00:00
|
|
|
EditorUtils::IsPaddingBRElementForEmptyEditor(*leftMostChild)) {
|
2019-08-09 08:57:00 +00:00
|
|
|
mPaddingBRElementForEmptyEditor =
|
|
|
|
static_cast<HTMLBRElement*>(leftMostChild);
|
|
|
|
} else {
|
|
|
|
mPaddingBRElementForEmptyEditor = nullptr;
|
2018-03-22 16:21:17 +00:00
|
|
|
}
|
|
|
|
}
|
2015-05-28 15:58:42 +00:00
|
|
|
}
|
2014-07-31 04:37:59 +00:00
|
|
|
|
|
|
|
NotifyEditorObservers(eNotifyEditorObserversOfEnd);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
nsresult TextEditor::RedoAsAction(uint32_t aCount, nsIPrincipal* aPrincipal) {
|
2020-03-19 13:18:16 +00:00
|
|
|
if (aCount == 0 || IsReadonly()) {
|
2019-08-09 08:57:00 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2018-03-22 16:21:17 +00:00
|
|
|
// If we don't have transaction in the redo stack, we shouldn't notify
|
|
|
|
// anybody of trying to redo since it's not useful notification but we
|
|
|
|
// need to pay some runtime cost.
|
|
|
|
if (!CanRedo()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If there is composition, we shouldn't allow to redo with committing
|
|
|
|
// composition since Chrome doesn't allow it and it doesn't make sense
|
|
|
|
// because committing composition causes removing all transactions from
|
|
|
|
// the redo queue. So, it becomes impossible to redo anything.
|
|
|
|
if (GetComposition()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eRedo, aPrincipal);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsresult rv = editActionData.CanHandleAndMaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"CanHandleAndMaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-10-30 09:59:33 +00:00
|
|
|
}
|
|
|
|
|
2018-10-24 09:42:06 +00:00
|
|
|
AutoUpdateViewBatch preventSelectionChangeEvent(*this);
|
2011-01-20 00:25:03 +00:00
|
|
|
|
2014-07-31 04:37:59 +00:00
|
|
|
NotifyEditorObservers(eNotifyEditorObserversOfBefore);
|
2018-03-22 16:21:17 +00:00
|
|
|
if (NS_WARN_IF(!CanRedo()) || NS_WARN_IF(Destroyed())) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
2014-07-31 04:37:59 +00:00
|
|
|
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
rv = NS_OK;
|
2018-03-22 16:21:17 +00:00
|
|
|
{
|
2019-09-18 03:01:28 +00:00
|
|
|
IgnoredErrorResult ignoredError;
|
2019-08-20 01:52:50 +00:00
|
|
|
AutoEditSubActionNotifier startToHandleEditSubAction(
|
2019-09-18 03:01:28 +00:00
|
|
|
*this, EditSubAction::eRedo, nsIEditor::eNone, ignoredError);
|
|
|
|
if (NS_WARN_IF(ignoredError.ErrorCodeIs(NS_ERROR_EDITOR_DESTROYED))) {
|
|
|
|
return ignoredError.StealNSResult();
|
|
|
|
}
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(!ignoredError.Failed(),
|
|
|
|
"TextEditor::OnStartToHandleTopLevelEditSubAction() "
|
|
|
|
"failed, but ignored");
|
2018-03-22 16:21:17 +00:00
|
|
|
|
2019-08-09 08:57:00 +00:00
|
|
|
RefPtr<TransactionManager> transactionManager(mTransactionManager);
|
|
|
|
for (uint32_t i = 0; i < aCount; ++i) {
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(transactionManager->Redo())) {
|
|
|
|
NS_WARNING("TransactionManager::Redo() failed");
|
2019-08-09 08:57:00 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
DoAfterRedoTransaction();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (NS_WARN_IF(!mRootElement)) {
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
NS_WARNING("Failed to handle padding BR element due to no root element");
|
2019-08-09 08:57:00 +00:00
|
|
|
rv = NS_ERROR_FAILURE;
|
|
|
|
} else {
|
|
|
|
// We may take empty <br> element for empty editor back with this redo.
|
|
|
|
// We need to store it again.
|
|
|
|
// XXX Looks like that this is too slow if there are a lot of nodes.
|
|
|
|
// Shouldn't we just scan children in the root?
|
|
|
|
nsCOMPtr<nsIHTMLCollection> nodeList =
|
|
|
|
mRootElement->GetElementsByTagName(NS_LITERAL_STRING("br"));
|
|
|
|
MOZ_ASSERT(nodeList);
|
|
|
|
Element* brElement =
|
|
|
|
nodeList->Length() == 1 ? nodeList->Item(0) : nullptr;
|
|
|
|
if (brElement &&
|
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 15:27:38 +00:00
|
|
|
EditorUtils::IsPaddingBRElementForEmptyEditor(*brElement)) {
|
2019-08-09 08:57:00 +00:00
|
|
|
mPaddingBRElementForEmptyEditor =
|
|
|
|
static_cast<HTMLBRElement*>(brElement);
|
|
|
|
} else {
|
|
|
|
mPaddingBRElementForEmptyEditor = nullptr;
|
2018-03-22 16:21:17 +00:00
|
|
|
}
|
|
|
|
}
|
2015-05-28 15:58:42 +00:00
|
|
|
}
|
2014-07-31 04:37:59 +00:00
|
|
|
|
|
|
|
NotifyEditorObservers(eNotifyEditorObserversOfEnd);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2019-07-29 06:21:42 +00:00
|
|
|
bool TextEditor::IsCopyToClipboardAllowedInternal() const {
|
2018-10-30 10:04:08 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
2019-07-29 06:21:14 +00:00
|
|
|
if (SelectionRefPtr()->IsCollapsed()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!IsSingleLineEditor() || !IsPasswordEditor()) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we're a password editor, we should allow selected text to be copied
|
|
|
|
// to the clipboard only when selection range is in unmasked range.
|
|
|
|
if (IsAllMasked() || IsMaskingPassword() || mUnmaskedLength == 0) {
|
|
|
|
return false;
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2019-07-29 06:21:14 +00:00
|
|
|
// If there are 2 or more ranges, we don't allow to copy/cut for now since
|
|
|
|
// we need to check whether all ranges are in unmasked range or not.
|
|
|
|
// Anyway, such operation in password field does not make sense.
|
|
|
|
if (SelectionRefPtr()->RangeCount() > 1) {
|
2014-10-08 23:27:31 +00:00
|
|
|
return false;
|
2016-10-24 02:27:45 +00:00
|
|
|
}
|
2014-10-08 23:27:31 +00:00
|
|
|
|
2019-07-29 06:21:14 +00:00
|
|
|
uint32_t selectionStart = 0, selectionEnd = 0;
|
|
|
|
nsContentUtils::GetSelectionInTextControl(SelectionRefPtr(), mRootElement,
|
|
|
|
selectionStart, selectionEnd);
|
|
|
|
return mUnmaskedStart <= selectionStart && UnmaskedEnd() >= selectionEnd;
|
2007-07-26 04:14:33 +00:00
|
|
|
}
|
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
bool TextEditor::FireClipboardEvent(EventMessage aEventMessage,
|
|
|
|
int32_t aSelectionType,
|
|
|
|
bool* aActionTaken) {
|
2018-10-30 10:04:08 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
2015-09-08 14:33:35 +00:00
|
|
|
if (aEventMessage == ePaste) {
|
2017-08-08 02:25:36 +00:00
|
|
|
CommitComposition();
|
2015-08-26 12:56:59 +00:00
|
|
|
}
|
2007-09-29 17:56:04 +00:00
|
|
|
|
2019-03-15 05:01:10 +00:00
|
|
|
RefPtr<PresShell> presShell = GetPresShell();
|
2018-10-30 10:04:08 +00:00
|
|
|
if (NS_WARN_IF(!presShell)) {
|
2011-10-17 14:59:28 +00:00
|
|
|
return false;
|
2014-11-02 12:04:13 +00:00
|
|
|
}
|
2007-09-29 17:56:04 +00:00
|
|
|
|
2019-04-13 12:43:57 +00:00
|
|
|
if (!nsCopySupport::FireClipboardEvent(
|
|
|
|
aEventMessage, aSelectionType, presShell,
|
|
|
|
MOZ_KnownLive(SelectionRefPtr()), aActionTaken)) {
|
2011-10-17 14:59:28 +00:00
|
|
|
return false;
|
2015-08-26 12:56:59 +00:00
|
|
|
}
|
2007-09-29 17:56:04 +00:00
|
|
|
|
2010-03-19 18:32:13 +00:00
|
|
|
// If the event handler caused the editor to be destroyed, return false.
|
|
|
|
// Otherwise return true to indicate that the event was not cancelled.
|
|
|
|
return !mDidPreDestroy;
|
2007-09-29 17:56:04 +00:00
|
|
|
}
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
nsresult TextEditor::CutAsAction(nsIPrincipal* aPrincipal) {
|
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eCut, aPrincipal);
|
2018-10-30 09:59:33 +00:00
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
2015-05-13 06:51:00 +00:00
|
|
|
bool actionTaken = false;
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
if (!FireClipboardEvent(eCut, nsIClipboard::kGlobalClipboard, &actionTaken)) {
|
|
|
|
return EditorBase::ToGenericNSResult(
|
|
|
|
actionTaken ? NS_OK : NS_ERROR_EDITOR_ACTION_CANCELED);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 01:09:45 +00:00
|
|
|
}
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
|
|
|
|
// Dispatch "beforeinput" event after dispatching "cut" event.
|
|
|
|
nsresult rv = editActionData.MaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"MaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
|
|
|
// XXX This transaction name is referred by PlaceholderTransaction::Merge()
|
|
|
|
// so that we need to keep using it here.
|
|
|
|
AutoPlaceholderBatch treatAsOneTransaction(*this, *nsGkAtoms::DeleteTxnName);
|
|
|
|
rv = DeleteSelectionAsSubAction(eNone, eStrip);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::DeleteSelectionAsSubAction() failed, but ignored");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2019-07-29 06:21:42 +00:00
|
|
|
bool TextEditor::IsCutCommandEnabled() const {
|
2018-10-30 09:59:33 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eNotEditing);
|
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
2019-04-25 07:14:39 +00:00
|
|
|
return false;
|
2018-10-30 09:59:33 +00:00
|
|
|
}
|
|
|
|
|
2019-06-18 20:40:19 +00:00
|
|
|
// Cut is always enabled in HTML documents, but if the document is chrome,
|
|
|
|
// let it control it.
|
2019-04-25 07:14:39 +00:00
|
|
|
Document* document = GetDocument();
|
2019-06-18 20:40:19 +00:00
|
|
|
if (document && document->IsHTMLOrXHTML() &&
|
|
|
|
!nsContentUtils::IsChromeDoc(document)) {
|
2019-04-25 07:14:39 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-07-29 06:21:42 +00:00
|
|
|
return IsModifiable() && IsCopyToClipboardAllowedInternal();
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_IMETHODIMP TextEditor::Copy() {
|
2018-10-30 09:59:33 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eCopy);
|
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
2015-05-13 06:51:00 +00:00
|
|
|
bool actionTaken = false;
|
2015-09-08 14:33:34 +00:00
|
|
|
FireClipboardEvent(eCopy, nsIClipboard::kGlobalClipboard, &actionTaken);
|
2015-05-13 06:51:00 +00:00
|
|
|
|
2019-05-02 08:39:53 +00:00
|
|
|
return EditorBase::ToGenericNSResult(
|
|
|
|
actionTaken ? NS_OK : NS_ERROR_EDITOR_ACTION_CANCELED);
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2019-07-29 06:21:42 +00:00
|
|
|
bool TextEditor::IsCopyCommandEnabled() const {
|
2018-10-30 09:59:33 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eNotEditing);
|
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
2019-04-25 07:14:39 +00:00
|
|
|
return false;
|
2018-10-30 09:59:33 +00:00
|
|
|
}
|
|
|
|
|
2019-06-18 20:40:19 +00:00
|
|
|
// Copy is always enabled in HTML documents, but if the document is chrome,
|
|
|
|
// let it control it.
|
2019-04-25 07:14:39 +00:00
|
|
|
Document* document = GetDocument();
|
2019-06-18 20:40:19 +00:00
|
|
|
if (document && document->IsHTMLOrXHTML() &&
|
|
|
|
!nsContentUtils::IsChromeDoc(document)) {
|
2019-04-25 07:14:39 +00:00
|
|
|
return true;
|
2018-10-30 09:59:33 +00:00
|
|
|
}
|
|
|
|
|
2019-07-29 06:21:42 +00:00
|
|
|
return IsCopyToClipboardAllowedInternal();
|
2019-04-25 07:14:39 +00:00
|
|
|
}
|
|
|
|
|
2019-07-29 06:21:14 +00:00
|
|
|
bool TextEditor::CanDeleteSelection() const {
|
2018-10-30 09:59:33 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eNotEditing);
|
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
2019-04-25 07:14:39 +00:00
|
|
|
return false;
|
2018-10-30 09:59:33 +00:00
|
|
|
}
|
|
|
|
|
2019-07-29 06:21:14 +00:00
|
|
|
return IsModifiable() && !SelectionRefPtr()->IsCollapsed();
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2017-04-17 08:29:46 +00:00
|
|
|
already_AddRefed<nsIDocumentEncoder> TextEditor::GetAndInitDocEncoder(
|
2016-07-09 02:54:50 +00:00
|
|
|
const nsAString& aFormatType, uint32_t aDocumentEncoderFlags,
|
2018-07-18 11:51:55 +00:00
|
|
|
const nsACString& aCharset) const {
|
2018-10-30 10:04:08 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
2017-04-17 08:29:46 +00:00
|
|
|
nsCOMPtr<nsIDocumentEncoder> docEncoder;
|
|
|
|
if (!mCachedDocumentEncoder ||
|
|
|
|
!mCachedDocumentEncoderType.Equals(aFormatType)) {
|
2018-11-05 00:41:05 +00:00
|
|
|
nsAutoCString formatType;
|
2017-04-17 08:29:46 +00:00
|
|
|
LossyAppendUTF16toASCII(aFormatType, formatType);
|
2018-11-05 00:41:05 +00:00
|
|
|
docEncoder = do_createDocumentEncoder(PromiseFlatCString(formatType).get());
|
2017-04-17 08:29:46 +00:00
|
|
|
if (NS_WARN_IF(!docEncoder)) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
mCachedDocumentEncoder = docEncoder;
|
|
|
|
mCachedDocumentEncoderType = aFormatType;
|
|
|
|
} else {
|
|
|
|
docEncoder = mCachedDocumentEncoder;
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2019-01-02 13:05:23 +00:00
|
|
|
RefPtr<Document> doc = GetDocument();
|
2017-04-27 08:41:26 +00:00
|
|
|
NS_ASSERTION(doc, "Need a document");
|
2006-05-01 05:25:52 +00:00
|
|
|
|
2017-04-27 08:41:26 +00:00
|
|
|
nsresult rv = docEncoder->NativeInit(
|
|
|
|
doc, aFormatType,
|
2018-07-18 11:51:55 +00:00
|
|
|
aDocumentEncoderFlags | nsIDocumentEncoder::RequiresReinitAfterOutput);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("nsIDocumentEncoder::NativeInit() failed");
|
2017-04-17 08:29:46 +00:00
|
|
|
return nullptr;
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2012-02-01 10:54:22 +00:00
|
|
|
if (!aCharset.IsEmpty() && !aCharset.EqualsLiteral("null")) {
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored = docEncoder->SetCharset(aCharset);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsIDocumentEncoder::SetCharset() failed, but ignored");
|
2012-02-01 10:54:22 +00:00
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2019-09-23 11:43:59 +00:00
|
|
|
const int32_t wrapWidth = std::max(WrapWidth(), 0);
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored = docEncoder->SetWrapColumn(wrapWidth);
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsIDocumentEncoder::SetWrapColumn() failed, but ignored");
|
2001-01-28 20:13:07 +00:00
|
|
|
|
|
|
|
// Set the selection, if appropriate.
|
|
|
|
// We do this either if the OutputSelectionOnly flag is set,
|
|
|
|
// in which case we use our existing selection ...
|
2018-07-18 11:51:55 +00:00
|
|
|
if (aDocumentEncoderFlags & nsIDocumentEncoder::OutputSelectionOnly) {
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(docEncoder->SetSelection(SelectionRefPtr()))) {
|
|
|
|
NS_WARNING("nsIDocumentEncoder::SetSelection() failed");
|
2017-04-17 08:29:46 +00:00
|
|
|
return nullptr;
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
// ... or if the root element is not a body,
|
|
|
|
// in which case we set the selection to encompass the root.
|
2016-10-24 02:27:45 +00:00
|
|
|
else {
|
2012-02-01 10:54:22 +00:00
|
|
|
dom::Element* rootElement = GetRoot();
|
2017-04-17 08:29:46 +00:00
|
|
|
if (NS_WARN_IF(!rootElement)) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
2015-03-03 11:08:59 +00:00
|
|
|
if (!rootElement->IsHTMLElement(nsGkAtoms::body)) {
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(docEncoder->SetContainerNode(rootElement))) {
|
|
|
|
NS_WARNING("nsIDocumentEncoder::SetContainerNode() failed");
|
2017-04-17 08:29:46 +00:00
|
|
|
return nullptr;
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-17 08:29:46 +00:00
|
|
|
return docEncoder.forget();
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_IMETHODIMP TextEditor::OutputToString(const nsAString& aFormatType,
|
|
|
|
uint32_t aDocumentEncoderFlags,
|
|
|
|
nsAString& aOutputString) {
|
2018-10-30 09:59:33 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eNotEditing);
|
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
2019-02-25 09:07:54 +00:00
|
|
|
nsresult rv =
|
|
|
|
ComputeValueInternal(aFormatType, aDocumentEncoderFlags, aOutputString);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::ComputeValueInternal() failed");
|
2019-09-13 03:44:33 +00:00
|
|
|
// This is low level API for XUL application. So, we should return raw
|
|
|
|
// error code here.
|
|
|
|
return rv;
|
2018-07-18 12:27:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
nsresult TextEditor::ComputeValueInternal(const nsAString& aFormatType,
|
|
|
|
uint32_t aDocumentEncoderFlags,
|
|
|
|
nsAString& aOutputString) const {
|
2018-10-30 10:02:58 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
2019-09-13 03:44:33 +00:00
|
|
|
// First, let's try to get the value simply only from text node if the
|
|
|
|
// caller wants plaintext value.
|
|
|
|
if (aFormatType.LowerCaseEqualsLiteral("text/plain")) {
|
|
|
|
// If it's necessary to check selection range or the editor wraps hard,
|
|
|
|
// we need some complicated handling. In such case, we need to use the
|
|
|
|
// expensive path.
|
|
|
|
// XXX Anything else what we cannot return the text node data simply?
|
|
|
|
if (!(aDocumentEncoderFlags & (nsIDocumentEncoder::OutputSelectionOnly |
|
|
|
|
nsIDocumentEncoder::OutputWrap))) {
|
|
|
|
EditActionResult result =
|
|
|
|
ComputeValueFromTextNodeAndPaddingBRElement(aOutputString);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (result.Failed() || result.Canceled() || result.Handled()) {
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
result.Succeeded(),
|
|
|
|
"TextEditor::ComputeValueFromTextNodeAndPaddingBRElement() failed");
|
2019-09-13 03:44:33 +00:00
|
|
|
return result.Rv();
|
|
|
|
}
|
|
|
|
}
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2018-07-18 12:11:32 +00:00
|
|
|
nsAutoCString charset;
|
2019-09-13 03:44:33 +00:00
|
|
|
nsresult rv = GetDocumentCharsetInternal(charset);
|
2018-07-18 12:11:32 +00:00
|
|
|
if (NS_FAILED(rv) || charset.IsEmpty()) {
|
|
|
|
charset.AssignLiteral("windows-1252");
|
2016-10-24 02:27:45 +00:00
|
|
|
}
|
2001-07-14 00:50:21 +00:00
|
|
|
|
2017-04-17 08:29:46 +00:00
|
|
|
nsCOMPtr<nsIDocumentEncoder> encoder =
|
2018-07-18 12:27:30 +00:00
|
|
|
GetAndInitDocEncoder(aFormatType, aDocumentEncoderFlags, charset);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (!encoder) {
|
|
|
|
NS_WARNING("TextEditor::GetAndInitDocEncoder() failed");
|
2017-04-17 08:29:46 +00:00
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
2018-10-30 10:02:58 +00:00
|
|
|
rv = encoder->EncodeToString(aOutputString);
|
2019-09-13 03:44:33 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"nsIDocumentEncoder::EncodeToString() failed");
|
|
|
|
return rv;
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2018-10-10 12:05:39 +00:00
|
|
|
nsresult TextEditor::PasteAsQuotationAsAction(int32_t aClipboardType,
|
2019-06-10 10:27:07 +00:00
|
|
|
bool aDispatchPasteEvent,
|
|
|
|
nsIPrincipal* aPrincipal) {
|
2018-07-23 07:34:03 +00:00
|
|
|
MOZ_ASSERT(aClipboardType == nsIClipboard::kGlobalClipboard ||
|
|
|
|
aClipboardType == nsIClipboard::kSelectionClipboard);
|
|
|
|
|
2019-06-10 10:27:07 +00:00
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::ePasteAsQuotation,
|
|
|
|
aPrincipal);
|
2018-10-30 09:59:33 +00:00
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
2001-04-05 23:48:01 +00:00
|
|
|
// Get Clipboard Service
|
|
|
|
nsresult rv;
|
2018-07-23 07:34:03 +00:00
|
|
|
nsCOMPtr<nsIClipboard> clipboard =
|
|
|
|
do_GetService("@mozilla.org/widget/clipboard;1", &rv);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("Failed to get nsIClipboard service");
|
2018-07-23 07:34:03 +00:00
|
|
|
return rv;
|
|
|
|
}
|
2001-04-05 23:48:01 +00:00
|
|
|
|
2018-10-10 12:05:39 +00:00
|
|
|
// XXX Why don't we dispatch ePaste event here?
|
|
|
|
|
2013-01-04 20:33:09 +00:00
|
|
|
// Get the nsITransferable interface for getting the data from the clipboard
|
|
|
|
nsCOMPtr<nsITransferable> trans;
|
|
|
|
rv = PrepareTransferable(getter_AddRefs(trans));
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("TextEditor::PrepareTransferable() failed");
|
2019-02-25 09:07:54 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2018-07-23 07:34:03 +00:00
|
|
|
}
|
|
|
|
if (!trans) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
2014-08-08 04:52:05 +00:00
|
|
|
|
2018-07-23 07:34:03 +00:00
|
|
|
// Get the Data from the clipboard
|
|
|
|
clipboard->GetData(trans, aClipboardType);
|
|
|
|
|
|
|
|
// Now we ask the transferable for the data
|
|
|
|
// it still owns the data, we just have a pointer to it.
|
|
|
|
// If it can't support a "text" output of the data the call will fail
|
|
|
|
nsCOMPtr<nsISupports> genericDataObj;
|
|
|
|
nsAutoCString flav;
|
2018-11-02 11:02:25 +00:00
|
|
|
rv = trans->GetAnyTransferData(flav, getter_AddRefs(genericDataObj));
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("nsITransferable::GetAnyTransferData() failed");
|
2019-02-25 09:07:54 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2001-04-05 23:48:01 +00:00
|
|
|
}
|
|
|
|
|
2018-07-23 07:34:03 +00:00
|
|
|
if (!flav.EqualsLiteral(kUnicodeMime) &&
|
|
|
|
!flav.EqualsLiteral(kMozTextInternal)) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsCOMPtr<nsISupportsString> text = do_QueryInterface(genericDataObj);
|
|
|
|
if (!text) {
|
|
|
|
return NS_OK;
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 01:09:45 +00:00
|
|
|
}
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
|
|
|
|
nsString stuffToPaste;
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored = text->GetData(stuffToPaste);
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsISupportsString::GetData() failed, but ignored");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
if (stuffToPaste.IsEmpty()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
editActionData.SetData(stuffToPaste);
|
|
|
|
if (!stuffToPaste.IsEmpty()) {
|
|
|
|
nsContentUtils::PlatformToDOMLineBreaks(stuffToPaste);
|
|
|
|
}
|
|
|
|
rv = editActionData.MaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"MaybeDispatchBeforeInputEvent() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
|
|
|
|
|
|
|
AutoPlaceholderBatch treatAsOneTransaction(*this);
|
|
|
|
rv = InsertWithQuotationsAsSubAction(stuffToPaste);
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
2020-03-18 01:14:42 +00:00
|
|
|
"TextEditor::InsertWithQuotationsAsSubAction() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2001-04-05 23:48:01 +00:00
|
|
|
}
|
|
|
|
|
2018-07-23 07:05:30 +00:00
|
|
|
nsresult TextEditor::InsertWithQuotationsAsSubAction(
|
|
|
|
const nsAString& aQuotedText) {
|
2018-10-30 10:02:58 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
2020-03-19 13:18:16 +00:00
|
|
|
if (IsReadonly()) {
|
2019-09-17 02:47:26 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
2010-05-28 01:18:48 +00:00
|
|
|
|
2001-04-05 23:48:01 +00:00
|
|
|
// Let the citer quote it for us:
|
|
|
|
nsString quotedStuff;
|
2016-07-07 09:00:19 +00:00
|
|
|
nsresult rv = InternetCiter::GetCiteString(aQuotedText, quotedStuff);
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("InternetCiter::GetCiteString() failed");
|
2018-07-23 07:05:30 +00:00
|
|
|
return rv;
|
|
|
|
}
|
2001-04-05 23:48:01 +00:00
|
|
|
|
|
|
|
// It's best to put a blank line after the quoted text so that mails
|
|
|
|
// written without thinking won't be so ugly.
|
2016-10-24 02:27:45 +00:00
|
|
|
if (!aQuotedText.IsEmpty() && (aQuotedText.Last() != char16_t('\n'))) {
|
2014-01-04 15:02:17 +00:00
|
|
|
quotedStuff.Append(char16_t('\n'));
|
2016-10-24 02:27:45 +00:00
|
|
|
}
|
2001-04-05 23:48:01 +00:00
|
|
|
|
2019-09-18 03:01:28 +00:00
|
|
|
IgnoredErrorResult ignoredError;
|
2019-08-20 01:52:50 +00:00
|
|
|
AutoEditSubActionNotifier startToHandleEditSubAction(
|
2019-09-18 03:01:28 +00:00
|
|
|
*this, EditSubAction::eInsertText, nsIEditor::eNext, ignoredError);
|
|
|
|
if (NS_WARN_IF(ignoredError.ErrorCodeIs(NS_ERROR_EDITOR_DESTROYED))) {
|
|
|
|
return ignoredError.StealNSResult();
|
|
|
|
}
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
!ignoredError.Failed(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"TextEditor::OnStartToHandleTopLevelEditSubAction() failed, but ignored");
|
2001-04-05 23:48:01 +00:00
|
|
|
|
2019-09-17 02:47:26 +00:00
|
|
|
// XXX Do we need to support paste-as-quotation in password editor (and
|
|
|
|
// also in single line editor)?
|
|
|
|
MaybeDoAutoPasswordMasking();
|
|
|
|
|
|
|
|
rv = EnsureNoPaddingBRElementForEmptyEditor();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("EditorBase::EnsureNoPaddingBRElementForEmptyEditor() failed");
|
Bug 1463985 - part 1: Rename EditAction to EditSubAction and related stuff r=m_kato
When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
2018-05-28 11:12:34 +00:00
|
|
|
return rv;
|
|
|
|
}
|
2019-09-17 02:47:26 +00:00
|
|
|
|
2019-08-09 08:25:37 +00:00
|
|
|
rv = InsertTextAsSubAction(quotedStuff);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"EditorBase::InsertTextAsSubAction() failed");
|
2019-09-17 02:47:26 +00:00
|
|
|
return rv;
|
2001-04-05 23:48:01 +00:00
|
|
|
}
|
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
nsresult TextEditor::SharedOutputString(uint32_t aFlags, bool* aIsCollapsed,
|
2019-09-13 03:44:33 +00:00
|
|
|
nsAString& aResult) const {
|
2018-10-30 10:04:08 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
2003-07-28 13:13:50 +00:00
|
|
|
|
2018-10-30 10:04:08 +00:00
|
|
|
*aIsCollapsed = SelectionRefPtr()->IsCollapsed();
|
2003-07-28 13:13:50 +00:00
|
|
|
|
2016-10-24 02:27:45 +00:00
|
|
|
if (!*aIsCollapsed) {
|
2003-07-28 13:13:50 +00:00
|
|
|
aFlags |= nsIDocumentEncoder::OutputSelectionOnly;
|
2016-10-24 02:27:45 +00:00
|
|
|
}
|
2003-09-03 04:17:45 +00:00
|
|
|
// If the selection isn't collapsed, we'll use the whole document.
|
2019-09-13 03:44:33 +00:00
|
|
|
nsresult rv =
|
|
|
|
ComputeValueInternal(NS_LITERAL_STRING("text/plain"), aFlags, aResult);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::ComputeValueInternal(text/plain) failed");
|
2019-09-13 03:44:33 +00:00
|
|
|
return rv;
|
2003-07-28 13:13:50 +00:00
|
|
|
}
|
|
|
|
|
2018-10-30 10:01:38 +00:00
|
|
|
nsresult TextEditor::SelectEntireDocument() {
|
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
2019-09-17 06:58:06 +00:00
|
|
|
MOZ_ASSERT(!AsHTMLEditor());
|
2018-10-30 10:01:38 +00:00
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_WARN_IF(!mInitSucceeded)) {
|
2019-09-17 06:58:06 +00:00
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
2016-10-24 02:27:45 +00:00
|
|
|
}
|
2005-03-24 19:00:01 +00:00
|
|
|
|
2019-09-17 06:58:06 +00:00
|
|
|
Element* anonymousDivElement = GetRoot();
|
|
|
|
if (NS_WARN_IF(!anonymousDivElement)) {
|
2019-03-26 10:06:43 +00:00
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we're empty, don't select all children because that would select the
|
2019-08-02 05:44:40 +00:00
|
|
|
// padding <br> element for empty editor.
|
2019-09-17 06:58:06 +00:00
|
|
|
if (IsEmpty()) {
|
|
|
|
nsresult rv = SelectionRefPtr()->Collapse(anonymousDivElement, 0);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Selection::Collapse() failed");
|
2018-10-30 10:01:38 +00:00
|
|
|
return rv;
|
|
|
|
}
|
2011-05-25 20:30:14 +00:00
|
|
|
|
2019-09-17 06:58:06 +00:00
|
|
|
// XXX We just need to select all of first text node (if there is).
|
|
|
|
// Why do we do this kind of complicated things?
|
|
|
|
|
2011-05-25 20:30:14 +00:00
|
|
|
// Don't select the trailing BR node if we have one
|
2017-10-04 17:55:29 +00:00
|
|
|
nsCOMPtr<nsIContent> childNode;
|
2019-03-26 10:06:43 +00:00
|
|
|
nsresult rv = EditorBase::GetEndChildNode(*SelectionRefPtr(),
|
|
|
|
getter_AddRefs(childNode));
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("EditorBase::GetEndChildNode() failed");
|
2017-10-04 17:55:29 +00:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
if (childNode) {
|
|
|
|
childNode = childNode->GetPreviousSibling();
|
|
|
|
}
|
2011-05-25 20:30:14 +00:00
|
|
|
|
2019-08-02 05:45:18 +00:00
|
|
|
if (childNode && EditorBase::IsPaddingBRElementForEmptyLastLine(*childNode)) {
|
2019-03-26 10:06:43 +00:00
|
|
|
ErrorResult error;
|
|
|
|
MOZ_KnownLive(SelectionRefPtr())
|
2019-10-23 08:22:36 +00:00
|
|
|
->SetStartAndEndInLimiter(RawRangeBoundary(anonymousDivElement, 0u),
|
2019-03-26 10:06:43 +00:00
|
|
|
EditorRawDOMPoint(childNode), error);
|
|
|
|
NS_WARNING_ASSERTION(!error.Failed(),
|
2020-03-18 01:14:42 +00:00
|
|
|
"Selection::SetStartAndEndInLimiter() failed");
|
2019-03-26 10:06:43 +00:00
|
|
|
return error.StealNSResult();
|
2011-05-25 20:30:14 +00:00
|
|
|
}
|
|
|
|
|
2019-03-26 10:06:43 +00:00
|
|
|
ErrorResult error;
|
2019-09-17 06:58:06 +00:00
|
|
|
SelectionRefPtr()->SelectAllChildren(*anonymousDivElement, error);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(!error.Failed(),
|
|
|
|
"Selection::SelectAllChildren() failed");
|
2019-03-26 10:06:43 +00:00
|
|
|
return error.StealNSResult();
|
2001-01-28 20:13:07 +00:00
|
|
|
}
|
|
|
|
|
2020-04-13 01:43:41 +00:00
|
|
|
EventTarget* TextEditor::GetDOMEventTarget() const { return mEventTarget; }
|
2001-01-28 20:13:07 +00:00
|
|
|
|
2016-12-20 10:24:08 +00:00
|
|
|
nsresult TextEditor::SetAttributeOrEquivalent(Element* aElement,
|
2017-10-02 22:05:19 +00:00
|
|
|
nsAtom* aAttribute,
|
2016-07-09 02:54:50 +00:00
|
|
|
const nsAString& aValue,
|
|
|
|
bool aSuppressTransaction) {
|
2018-04-12 07:58:33 +00:00
|
|
|
if (NS_WARN_IF(!aElement) || NS_WARN_IF(!aAttribute)) {
|
|
|
|
return NS_ERROR_INVALID_ARG;
|
|
|
|
}
|
2018-10-30 09:59:33 +00:00
|
|
|
|
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eSetAttribute);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsresult rv = editActionData.CanHandleAndMaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"CanHandleAndMaybeDispatchBeforeInputEvent() failed");
|
2020-01-14 02:41:15 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
|
|
|
|
rv = SetAttributeWithTransaction(*aElement, *aAttribute, aValue);
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
2020-03-18 01:14:42 +00:00
|
|
|
"EditorBase::SetAttributeWithTransaction() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2002-03-15 15:33:29 +00:00
|
|
|
}
|
|
|
|
|
2016-12-20 10:24:08 +00:00
|
|
|
nsresult TextEditor::RemoveAttributeOrEquivalent(Element* aElement,
|
2017-10-02 22:05:19 +00:00
|
|
|
nsAtom* aAttribute,
|
2016-07-09 02:54:50 +00:00
|
|
|
bool aSuppressTransaction) {
|
2018-04-12 07:58:33 +00:00
|
|
|
if (NS_WARN_IF(!aElement) || NS_WARN_IF(!aAttribute)) {
|
|
|
|
return NS_ERROR_INVALID_ARG;
|
|
|
|
}
|
2018-10-30 09:59:33 +00:00
|
|
|
|
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eRemoveAttribute);
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
nsresult rv = editActionData.CanHandleAndMaybeDispatchBeforeInputEvent();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING_ASSERTION(rv == NS_ERROR_EDITOR_ACTION_CANCELED,
|
|
|
|
"CanHandleAndMaybeDispatchBeforeInputEvent() failed");
|
2020-01-14 02:41:15 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
|
|
|
|
rv = RemoveAttributeWithTransaction(*aElement, *aAttribute);
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
2020-03-18 01:14:42 +00:00
|
|
|
"EditorBase::RemoveAttributeWithTransaction() failed");
|
Bug 970802 - part 5: Make `AutoEditActionDataSetter` created method dispatch "beforeinput" event r=smaug,m_kato
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
2020-01-14 07:18:51 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
2002-01-09 13:51:37 +00:00
|
|
|
}
|
2016-07-09 02:54:50 +00:00
|
|
|
|
2019-08-09 10:19:11 +00:00
|
|
|
nsresult TextEditor::EnsurePaddingBRElementForEmptyEditor() {
|
2019-08-09 09:01:56 +00:00
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
MOZ_ASSERT(!AsHTMLEditor());
|
|
|
|
|
|
|
|
// If there is padding <br> element for empty editor, we have no work to do.
|
|
|
|
if (mPaddingBRElementForEmptyEditor) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Likewise, nothing to be done if we could never have inserted a trailing
|
|
|
|
// <br> element.
|
|
|
|
// XXX Why don't we use same path for <textarea> and <input>?
|
|
|
|
if (IsSingleLineEditor()) {
|
2019-08-09 10:19:11 +00:00
|
|
|
nsresult rv = MaybeCreatePaddingBRElementForEmptyEditor();
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
2020-03-18 01:14:42 +00:00
|
|
|
"EditorBase::MaybeCreatePaddingBRElementForEmptyEditor() failed");
|
2019-08-09 10:19:11 +00:00
|
|
|
return rv;
|
2019-08-09 09:01:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (NS_WARN_IF(!mRootElement)) {
|
|
|
|
return NS_ERROR_FAILURE;
|
|
|
|
}
|
|
|
|
|
2019-08-09 10:19:11 +00:00
|
|
|
uint32_t childCount = mRootElement->GetChildCount();
|
|
|
|
if (childCount == 0) {
|
|
|
|
nsresult rv = MaybeCreatePaddingBRElementForEmptyEditor();
|
|
|
|
NS_WARNING_ASSERTION(
|
|
|
|
NS_SUCCEEDED(rv),
|
2020-03-18 01:14:42 +00:00
|
|
|
"EditorBase::MaybeCreatePaddingBRElementForEmptyEditor() failed");
|
2019-08-09 10:19:11 +00:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (childCount > 1) {
|
2019-08-09 09:01:56 +00:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
RefPtr<HTMLBRElement> brElement =
|
|
|
|
HTMLBRElement::FromNodeOrNull(mRootElement->GetFirstChild());
|
|
|
|
if (!brElement ||
|
|
|
|
!EditorBase::IsPaddingBRElementForEmptyLastLine(*brElement)) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Rather than deleting this node from the DOM tree we should instead
|
|
|
|
// morph this <br> element into the padding <br> element for editor.
|
|
|
|
mPaddingBRElementForEmptyEditor = std::move(brElement);
|
|
|
|
mPaddingBRElementForEmptyEditor->UnsetFlags(NS_PADDING_FOR_EMPTY_LAST_LINE);
|
|
|
|
mPaddingBRElementForEmptyEditor->SetFlags(NS_PADDING_FOR_EMPTY_EDITOR);
|
|
|
|
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2019-07-22 03:53:36 +00:00
|
|
|
nsresult TextEditor::SetUnmaskRangeInternal(uint32_t aStart, uint32_t aLength,
|
|
|
|
uint32_t aTimeout, bool aNotify,
|
|
|
|
bool aForceStartMasking) {
|
|
|
|
mIsMaskingPassword = aForceStartMasking || aTimeout != 0;
|
|
|
|
|
|
|
|
// We cannot manage multiple unmasked ranges so that shrink the previous
|
|
|
|
// range first.
|
|
|
|
if (!IsAllMasked()) {
|
|
|
|
mUnmaskedLength = 0;
|
|
|
|
if (mMaskTimer) {
|
|
|
|
mMaskTimer->Cancel();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we're not a password editor, return error since this call does not
|
|
|
|
// make sense.
|
|
|
|
if (!IsPasswordEditor()) {
|
|
|
|
if (mMaskTimer) {
|
|
|
|
mMaskTimer = nullptr;
|
|
|
|
}
|
|
|
|
return NS_ERROR_NOT_AVAILABLE;
|
|
|
|
}
|
|
|
|
|
|
|
|
Element* rootElement = GetRoot();
|
|
|
|
if (NS_WARN_IF(!rootElement)) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
2019-07-22 03:56:33 +00:00
|
|
|
Text* text = Text::FromNodeOrNull(rootElement->GetFirstChild());
|
|
|
|
if (!text) {
|
2019-07-22 03:53:36 +00:00
|
|
|
// There is no anonymous text node in the editor.
|
2019-07-29 06:30:50 +00:00
|
|
|
return aStart > 0 && aStart != UINT32_MAX ? NS_ERROR_INVALID_ARG : NS_OK;
|
2019-07-22 03:53:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (aStart < UINT32_MAX) {
|
2019-07-22 03:56:33 +00:00
|
|
|
uint32_t valueLength = text->Length();
|
2019-07-22 03:53:36 +00:00
|
|
|
if (aStart >= valueLength) {
|
|
|
|
return NS_ERROR_INVALID_ARG; // There is no character can be masked.
|
|
|
|
}
|
2019-07-22 03:56:33 +00:00
|
|
|
// If aStart is middle of a surrogate pair, expand it to include the
|
|
|
|
// preceding high surrogate because the caller may want to show a
|
|
|
|
// character before the character at `aStart + 1`.
|
|
|
|
const nsTextFragment* textFragment = text->GetText();
|
2019-08-06 05:43:21 +00:00
|
|
|
if (textFragment->IsLowSurrogateFollowingHighSurrogateAt(aStart)) {
|
2019-07-22 03:56:33 +00:00
|
|
|
mUnmaskedStart = aStart - 1;
|
|
|
|
// If caller collapses the range, keep it. Otherwise, expand the length.
|
|
|
|
if (aLength > 0) {
|
|
|
|
++aLength;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
mUnmaskedStart = aStart;
|
|
|
|
}
|
2019-07-22 03:53:36 +00:00
|
|
|
mUnmaskedLength = std::min(valueLength - mUnmaskedStart, aLength);
|
2019-07-22 03:56:33 +00:00
|
|
|
// If unmasked end is middle of a surrogate pair, expand it to include
|
|
|
|
// the following low surrogate because the caller may want to show a
|
|
|
|
// character after the character at `aStart + aLength`.
|
2019-08-06 05:43:21 +00:00
|
|
|
if (UnmaskedEnd() < valueLength &&
|
|
|
|
textFragment->IsLowSurrogateFollowingHighSurrogateAt(UnmaskedEnd())) {
|
2019-07-22 03:56:33 +00:00
|
|
|
++mUnmaskedLength;
|
|
|
|
}
|
2019-07-22 03:53:36 +00:00
|
|
|
// If it's first time to mask the unmasking characters with timer, create
|
|
|
|
// the timer now. Then, we'll keep using it for saving the creation cost.
|
|
|
|
if (!mMaskTimer && aLength && aTimeout && mUnmaskedLength) {
|
|
|
|
mMaskTimer = NS_NewTimer();
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (NS_WARN_IF(aLength != 0)) {
|
|
|
|
return NS_ERROR_INVALID_ARG;
|
|
|
|
}
|
|
|
|
mUnmaskedStart = UINT32_MAX;
|
|
|
|
mUnmaskedLength = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Notify nsTextFrame of this update if the caller wants this to do it.
|
|
|
|
// Only in this case, script may run.
|
|
|
|
if (aNotify) {
|
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
|
|
|
RefPtr<Document> document = GetDocument();
|
|
|
|
if (NS_WARN_IF(!document)) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
// Notify nsTextFrame of masking range change.
|
2020-01-17 10:00:28 +00:00
|
|
|
if (RefPtr<PresShell> presShell = document->GetObservingPresShell()) {
|
|
|
|
nsAutoScriptBlocker blockRunningScript;
|
2019-07-22 03:56:33 +00:00
|
|
|
uint32_t valueLength = text->Length();
|
|
|
|
CharacterDataChangeInfo changeInfo = {false, 0, valueLength, valueLength,
|
|
|
|
nullptr};
|
|
|
|
presShell->CharacterDataChanged(text, changeInfo);
|
2019-07-22 03:53:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Scroll caret into the view since masking or unmasking character may
|
|
|
|
// move caret to outside of the view.
|
2019-11-07 02:59:51 +00:00
|
|
|
nsresult rv = ScrollSelectionFocusIntoView();
|
2020-03-18 01:14:42 +00:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
NS_WARNING("EditorBase::ScrollSelectionFocusIntoView() failed");
|
2019-11-07 02:59:51 +00:00
|
|
|
return rv;
|
2019-07-22 03:53:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!IsAllMasked() && aTimeout != 0) {
|
|
|
|
// Initialize the timer to mask the range automatically.
|
|
|
|
MOZ_ASSERT(mMaskTimer);
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
mMaskTimer->InitWithCallback(this, aTimeout, nsITimer::TYPE_ONE_SHOT);
|
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsITimer::InitWithCallback() failed, but ignored");
|
2019-07-22 03:53:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2019-07-22 03:55:13 +00:00
|
|
|
// static
|
|
|
|
char16_t TextEditor::PasswordMask() {
|
|
|
|
char16_t ret = LookAndFeel::GetPasswordCharacter();
|
|
|
|
if (!ret) {
|
|
|
|
ret = '*';
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
MOZ_CAN_RUN_SCRIPT_BOUNDARY NS_IMETHODIMP TextEditor::Notify(nsITimer* aTimer) {
|
2019-07-22 03:53:36 +00:00
|
|
|
// Check whether our text editor's password flag was changed before this
|
|
|
|
// "hide password character" timer actually fires.
|
|
|
|
if (!IsPasswordEditor()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IsAllMasked()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
AutoEditActionDataSetter editActionData(*this, EditAction::eHidePassword);
|
|
|
|
if (NS_WARN_IF(!editActionData.CanHandle())) {
|
|
|
|
return NS_ERROR_NOT_INITIALIZED;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Mask all characters.
|
|
|
|
nsresult rv = MaskAllCharactersAndNotify();
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::MaskAllCharactersAndNotify() failed");
|
2019-07-22 03:55:13 +00:00
|
|
|
|
|
|
|
if (StaticPrefs::editor_password_testing_mask_delay()) {
|
|
|
|
if (RefPtr<Element> target = GetInputEventTargetElement()) {
|
|
|
|
RefPtr<Document> document = target->OwnerDoc();
|
2020-03-18 01:14:42 +00:00
|
|
|
DebugOnly<nsresult> rvIgnored = nsContentUtils::DispatchTrustedEvent(
|
2019-07-22 03:55:13 +00:00
|
|
|
document, target, NS_LITERAL_STRING("MozLastInputMasked"),
|
|
|
|
CanBubble::eYes, Cancelable::eNo);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"nsContentUtils::DispatchTrustedEvent("
|
|
|
|
"MozLastInputMasked) failed, but ignored");
|
2019-07-22 03:55:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-07-22 03:53:36 +00:00
|
|
|
return EditorBase::ToGenericNSResult(rv);
|
|
|
|
}
|
|
|
|
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_IMETHODIMP TextEditor::GetName(nsACString& aName) {
|
2019-07-22 03:53:36 +00:00
|
|
|
aName.AssignLiteral("TextEditor");
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
void TextEditor::WillDeleteText(uint32_t aCurrentLength,
|
|
|
|
uint32_t aRemoveStartOffset,
|
|
|
|
uint32_t aRemoveLength) {
|
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
|
|
|
if (!IsPasswordEditor() || IsAllMasked()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Adjust unmasked range before deletion since DOM mutation may cause
|
|
|
|
// layout referring the range in old text.
|
|
|
|
|
|
|
|
// If we need to mask automatically, mask all now.
|
|
|
|
if (mIsMaskingPassword) {
|
|
|
|
DebugOnly<nsresult> rvIgnored = MaskAllCharacters();
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"TextEditor::MaskAllCharacters() failed, but ignored");
|
2019-07-22 03:53:36 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (aRemoveStartOffset < mUnmaskedStart) {
|
|
|
|
// If removing range is before the unmasked range, move it.
|
|
|
|
if (aRemoveStartOffset + aRemoveLength <= mUnmaskedStart) {
|
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
SetUnmaskRange(mUnmaskedStart - aRemoveLength, mUnmaskedLength);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"TextEditor::SetUnmaskRange() failed, but ignored");
|
2019-07-22 03:53:36 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If removing range starts before unmasked range, and ends in unmasked
|
|
|
|
// range, move and shrink the range.
|
|
|
|
if (aRemoveStartOffset + aRemoveLength < UnmaskedEnd()) {
|
|
|
|
uint32_t unmaskedLengthInRemovingRange =
|
|
|
|
aRemoveStartOffset + aRemoveLength - mUnmaskedStart;
|
|
|
|
DebugOnly<nsresult> rvIgnored = SetUnmaskRange(
|
|
|
|
aRemoveStartOffset, mUnmaskedLength - unmaskedLengthInRemovingRange);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"TextEditor::SetUnmaskRange() failed, but ignored");
|
2019-07-22 03:53:36 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If removing range includes all unmasked range, collapse it to the
|
|
|
|
// remove offset.
|
|
|
|
DebugOnly<nsresult> rvIgnored = SetUnmaskRange(aRemoveStartOffset, 0);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"TextEditor::SetUnmaskRange() failed, but ignored");
|
2019-07-22 03:53:36 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (aRemoveStartOffset < UnmaskedEnd()) {
|
|
|
|
// If removing range is in unmasked range, shrink the range.
|
|
|
|
if (aRemoveStartOffset + aRemoveLength <= UnmaskedEnd()) {
|
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
SetUnmaskRange(mUnmaskedStart, mUnmaskedLength - aRemoveLength);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"TextEditor::SetUnmaskRange() failed, but ignored");
|
2019-07-22 03:53:36 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If removing range starts from unmasked range, and ends after it,
|
|
|
|
// shrink it.
|
|
|
|
DebugOnly<nsresult> rvIgnored =
|
|
|
|
SetUnmaskRange(mUnmaskedStart, aRemoveStartOffset - mUnmaskedStart);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rvIgnored),
|
|
|
|
"TextEditor::SetUnmaskRange() failed, but ignored");
|
2019-07-22 03:53:36 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If removing range is after the unmasked range, keep it.
|
|
|
|
}
|
|
|
|
|
|
|
|
nsresult TextEditor::DidInsertText(uint32_t aNewLength,
|
|
|
|
uint32_t aInsertedOffset,
|
|
|
|
uint32_t aInsertedLength) {
|
|
|
|
MOZ_ASSERT(IsEditActionDataAvailable());
|
|
|
|
|
|
|
|
if (!IsPasswordEditor() || IsAllMasked()) {
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mIsMaskingPassword) {
|
|
|
|
// If we need to mask password, mask all right now.
|
|
|
|
nsresult rv = MaskAllCharactersAndNotify();
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::MaskAllCharacters() failed");
|
2019-07-22 03:53:36 +00:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (aInsertedOffset < mUnmaskedStart) {
|
|
|
|
// If insertion point is before unmasked range, expand the unmasked range
|
|
|
|
// to include the new text.
|
|
|
|
nsresult rv = SetUnmaskRangeAndNotify(
|
|
|
|
aInsertedOffset, UnmaskedEnd() + aInsertedLength - aInsertedOffset);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::SetUnmaskRangeAndNotify() failed");
|
2019-07-22 03:53:36 +00:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (aInsertedOffset <= UnmaskedEnd()) {
|
|
|
|
// If insertion point is in unmasked range, unmask new text.
|
|
|
|
nsresult rv = SetUnmaskRangeAndNotify(mUnmaskedStart,
|
|
|
|
mUnmaskedLength + aInsertedLength);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::SetUnmaskRangeAndNotify() failed");
|
2019-07-22 03:53:36 +00:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If insertion point is after unmasked range, extend the unmask range to
|
|
|
|
// include the new text.
|
|
|
|
nsresult rv = SetUnmaskRangeAndNotify(
|
|
|
|
mUnmaskedStart, aInsertedOffset + aInsertedLength - mUnmaskedStart);
|
2020-03-18 01:14:42 +00:00
|
|
|
NS_WARNING_ASSERTION(NS_SUCCEEDED(rv),
|
|
|
|
"TextEditor::SetUnmaskRangeAndNotify() failed");
|
2019-07-22 03:53:36 +00:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
2016-07-09 02:54:50 +00:00
|
|
|
} // namespace mozilla
|