The original implementations contain unnecessary branches and operate on
double values. The new implementations, based on [1], are branch free on
x86_64 and mostly use integer arithmetic.
All tests pass and, in addition, [2] contains an exhaustive test that checks
all required dates, that is, in [-8.64e15 / msPerDay, 8.64e15 / msPerDay]
(as per ES5 15.9.1.1).
[1] Neri C, Schneider L., "Euclidean affine functions and their
application to calendar algorithms."
Softw Pract Exper. 2023;53(4):937-970. doi: 10.1002/spe.3172
https://onlinelibrary.wiley.com/doi/full/10.1002/spe.3172
[2] https://godbolt.org/z/oPvxzY6vx
Differential Revision: https://phabricator.services.mozilla.com/D175569
This avoids a lot of useless time on things like GetValueAsDecimal(),
where we get the default value as a string, parse it as a number for
sanitization reasons, localize it to a string, just to parse it back to
a number.
Differential Revision: https://phabricator.services.mozilla.com/D183284
It is always called from TextControlState, and always ends up in
TextControlState::ValueEquals, so we can avoid some indirection and just
use that.
Depends on D183282
Differential Revision: https://phabricator.services.mozilla.com/D183283
It was introduced in bug 206859, but the `<input type="text">` in
`<input type="file">` was replaced with `<label>` in bug 345195.
Additionally, it's used only by `EditorBase` to check `<input type="text">`
is in `<input type="file">`. Therefore, we don't need it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D181599
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
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
The issue here is that the SetValueInternal call made us go from empty
value to non-empty due to color's specialness of returning black always,
but since the value dirty flag wasn't set, the non-empty value actually
didn't make a difference and just confused the code.
Make the code follow the spec more closely, which fixes this (in
particular the SetDefaultValueAsValue call).
Also, remove some useless code in SetValueInternal() since callers end
up in OnValueChanged() effectively everywhere except when mDoneCreating
is false (in which case we can just wait until DoneCreatingElement calls
us again), and if the do not end up there then that's a bug to fix.
Differential Revision: https://phabricator.services.mozilla.com/D178706
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
