Bug 1776896 happened because we have manual code to cleanup every member
for reuse. Instead, reuse the individual block of memory and use the
destructor to clean up.
Differential Revision: https://phabricator.services.mozilla.com/D150489
One unfortunate-ish thing of storing it in TextControlState is that we
can't preserve it across type changes, but that seems ok for now
according to my conversations with Serg.
In the future we might want to move the value to HTMLInputElement itself
or something, we'll see, but this should help folks fix some
long-standing quality issues in the password manager / autofill
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D150148
`TextControlState` is alive during reframing, but `TextEditor` is not so.
Therefore, `TextControlState` should take the `PasswordMaskData` before
`TextEditor` is destroyed. And if `TextEditor` is recreated, and the value
hasn't been modified, unmasked range should be restored in the new editor.
Depends on D118757
Differential Revision: https://phabricator.services.mozilla.com/D118758
During a `TextControlState` alive, `PasswordMaskData` should be alive too.
Otherwise, we cannot keep unmasked range at reframing.
Depends on D118756
Differential Revision: https://phabricator.services.mozilla.com/D118757
Capping selection range in SetValue early makes the subsequent SetSelectionRange call unable to detect actual selection range change. This patch defers it so that select events can be consistently fired.
Differential Revision: https://phabricator.services.mozilla.com/D115729
Should be much simpler and doesn't need to deal with the different
stuff. We already have pseudo-classes for this, :autofill and
:placeholder-shown.
I initially wrote this because this is the only limitation that forces
us to have the placeholder text as a direct child of the text control
frame. In the end I kept that as-is, but this simplification is still
worth it.
We remove dom.placeholder.show_on_focus because it doesn't behave
correctly (it doesn't match the :placeholder-shown pseudo-class and it
should). It was introduced in bug 807613 and never turned to false by
default. I suspect nobody will miss this, but if somebody complains
about it we can reintroduce it properly (handling the pref in DOM
instead, changing the right state bits).
Differential Revision: https://phabricator.services.mozilla.com/D108304
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
The [[nodiscard]] attribute must precede a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute does not have this order restriction.
Differential Revision: https://phabricator.services.mozilla.com/D107355
Cloning a textarea element without a dirty value flag does not call SetValue() and thus gets no max length. This makes sure it always gets one before setting selection range.
Differential Revision: https://phabricator.services.mozilla.com/D99734
This is intended to be a hotfix for the URL bar regression. Ideally there should be a spec or this behavior should be removed completely.
Previously select() scrolled back to the start position before the regression, but this fix does not restore that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D98972
Using integer as a bit field may cause simple mistake and may not be easy
to read, and we have `EnumSet` class which can treat an `enum class` as
a bit flags so that we should make it an `enum class` and use it with the
`EnumSet` class.
Differential Revision: https://phabricator.services.mozilla.com/D99172
This is intended to be a hotfix for the URL bar regression. Ideally there should be a spec or this behavior should be removed completely.
Previously select() scrolled back to the start position before the regression, but this fix does not restore that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D98972
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
I thought this would fix <input type=number style="user-select: none">, but
turns out it doesn't.
<input type=number> doesn't have the editor root as a root of the anonymous
subtree, so the current hack wouldn't work, as the anon root wouldn't have the
editable flag. So tweak the code a bit to handle stuff in a simpler way than
setting the flags after the fact, and set the NAC-root flag earlier to avoid
the mOuterWrapper->AppendChildTo(root) call forgetting about root's flags.
I had to tweak one AccessibleCaret test, but that's because it uses <textarea>
with user-select: none, and our behavior there is not particularly sane. It just
happened to work because that test-case also had a bunch of contenteditable
elements, and we stop matching this rule:
https://searchfox.org/mozilla-central/rev/220a3bd6063fcbe5ca50e88dcabdc7dee0aca448/layout/style/contenteditable.css#22
Because the anonymous div now properly matches :-moz-read-write, which made the
rule apply and the test work. See comment 4 of this bug.
I'll fix this stuff up and add some tests for our behavior here in bug 1611699.
I refactored the dragdrop tests to cover more input types, but I ended up not
being able to use them because they're dependent on the content.
Instead I added an extra test and changed the refactor so that it applies to
<input type=search>, as there's layout work going on in bug 558594, and it'd be
unfortunate to regress this there too.
Differential Revision: https://phabricator.services.mozilla.com/D61094
--HG--
extra : moz-landing-system : lando
For preparing to remove `nsIPlaintextEditor` interface, this patch moves
all of them to `nsIEditor`, but for avoiding bustage in comm-central, makes
`nsIPlaintextEditor` inherit `nsIEditor` for now (i.e., even with this patch,
script can access old `nsIPlaintextEditor` members with the interface.
In C++ code, this patch moves `SetWrapColumn()`, `InsertTextAsAction()`,
`InsertTextAsSubAction()` and `InsertLineBreakAsSubAction()` because
they do common things between `TextEditor` and `HTMLEditor`. On the other
hand, this does not move `TextEditor::GetTextLength()` because it's designed
only for `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D60820
--HG--
rename : editor/libeditor/tests/test_nsIPlaintextEditor_insertLineBreak.html => editor/libeditor/tests/test_nsIEditor_insertLineBreak.html
extra : moz-landing-system : lando
Note that `TextControlState::BindToFrame()` may also run script if it's
called without script blocker. However, it shouldn't occur. Therefore,
we don't need to mark it `MOZ_CAN_RUN_SCRIPT`, but we should check
script blocker existence with `MOZ_ASSERT`.
Differential Revision: https://phabricator.services.mozilla.com/D55776
--HG--
extra : moz-landing-system : lando
If `PreareEditor()` returns `NS_OK`, but if the instance is deleted at returning
from it, `GetTextEditor()` will access `mTextEditor`. Therefore, this patch
makes `PrepareEditor()` return error if the instance is destroyed at its end.
Differential Revision: https://phabricator.services.mozilla.com/D55775
--HG--
extra : moz-landing-system : lando
Similar to the previous patch, it may notify selection listeners of native
anonymous tree in `<input>` and `<textarea>` element.
Differential Revision: https://phabricator.services.mozilla.com/D55774
--HG--
extra : moz-landing-system : lando
They are really complicated and can run script while the instance is being
destroyed. Therefore, they should have their own `AutoTextControlHandlingState`
as "kungFuDeathGrip".
Differential Revision: https://phabricator.services.mozilla.com/D55773
--HG--
extra : moz-landing-system : lando
The destructor of `AutoTextControlHandlingState`is marked as
`MOZ_CAN_RUN_SCRIPT`, but it's not checked at build time. And this does not
need to be created when the method does not run script. Therefore, we should
mark its constructor as `MOZ_CAN_RUN_SCRIPT` instead since it's stack only
class so that its constructor and destructor are always called from same
method.
Differential Revision: https://phabricator.services.mozilla.com/D55772
--HG--
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--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
Previously, we cache only one `TextControlState` instance to reuse. However,
`HTMLTextAreaElement` also started to allocate it in the heap rather than
a part of its instance. Therefore, we should have more room to cache the
instances for saving the allocation cost.
Differential Revision: https://phabricator.services.mozilla.com/D54326
--HG--
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--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
Previously, we cache only one `TextControlState` instance to reuse. However,
`HTMLTextAreaElement` also started to allocate it in the heap rather than
a part of its instance. Therefore, we should have more room to cache the
instances for saving the allocation cost.
Differential Revision: https://phabricator.services.mozilla.com/D54326
--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
`TextControlState::SetValue()` does 4 things.
1. Committing composition if there is and if possible.
2. Setting value with `TextEditor` if text editor and frame are available.
3. Setting value without `TextEditor` otherwise.
4. Notifying value changed.
We can split #2 and #3 from it now because `AutoTextControlHandlingState`
manages nested actions. Therefore, this patch creates
`SetValueWithTextEditor()` and `SetValueWithoutTextEditor()` which take
`AutoTextControlHandlingState`.
Depends on D51394
Differential Revision: https://phabricator.services.mozilla.com/D51395
--HG--
extra : moz-landing-system : lando
Currently, only `HTMLInputElement` reuses `TextControlState` instance since
`HTMLTextAreaElement` had the instance as a member rather than allocate it.
Now, all instances are allocated in the heap independently for guaranteeing
their lifetime. So, the reuse mechanism should be managed by
`TextControlState` itself.
Depends on D51393
Differential Revision: https://phabricator.services.mozilla.com/D51394
--HG--
extra : moz-landing-system : lando
Currently, nobody guarantees that `TextControlState` won't be deleted while
it handles something with `MOZ_CAN_RUN_SCRIPT` methods.
This patch hides its destructor (and constructor) for making only
`TextControlState` itself can delete its instances. Then, if instance owner
wants to delete it while handling action(s), the oldest `AutoHandlingState`
will delete the `TextControlState`.
Depends on D51392
Differential Revision: https://phabricator.services.mozilla.com/D51393
--HG--
extra : moz-landing-system : lando
Some members of `TextControlState` are initialized and restored in same block
scopes. Therefore, with creating new stack only class and storing latest one
with a new member variable, we can store all of them in the stack.
Depends on D51391
Differential Revision: https://phabricator.services.mozilla.com/D51392
--HG--
extra : moz-landing-system : lando
It should be in `mozilla` namespace and it manages not only `TextEditor`,
manages selection, selection controller and callback from editor. so that
I think it stores state of "text control widget". Therefore, I name it to
`TextControlState`.
And cleaning up the cpp file.
Differential Revision: https://phabricator.services.mozilla.com/D51391
--HG--
rename : dom/html/nsTextEditorState.cpp => dom/html/TextControlState.cpp
rename : dom/html/nsTextEditorState.h => dom/html/TextControlState.h
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Masayuki Nakano
Kagami Sascha Rosylight
Chris Peterson
Butkovits Atila
Bogdan Tara
Mihai Alexandru Michis
Simon Giesecke
Coroiu Cristina