`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
It's used only by password field, i.e., only by `TextEditor`, and used
temporarily. Additionally, there is some space in `TextEditor`. So, we
can get rid of it, and make `TextEditor` store it directly.
Note that this allows to skip expensive `nsIEditor::SetFlags()` calls by
`AutoRestoreEditorState`. This may improve setting `<input>.value` performance.
Differential Revision: https://phabricator.services.mozilla.com/D118266
With the previous patch, we know `nsIEditor::eEditorWidgetMask` always
matches with `EditorBase::IsTextEditor()`. And it's not referred from JS
(including comm-central and BlueGriffon). So, we can get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D118262
They are used by setting text value of `TextEditor` or replacing a misspelled
word with a new word in both `TextEditor` and `HTMLEditor`. Therefore,
they should be in the `EditorBase` rather than `TextEditor`.
Note that the path of the former case may be in a hot path. Therefore, we need
to keep redirecting to `TextEditor` for keeping the performance only in the
case.
Depends on D115785
Differential Revision: https://phabricator.services.mozilla.com/D115786
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
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
SetSelectionRange may kill the frame (in the test-case, AccessibleCaret
flushes layout).
No crashtest as there doesn't seem to be one available.
Differential Revision: https://phabricator.services.mozilla.com/D101253
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
No need to special case here as both already use cached selection. This makes it consistent with SetSelectionStart etc.
Differential Revision: https://phabricator.services.mozilla.com/D98185
No need to special case here as both already use cached selection. This makes it consistent with SetSelectionStart etc.
Differential Revision: https://phabricator.services.mozilla.com/D98185
Blink and WebKit do not fire `beforeinput` event when user uses build-in
password manager and autocomplete. But the `inputType` value for this case,
`"insertReplacementText"` is defined as cancelable in the spec, and it's
actually cancelable when it's fired for correcting a word with built-in
spellchecker of them.
For making only our users' autocomplete and password manager not blocked by
web apps, we should make them not cancelable by default, but I think that we
should keep dispatching such non-cancelable `beforeinput` for conforming to
the standard unless we'd get a web-compat report for this.
Differential Revision: https://phabricator.services.mozilla.com/D93206
This is mostly a revert of the patch in bug 1425686 that removed the old
probe, but rebased to new code locations and clang-formatted. The histogram
entry is also updated with new bug numbers and fields.
The next patch will refine some of these telemetry recording points; the patch
is split into two for easier reviewing as this part is basically what landed
originally.
Differential Revision: https://phabricator.services.mozilla.com/D92995
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
