Use parsed atoms to store popovertarget attributes as more effective mechanism to search for ID match in attr associated elements implementation. Followup from D173337.
Differential Revision: https://phabricator.services.mozilla.com/D174786
The idea is that chrome code would be able to call preventDefault(),
then run primary password authentication when needed, then setRevealPassword
again.
Differential Revision: https://phabricator.services.mozilla.com/D173491
Convert the various capture* constants in nsIFilePicker into a proper
enum, and perform validation when passing it across IPC.
Additionally, unlike the previous two enums, reduce the size of
CaptureTarget to 8 bits. This is a workaround for its use with
nsAttrValue, which at present very specifically requires that parseable
enums' values fit within an `int16_t` -- and a `uint16_t` does not.
Differential Revision: https://phabricator.services.mozilla.com/D169854
Convert the various mode* constants in nsIFilePicker into a proper
enum, and perform validation when passing it across IPC.
Differential Revision: https://phabricator.services.mozilla.com/D169853
Convert the various result* constants in nsIFilePicker into a proper
enum, and perform validation when passing it across IPC.
Differential Revision: https://phabricator.services.mozilla.com/D169852
First, the test compares `document.querySelector(":active")` and a checkbox or
a radio button. However, Gecko activates ancestor elements too. Therefore,
Gecko returns `<html>` element or `null` for the selector. However, this is
an issue of CSS pseudo class compatibility which is **not** scope of the test.
Therefore, this patch makes it compare `document.querySelector("input:active")`
and a checkbox or a radio button instead.
Next, Gecko does not activate checkboxes and radio buttons when user presses
the space key, but the other browsers do it. Therefore, this patch makes
`HTMLInputElement::PostHandleEvent` do it and
`EventStateManager::PostHandleEvent` clear it at `keyup` of the space key.
Next, Gecko does not inactive active elements when it gets lost focus.
Therefore, this patch makes `nsFocusManager::NotifyFocusStateChange` do it
like the other browsers.
Finally, with manual testing of draft patches, I found some issues of
inactivating them when they are activated by `<label>`s. Therefore, I add new
tests in a separate file. Note that Chrome fails only in the cases testing
`<input type="radio">` with `<label>`.
Differential Revision: https://phabricator.services.mozilla.com/D160494
Seems somewhat reasonable to do this, if we wanted to, since
nsFocusManager also makes these always match :focus-visible.
If you think it's worth doing I can add a test quite trivially.
Differential Revision: https://phabricator.services.mozilla.com/D158186
This matches Chrome and Safari. Also add a test for FileList being
shareable between DataTransfer and input, which seems to be in the
intention of the spec and matches our pre-existing behavior, the
behavior of input-to-input FileList handling, and Safari, but not
Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D152367
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
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
We have similar code for range inputs. This matches Blink (but not
WebKit), but I think it's a better default.
The spec seems to leave this up to UAs, so for now landing a
moz-specific WPT. Should be trivial to upstream if we want.
Depends on D141705
Differential Revision: https://phabricator.services.mozilla.com/D141706
