This and "value changed" affect the "too long" and "too short" validity
states.
The validity state tracking code is quite messy...
Differential Revision: https://phabricator.services.mozilla.com/D111254
This patch adds two events - `DOMFormRemoved` and `DOMInputPasswordRemoved`.
These events are notified when a form/password field is removed from
the DOM tree. When the LoginManagerChild receives the event, it calls
_onFormSubmit as the form is submitted.
This patch also adds a WeakFieldSet formlessModifiedPasswordFields to
record all the form-less password fields that users have interacted
with to track whether a formless password is removed
Depends on D106024
Differential Revision: https://phabricator.services.mozilla.com/D106025
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
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
They're enabled in all configurations and there's no plan to change
this. With it, dom.experimental_forms is also useless, so we can remove
it too.
Differential Revision: https://phabricator.services.mozilla.com/D87623
URLBarInput relies on it being non-null when created, but that may not
happen if we construct frames lazily without this patch.
Differential Revision: https://phabricator.services.mozilla.com/D74891
`inputmode` attribute controls software keyboard layout like `<input type>`.
Originally this was by B2G (bug 746142) and for `<input>` element only.
WHATWG spec allows this attribute for HTML element and WebKit and Blink have
already implemented this.
Differential Revision: https://phabricator.services.mozilla.com/D69348
This restores our previous behavior with the new <input type=number>
implementation (see the changes in test_input_number_l10n.html, which undoes the
changes of the regressing bug), and adds a test that shows that we display the
localized value properly.
Differential Revision: https://phabricator.services.mozilla.com/D66822
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
If `TextControlState` does not have `TextEditor` and its `SetValue()` is called
from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput`
event.
If the value is modified by `beforeinput` event listener, it's intended that
`preventDefault()` is called by the web apps. However, the behavior in this
case is not mentioned by UI Events nor Input Events spec. We should just file
a spec issue instead of emulating Chrome's behavior for now because it requires
more changes, but this case must be an edge case.
The spec issue is: https://github.com/w3c/input-events/issues/106
Differential Revision: https://phabricator.services.mozilla.com/D58126
If `TextControlState` does not have `TextEditor` and its `SetValue()` is called
from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput`
event.
If the value is modified by `beforeinput` event listener, it's intended that
`preventDefault()` is called by the web apps. However, the behavior in this
case is not mentioned by UI Events nor Input Events spec. We should just file
a spec issue instead of emulating Chrome's behavior for now because it requires
more changes, but this case must be an edge case.
The spec issue is: https://github.com/w3c/input-events/issues/106
Differential Revision: https://phabricator.services.mozilla.com/D58126
