It's a rather useless interface:
* nsITextControlFrame is only implemented by nsTextControlFrame, so we
can just use that.
* nsIFormControlFrame had very few actual functionality, mostly
scattered around:
* SetFormProperty(select) was only useful for nsTextControlFrame.
* SetFormProperty(value) was only called on file controls.
* SetFocus() did mostly nothing, or things that can be done in
ElementStateChanged instead.
There are some do_QueryFrame calls that I replaced for better checks in
font inflation and nsIFrame, but I'll adjust to preserve behavior if you
insist (it just such a somewhat-random check).
Differential Revision: https://phabricator.services.mozilla.com/D217322
This commit is a prerequisite for part 5 of this patch set.
This flag is set in the docshell, based on `user gesture activation`.
This is not necessarily sufficient,
as the text fragments spec bases the value of
this flag also on User Involvement, which is not
implemented in Gecko yet.
The flag is then plumbed through the parent process
(`DocumentLoadListener::CreateDocumentLoadInfo()`)
to the document, where it can be consumed.
This includes client-side redirects as described in [0].
There is no changed behavior in this commit.
[0] https://wicg.github.io/scroll-to-text-fragment/#restricting-the-text-fragment
Differential Revision: https://phabricator.services.mozilla.com/D212817
This commit is a prerequisite for part 5 of this patch set.
This flag is set in the docshell, based on `user gesture activation`.
This is not necessarily sufficient,
as the text fragments spec bases the value of
this flag also on User Involvement, which is not
implemented in Gecko yet.
The flag is then plumbed through the parent process
(`DocumentLoadListener::CreateDocumentLoadInfo()`)
to the document, where it can be consumed.
This includes client-side redirects as described in [0].
There is no changed behavior in this commit.
[0] https://wicg.github.io/scroll-to-text-fragment/#restricting-the-text-fragment
Differential Revision: https://phabricator.services.mozilla.com/D212817
Much like BindToTree.
This will be useful because I need to pass more information through
UnbindFromTree() to speed up dir=auto for bug 1874040.
Differential Revision: https://phabricator.services.mozilla.com/D202215
Having a base class with a single static member doesn't buy us much, and
actually MSVC-compatible compilers don't optimize empty base classes out
(plus the empty base is at the end so it might even take space on Linux
and macOS, untested).
Just put the values in Element.h / Element.cpp which is the common base
class of the relevant elements.
Differential Revision: https://phabricator.services.mozilla.com/D200825
Add a RAII helper to notify of multiple state changes together for
these.
The UpdateState CustomElementInternals calls that are getting removed
are unnecessary (the state should be up-to-date by then, there's nothing
changing there particularly).
Same for the call in nsGenericHTMLFormElement::UnbindFromTree. ClearForm
already does an state update.
Differential Revision: https://phabricator.services.mozilla.com/D187033
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
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
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
