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 test uses `synthesizeDrop()` etc. However, the testing data does not match
with actual data when users do same thing in some cases. Therefore, we should
rewrite it with `synthesizePlainDragAndDrop()`.
Differential Revision: https://phabricator.services.mozilla.com/D57426
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
In a follow-up commit a new `ComparePoints` method with cleaner
arguments and return value will be added.
Differential Revision: https://phabricator.services.mozilla.com/D55295
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
`HTMLEditor::NodeIsBlockStatic` and `nsHTMLElement::IsBlock` doesn't check whether element is real `Element`. So we should add more check whether element or not.
Differential Revision: https://phabricator.services.mozilla.com/D56684
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--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
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
Starting from bug 1597679, `HTMLTextAreaElement::GetValueInternal()` stops
converting `\r\n` and `\r` with `\n` because it may be in hot path and the scan
cost of `\r` in `nsContentUtils::PlatformToDOMLineBreaks()` is redundant in
most cases.
However, there are still some paths to input `\r`. This patch makes them
call `nsContentUtils::PlatformToDOMLineBreaks()` if they have not done it.
Differential Revision: https://phabricator.services.mozilla.com/D54906
--HG--
extra : moz-landing-system : lando
The initialization cost of `AutoStyleCacheArray` is still expensive and it's
used only by `HTMLEditor`. Therefore, we should make it `Maybe` and construct
it only when the editor is an `HTMLEditor`.
Depends on D54253
Differential Revision: https://phabricator.services.mozilla.com/D54254
--HG--
extra : moz-landing-system : lando
Calling `AppendElement()` a lot causes the constructor appearing in profile.
`AutoTArray` has a constructor taking initialization list. Let's use it.
Differential Revision: https://phabricator.services.mozilla.com/D54253
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
The initialization cost of `AutoStyleCacheArray` is still expensive and it's
used only by `HTMLEditor`. Therefore, we should make it `Maybe` and construct
it only when the editor is an `HTMLEditor`.
Depends on D54253
Differential Revision: https://phabricator.services.mozilla.com/D54254
--HG--
extra : moz-landing-system : lando
Calling `AppendElement()` a lot causes the constructor appearing in profile.
`AutoTArray` has a constructor taking initialization list. Let's use it.
Differential Revision: https://phabricator.services.mozilla.com/D54253
--HG--
extra : moz-landing-system : lando
This is a regression by bug 1568996. Although editor uses nsFrameSelection to
move caret, if frame is dirty, nsFrameSelection returns error.
So by bug 1568996, we flush layout before calling nsFrameSelection. But we
should stop flushing layout when we don't use nsFrameSelection.
Differential Revision: https://phabricator.services.mozilla.com/D53919
--HG--
extra : moz-landing-system : lando
After removing all mutation event listeners, the corresponding method
still returns `true`, so the new name is more accurate.
Differential Revision: https://phabricator.services.mozilla.com/D52342
--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
Currently, "input" event is fired when the `AutoScriptBlocker` in `SetValue()`
is deleted. So, for keeping same behavior, the post processing after calling
`TextEditor` methods should be done before editor dispatches "input" event.
Fortunately, `TextInputListener::OnEditActionHandled()` is a good chance to
do that. Therefore, this patch makes it notify `TextControlState` and
`AutoTextControlHandlingState`.
Note that ideally, each method of `TextEditor` should return
`NS_ERROR_OUT_OF_MEMORY` coming from
`AutoTextControlHandlingState::OnEditActionHandled()`. However, it requires
a lot of changes in editor classes, and the case is really rare since editor
does not use fallible allocation. Therefore, it must be okay to crash in
editor if `OnEditActionHandled()` returns `NS_ERROR_OUT_OF_MEMORY`.
Depends on D51395
Differential Revision: https://phabricator.services.mozilla.com/D51396
--HG--
extra : moz-landing-system : lando
Makoto Kato
Emma Malysz
Masayuki Nakano
Chris Peterson
Mirko Brodesser
Csoregi Natalia
Kris Maglione
shindli
Noemi Erli
Daniel Varga
Gabriele Svelto
Julian Descottes
Emilio Cobos Álvarez
Sylvestre Ledru
jeffin143
Coroiu Cristina
Cosmin Sabou
Hiroyuki Ikezoe
Sebastian Hengst
Edgar Chen