The submission from requestSubmit() call is non-deferred due to
mDeferSubmission
being cleared in HTMLFormElement::PostHandleEvent when handling a submit
event. The
mDeferSubmission clearing is also to make the submission from the default
action
of a submit button non-deferred.
This patch makes the submission from default action of a submit button
deferred
which could fix this bug, and also simplify the logic a bit.
Since gecko would also trigger submission for untrusted submit event,
see
bug 1370630, we need to handle that case specially.
Differential Revision: https://phabricator.services.mozilla.com/D170941
ParseAttribute ideally would be const (see bug 1829138), but the SVG and
SMIL code is rather messy. Still, now that BeforeSetAttr can't really
fail, swapping the order of ParseAttribute and BeforeSetAttr shouldn't
really change behavior.
Sorry for the extra `virtual` keyword removal and such. I had to do this
one by hand unlike the dependent bugs, and I went a bit drive-by, lmk if
you want me to split those changes.
Differential Revision: https://phabricator.services.mozilla.com/D176086
Same rg + sed shenanigans as the first patch.
There were two that could fail, both due to OOM:
* HTMLInputElement::AfterSetAttr: If we fail (only in the type=range
case) we end up with an old value without it being clamped by
min/max/step.
* HTMLBodyElement::AfterSetAttr: If we fail we won't peek up the
DocShell's frame margins and styling could be incorrect.
That seems better than having to deal with broken states after we've
already set the attribute.
Depends on D176069
Differential Revision: https://phabricator.services.mozilla.com/D176070
rg BeforeSetAttr -l | xargs sed -i 's/nsresult BeforeSetAttr/void BeforeSetAttr/g'
rg ::BeforeSetAttr -l | xargs sed -i 's/nsresult \(.*\)::BeforeSetAttr/void \1::BeforeSetAttr/g'
Plus trivial fixes, plus clang-format.
The only meaningful changes are in nsXULElement::BeforeSetAttr. Two
things could fail:
chromemargin: I removed it because we don't use the parsed attribute any
other place than here:
https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/dom/xul/ChromeObserver.cpp#136
And that deals just fine with it not being parsed.
usercontextid: We have a debug assertion that we don't dynamically change it.
I kept it but I don't think it's worth failing to set the attribute on release for that
Differential Revision: https://phabricator.services.mozilla.com/D176069
The C++ code change here is simply replacing an ifdef with a pref-check (and
associated reindentation for being placed in an "if"-block).
The pref is off-by-default for now, since no other browser seems to modify
these fields through mousewheel scrolling, and users seem to be surprised when
they encounter the behavior in Firefox. See discussion on the bugzilla page.
Note: now that this behavior is controlled by a pref, we don't need to have
platform-specific #ifdefs and "skip-if" test exemptions. If we decide to bring
this behavior back on certain platforms, we can do so by simply changing the
default value of the pref on those platforms.
Differential Revision: https://phabricator.services.mozilla.com/D175719
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
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
Adam Vandolder