Now that we have UTF8String in the WebIDL, we can remove quite a few of the
conversions. Do that, and lift the remaining string conversions up as needed.
Also deindent Servo_ComputeColor while touching it.
Most of the remaining copies are because either bug 1606994, or because they're
WebIDL attributes that we still need to serialize back as UTF-16 (bug 1606995).
Differential Revision: https://phabricator.services.mozilla.com/D58687
--HG--
extra : moz-landing-system : lando
In particular, the ones where we transcode unconditionally atm (property names
and such).
There are others like cssText getters and setters which are a bit harder,
because I either need to rewrite all our serialization code to work with UTF8
(which is fine, but a lot of work), or teach webidl to have a setter that takes
UTF8String as input but returns DOMString as output (which is at best hacky).
Differential Revision: https://phabricator.services.mozilla.com/D58631
--HG--
extra : moz-landing-system : lando
test_password_per_word_operation.html uses magic number to consider
click point in `<input>` element. However, that causes permanent
failure on Ubuntu 18.04. Ideally, the click positions should be
computed dynamically. Therefore, this patch makes it use rect of
anonymous `<div>` element and rect of its child text node which can
be computed with `Range.getBoundingClientRect()`.
Differential Revision: https://phabricator.services.mozilla.com/D58193
--HG--
extra : moz-landing-system : lando
Most tests which use these APIs don't want to distinguish difference of
linebreaks (i.e., CRLF vs. CR vs. LF). And also most tests don't want to
check prefix and postfix of HTML data in clipboard on Windows.
Therefore, this patch makes them compare clipboard data with expected string
smarter. Every linebreak in clipboard data are treated as LF. Expected
HTML data is wrapped with `<html>`, `<body>` and comment nodes only on
Windows at comparing with clipboard data.
Differential Revision: https://phabricator.services.mozilla.com/D57963
--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 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
