`HTMLEditor::DeleteSelectionWithTransaction()` calls `EditorBase`'s overridden
method and handles `nsIEditor::eStrip` case. Therefore, we can rename it with
stop calling the `EditorBase::DeleteSelectionWithTransaction()`, and make it
called by `EditorBase::DeleteSelectionWithTransaction()` only when it's
necessary.
Additionally, we can make all internal method callers of editor classes always
set `nsIEditor::eNoStrip` if the instance is `TextEditor`. This must make
the code easier to understand.
Depends on D72292
Differential Revision: https://phabricator.services.mozilla.com/D72293
`DeleteSelection*()` are members of `TextEditor`, but they are also used by
`HTMLEditor`. Therefore, they and pref cache members for them should be
in `EditorBase` too.
Depends on D71911
Differential Revision: https://phabricator.services.mozilla.com/D72290
In most cases, `InputEvent.getTargetRange()` of `beforeinput` event should
return `Selection` ranges at dispatching the event.
This patch also handles special cases.
* composition change - target range should be the previous composition string
which will be replaced with new composition string.
* replace text - target range should be the replace range. This is used by
spellchecker.
* drop - target range should be the drop point.
However, the other exception is not handled by this patch. That is, deletions.
The target range(s) should be the range(s) which will be removed. In most
cases, they also matches selection ranges, but may be extended to:
* surrogate pair boundary
* grapheme cluster boundary like complex emoji
* word/line deletion deletion
* `Backspace` or `Delete` from collapsed selection
* to end of unnecessary whitespaces
For supporting these cases, we need to separate
`HTMLEditor::HandleDeleteSelection()` and its helper methods and helper class
to range computation part and modifying the DOM tree part. Of course, it
requires big changes and `InputEvent.getTargetRanges()` may be important for
feature detection of `beforeinput` event so that we should put off the big
changes to bug 1618457.
Differential Revision: https://phabricator.services.mozilla.com/D64730
--HG--
extra : moz-landing-system : lando
Currently, it checks whether proper element gets focus as expected with
`nsFocusManager::GetFocusedElement()`, but it returns globally focused element.
I.e., it may return different document's element or `nullptr` if application
itself is inactive.
The purpose of the focus check is, `HTMLEditor` can modify contents only in
active editing host. Therefore, comparing with
`HTMLEditor::GetActiveEditingHost()` is better and simpler for here.
Differential Revision: https://phabricator.services.mozilla.com/D63581
--HG--
extra : moz-landing-system : lando
`UIEvent::GetRangeParent()` retrieves `nsIContent` instance but it needs to
return `already_AddRefed<nsINode>` because of a WebIDL method. However,
`nsIContent` is better type in C++ code. Therefore, this patch renames it
to `UIEvent::GetRangeParentContent()` and makes new `UIEvent::GetRangeParent()`
and just call it.
Additionally, some callers call `UIEvent::RangeOffset()` too, but that means
that they compute same things twice because both of them use
`nsLayoutUtils::GetContainerAndOffsetAtEvent()` with same input arguments.
Thus, `UIEvent::GetRangeParentContent()` should also return offset with optional
out argument. (Note that this does not make `RangeOffset()` use
`GetRangeParentContent()` because using out parameter for range parent causes
unnecessary computation cost for `RangeOffset()`.)
Therefore, finally, `UIEvent::GetRangeParentContent()` becomes also an alias of
raw method `UIEvent::GetRangeParentContentAndOffset()` which also returns offset
with out argument.
Differential Revision: https://phabricator.services.mozilla.com/D60095
--HG--
extra : moz-landing-system : lando
`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
`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
User can move DnD between different 2 editors. Then, deleting selection in
drag source editor should be handled by the drag source editor rather than
drop target editor. Therefore, `TextEditor::OnDrop()` should look for
editor instance for drag source node and call is "deleteByDrag" handler.
Differential Revision: https://phabricator.services.mozilla.com/D57449
--HG--
extra : moz-landing-system : lando
Chrome moves focus to dropped element or editing host containing dropped
element, but we don't do it. For compatibility with Chrome, it's better to
follow their behavior. Additionally, this fixes 2 issues. One is, when
dropping something into non-focused contenteditable element, we've failed to
initialize selection from `TextEditor::PrepareToInsertContent()` because
`pointToInsert` is outside of selection limiter if another editing host
has focus. The other is, when same case, we've failed to insert dropped
content because edit action handlers of `HTMLEditor` check whether editing
position is in active editing host.
Finally, this patch makes `TextEditor::OnDrop()` cancels to dispatch "input"
event if it fails something before trying to insert dropped content. Without
this change, `EditorBase::DispatchInputEvent()` tries to dispatch without
proper `data` or `dataTransfer` and that hits `MOZ_ASSERT` in `nsContentUtils`.
Additionally, this fixes an existing bug which `HTMLEditor` may insert `\r`
as-is if it comes from paste or drop. Otherwise, we need complicated `todo_is`
paths in `test_dragdrop.html`.
Differential Revision: https://phabricator.services.mozilla.com/D57447
--HG--
extra : moz-landing-system : lando
Currently, any default drop effect is "move" on editable content even when
the editor cannot remove the source element (e.g., outside of any editing host).
The drop effect is initialized by `nsContentUtils::SetDataTransferInEvent()`
which is called when `EditorEventListener::CanDrop()` and it returns true.
However, it requires unnecessary cost if we make `nsContentUtils` check
whether the dragging element is removable. Therefore, we should make
`EditorEventListener` overwrites it with checking whether the source node is
editable or not.
Differential Revision: https://phabricator.services.mozilla.com/D57446
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
With making it take `WidgetKeyboardEvent*`, it won't need to return "handled"
state. However, when we implement `beforeinput` event, it needs to return
"canceled" state. Therefore, it should return `EditActionResult`.
Differential Revision: https://phabricator.services.mozilla.com/D51953
--HG--
extra : moz-landing-system : lando
`TextEditor::DeleteSelectionAsSubAction()` starts to handle all
"delete selection" sub-actions (i.e., even if the instance is `HTMLEditor`).
Therefore, `TextEditRules::WillDeleteSelection()` should be renamed to
`TextEditor::HandleDeleteSelection()` and we need to make it virtual.
Differential Revision: https://phabricator.services.mozilla.com/D45300
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
For content HTML/XHTML copy/paste should always be enabled, but for chrome
docs we can support enabling/disabling copy/paste.
Also, restores tests to how they were before copy/paste was always enabled.
Differential Revision: https://phabricator.services.mozilla.com/D34805
--HG--
extra : moz-landing-system : lando
`Document::ExecCommand()` knows subject principal. This patch makes it tell
`EditorCommand::DoCommand()` and `EditorCommand::DoCommandParam()`. Then,
makes they tell each editor public methods which may cause dispatching
`beforeinput` event once we implement it. Finally, each editor public
method sets it to the constructor of `EditorBase::AutoEditActionDataSetter`.
This means that when editor tries to dispatch `beforeinput` event, editor
can check whether it's called by JS or not from everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D29635
--HG--
extra : moz-landing-system : lando
This patch makes editors return new error code internally when clipboard event
is dispatched and canceled by script. This is for making each caller stop
handling the edit action. However, it's not actual failure. Therefore, making
public methods return `NS_SUCCESS_DOM_NO_OPERATION` instead via
`EditorBase::ToGenericNSResult()`.
Differential Revision: https://phabricator.services.mozilla.com/D28935
--HG--
extra : moz-landing-system : lando
`CanCut()`, `CanCopy()` and `CanPaste()` return error only when the editor has
already been destroyed or not been initialized yet, or when failed to access
clipboard when the document is not HTML/XHTML.
`CanDelete()` returns error only when the editor has already been destroyed or
not been initialized yet.
So, these error result won't be exposed to the web in most cases and such
exception shouldn't stop any content script because Chrome basically does not
throw exception in such situation as far as I know.
Therefore, there should be overloads of them to return `bool` result directly
for making their callers simpler.
Differential Revision: https://phabricator.services.mozilla.com/D28608
--HG--
extra : moz-landing-system : lando
As far as I've tested, Chrome does not throw exception even when editor is
destroyed or editor content is modified unexpectedly. So, we should return
`NS_OK` from most public methods of editor when internal methods return
`NS_ERROR_EDITOR_DESTROYED` or `NS_ERROR_EDITOR_UNEXPECTED_DOM_TREE`.
Differential Revision: https://phabricator.services.mozilla.com/D20811
--HG--
extra : moz-landing-system : lando
InputEvent.dataTransfer should be set to non-null when InputEvent.inputType
is "insertFromPaste", "insertFromDrop" or "insertReplacementText" and
editor is an HTMLEditor instance:
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
("insertTranspose" and "insertFromYank" are not currently supported on Gecko.)
This patch makes nsContentUtils::DispatchInputEvent() take dataTransfer value
and EditorBase set it via AutoEditActionDataSetter like data value.
However, we need to create other constructors of DataTransfer to create its
read-only instances initialized with nsITransferable or nsAString. This will
be implemented by the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D19297
--HG--
extra : moz-landing-system : lando
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://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
This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Turn all const lists and related attributes into cenums, to provide a
vague sense of type safety.
Depends on D11715
Differential Revision: https://phabricator.services.mozilla.com/D11716
--HG--
extra : moz-landing-system : lando
Similar to EditorBase::mSavedSel, we can move EditorBase::mRangeUpdater too
because of it's referred only when there is AutoEditActionDataSetter instance
so that it also does not need to be in the cycle collection.
And now, it can be marked as MOZ_STACK_CLASS and remove cycle collection
support.
Differential Revision: https://phabricator.services.mozilla.com/D12402
--HG--
extra : moz-landing-system : lando
Both Chrome and Safari dispatches 2 sets of "beforeinput" and "input" events
when user drag and drop content in same editor. One is "deleteByDrag" and
the other is "insertFromDrop". We need to follow same behavior since
it should be able to cancel only "deleteByDrag" or "insertFromDrop" when
we implement "beforeinput" event.
HTMLEditor::InsertObject() may handle asynchronously. And we don't need to
do anything additionally for HTMLEditor. Therefore, TextEditor::OnDrop()
can delete selection before inserting dropped content by itself.
Therefore, this patch makes TextEditor::OnDrop() call
TextEditor::PrepareToInsertContent() and EditorBase::FireInputEvent() by
itself.
Unfortunately, it seems that we cannot write automated tests for this.
Even if using synthesizeMouse() of EventUtils, synthesizing mouse events
won't generate "dragover" nor "drop" events. Perhaps, like EventUtils.js,
we need to do something with drag service, but it means that we cannot
emulate drag and drop in an editor.
Differential Revision: https://phabricator.services.mozilla.com/D11285
--HG--
extra : moz-landing-system : lando
Only TextEditor::InsertTextAt() and HTMLEditor::DoInsertHTMLWithContext()
removes selected content before pasting from clipboard or inserting dropped
content, and they do same things. Therefore, they can share the code with
a helper method.
Note that this makes each root caller won't return NS_ERROR_EDITOR_DESTROYED
since the destruction is expected by web app.
Differential Revision: https://phabricator.services.mozilla.com/D11284
--HG--
extra : moz-landing-system : lando
TextEditor::OnDrop() calls TextEditor::InsertFromDataTransfer() or
HTMLEditor::InsertFromDataTransfer() and they are called only by
TextEditor::OnDrop().
TextEditor::InsertFromDataTransfer() calls only TextEditor::InsertTextAt()
and TextEditor::InsertTextAt() calls only TextEditor::InsertTextAsSubAction() if
insertion point is nullptr. Therefore, if the callers sets nullptr, they
should call TextEditor::InsertTextAsSubAction() directly. Then, we can
make TextEditor::InsertTextAt() require non-nullptr insertion point.
HTMLEditor::InsertFromDataTransfer() calls HTMLEditor::InsertObject(),
HTMLEditor::DoInsertHTMLWithContext() or TextEditor::InsertTextAt().
HTMLEditor::InsertObject() calls HTMLEditor::DoInsertHTMLWithContext()
directly or via BlobReader (in this case, calls asynchronously).
Unfortunately both HTMLEditor::InsertObject() and
HTMLEditor::DoInsertHTMLWithContext() are called by
HTMLEditor::InsertFromTransferable() which is paste event handler. Therefore,
we cannot make them require non-nullptr insertion point, though, anyway,
they cannot become simpler even if we could do that.
This patch marks them as MOZ_CAN_RUN_SCRIPT as far as possible and
makes them take |const EditorDOMPoint&| for insertion point.
Differential Revision: https://phabricator.services.mozilla.com/D11283
--HG--
extra : moz-landing-system : lando
Now, any protected/private methods of editor classes can refer
SelectionRefPtr() safely. So, we can cut the cost of calling GetSelection()
only once per edit action handling.
Differential Revision: https://phabricator.services.mozilla.com/D10011
--HG--
extra : moz-landing-system : lando
AutoTransactionBatch, AutoPlaceholderBatch, AutoSelectionRestorer,
AutoTopLevelEditSubActionNotifier, AutoTransactionsConserveSelection and
AutoUpdateViewBatch access protected members of EditorBase. The access
scope management assume that they are used only by EditorBase or its
subclasses or TextEditRules or its inherited class (i.e., HTMLEditRules).
For guaranteeing this at build-time, we should change them to nested classes
of EditorBase. Then, EditorBase and its subclasses and friends can use them.
Differential Revision: https://phabricator.services.mozilla.com/D9479
--HG--
extra : moz-landing-system : lando
Kagami Sascha Rosylight
Mirko Brodesser
Botond Ballo
Masayuki Nakano
Razvan Maries
Tetsuharu OHZEKI
Gabriele Svelto
Kannan Vijayan
Brendan Dahl
Ciure Andrei
Narcis Beleuzu
Boris Zbarsky
Emilio Cobos Álvarez
Sylvestre Ledru
Kyle Machulis
Tom Schuster
Csoregi Natalia