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
When closing window / documnet, if content modifies an element that has
contenteditable via unload event, it hits assertion in
`nsDocShell::EnsureEditorData` due to destroying document. So we should
return error before getting editing session.
Differential Revision: https://phabricator.services.mozilla.com/D50573
--HG--
extra : moz-landing-system : lando
This seems to go back to our initial contenteditable implementation, and I don't
think there's a reason <label> should work differently from anything else.
Differential Revision: https://phabricator.services.mozilla.com/D46929
--HG--
extra : moz-landing-system : lando
`uint32_t`, because `nsRange::ComparePoints` requires it -- by webidl
interface -- to be unsigned long.
Moreover it makes `RangeBoundaryBase`'s interface cleaner, because it
already exposes the offset as a `uint32_t`.
Differential Revision: https://phabricator.services.mozilla.com/D50054
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
I intend to enable still more mochitests in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D49524
--HG--
extra : moz-landing-system : lando
* Make about:networking work on mobile
* I used the aboutMemory.css file as a guide for doing this
* The mobile CSS does not include the common.css, since that doesn't seem to work. But at least now the interfaces is functional. We should make it look nice in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D49582
--HG--
extra : moz-landing-system : lando
When inserting `<li>` elements into `<ul>`, `<ol>` or `<li>` element,
`HTMLEditor::DoInsertHTMLWithContext()` removes unnecessary empty `<li>`
elements at insertion point. At this time, we've computed next insertion
point with removed `<li>` element. Therefore, insertion point goes out
from the DOM tree. This patch makes it compute new insertion point before
removing each empty `<li>` element.
Additionally, this patch adds some WPT data for testing this case. I verified
that Chrome passes the new tests too.
Differential Revision: https://phabricator.services.mozilla.com/D49394
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
Finally, `Document.execCommand()` still does not work fine if selection
starts from very start of block and/or end at very end of block because
`PromoteInlineRange()` extends selection range to contain the
containers, then, `SubtreeContentIterator` won't list up text nodes.
In this case, `RemoveInlinePropertyInternal()` expects that
`RemoveStyleInside()` removes text node style with creating
`<span>` elements. However, `RemoveStyleInsilde()` only handles
`Element`s and it handles elements from most-descendants.
Therefore, it cannot distinguish whether text node style comes
from removing inline elements or parent block.
This patch makes `RemoveInlinePropertyInternal()` collect
descendant text nodes in the range after handling all nodes in
the range except descendant text nodes, then, check the
final style of descendant text nodes, finally, remove the style
if coming from parent block.
Differential Revision: https://phabricator.services.mozilla.com/D47865
--HG--
extra : moz-landing-system : lando
If selection range is not in **one** text node, `RemoveInlinePropertyInternal()`
collects target nodes with `SubtreeContentIterator`. It only collects topmost
nodes which are **entirely** contained in the range (it's enough because their
descendants will be handled by `RemoveStyleInside()` recursively).
The reasons why it uses `SubtreeContentIterator` rather than
`PreContentIterator` must be:
1. Performance reason.
2. Assuming there are no multiple text nodes.
3. Not expects that user removes text node styles come from parent block.
The reason 2 is wrong because when removing a style, all browsers don't
join text nodes which was in removing element with adjacent text nodes.
(I.e., we cannot change this behavior for compatibility.)
The reason 3 is of course wrong we're struggling with this scenario.
Therefore, `RemoveInlinePropertyInternal()` needs to collect partially
selected text nodes by itself (if there are). Then, we can merge the
single text node selected case with the `for` loop.
Differential Revision: https://phabricator.services.mozilla.com/D47864
--HG--
extra : moz-landing-system : lando
For compatibility with Chrome, when removing inline style at block parent,
we should reset the style with creating `<span>` element whose `style`
attribute removes the style. We do this only in CSS mode, but we should do
it in HTML mode too.
This patch also makes `FontFaceStateCommand::SetState()` ignore `tt` value
if its root caller is `Document::ExecCommand()`. It was implemented for
composer to handle XUL command in bug 115922. Therefore, we should not do
this special handling on the web. If it were possible to separate this
change to another bug, it'd be nicer. But without this change, we'll have
a lot of regressions of `Document.execCommand("fontname")`. Therefore,
this is also fixed in this patch.
Note that this removes first `.ini` file selection because
the tests cannot be run without test number range parameter.
So, the sections are not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47862
--HG--
extra : moz-landing-system : lando
For compatibility with Chrome, when removing inline style at block parent,
we should reset the style with creating `<span>` element whose `style`
attribute removes the style. We do this only in CSS mode, but we should do
it in HTML mode too.
This patch also makes `FontFaceStateCommand::SetState()` ignore `tt` value
if its root caller is `Document::ExecCommand()`. It was implemented for
composer to handle XUL command in bug 115922. Therefore, we should not do
this special handling on the web. If it were possible to separate this
change to another bug, it'd be nicer. But without this change, we'll have
a lot of regressions of `Document.execCommand("fontname")`. Therefore,
this is also fixed in this patch.
Note that this removes first `.ini` file selection because
the tests cannot be run without test number range parameter.
So, the sections are not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D47862
--HG--
extra : moz-landing-system : lando
Surprisingly, its `aChildOnly` is never set to `true` and if it were set to
`true`, it does unnecessary recursive calls. Therefore, we can make it
simpler.
Differential Revision: https://phabricator.services.mozilla.com/D47860
--HG--
extra : moz-landing-system : lando
This is related to bug 1530649. When using <span> element with contentedtiable,
we won't insert <br> element at last. When Korean IME on macOS commits
composition by space key, composition string has space.
Gekco removes U+0020 space when it is last character into editing host. To keep
whitespace, we have to replace with NBSP when it is last.
Differential Revision: https://phabricator.services.mozilla.com/D48146
--HG--
extra : moz-landing-system : lando
Both method take a DOM point with `nsCOMPtr<nsINode>*` and `int32_t*`.
This makes each caller complicated. Instead, we should use stack only class
to return both `EditorDOMPoint` and `nsresult`. I name it `EditResult`.
Additionally, this fixes a bug of `HTMLeditor::SplitStyleAboveRange()`. That
is not tracking new selection start point while it splits elements at end
of given range. This is detected by the debug assertion in
`ToRawRangeBoundary()` (i.e., this fix is required to pass some tests).
Differential Revision: https://phabricator.services.mozilla.com/D47858
--HG--
extra : moz-landing-system : lando
