This one is tricky because form controls, though I think I got it right...
This fixes a pre-existing bug where we're not following the spec for readonly
inside content-editable.
I filed this as bug 1850390 but other browsers match the spec so add a test and
fix it while at it. This allows cheaper checks for readonlyness in a couple
places.
Differential Revision: https://phabricator.services.mozilla.com/D186896
This generalizes the previous "set single class from parser" fast-path to
also apply when there are multiple classes in the class attribute.
The main benefit is the cheaper cache lookup.
Another benefit is that this avoids a string copy (the same copy that the original
"set single class from parser" optimization avoided).
We now always atomize the full class attribute value before parsing it,
e.g. when somebody uses setAttribute. In the common case of a single class,
this atomization cost would have been paid anyway.
Before: https://share.firefox.dev/4576ulw
After: https://share.firefox.dev/3rNGBsH (though this is not the full story
because the atomization work is moved outside of nsHtml5TreeOperation::SetHTMLElementAttributes)
Differential Revision: https://phabricator.services.mozilla.com/D183813
Implemented the new <search> HTML element.
All WPT tests for it now pass (except one for iso-8859-8, not done generally).
A11y role uses just landmark as recommended instead of a new search role (for now).
Co-authored-by: Henri Sivonen <hsivonen@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D176967
Implemented the new <search> HTML element.
All WPT tests for it now pass (except one for iso-8859-8, not done generally).
A11y role uses just landmark as recommended instead of a new search role (for now).
Co-authored-by: Henri Sivonen <hsivonen@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D176967
Implemented the new <search> HTML element.
All WPT tests for it now pass (except one for iso-8859-8, not done generally).
A11y role uses just landmark as recommended instead of a new search role (for now).
Co-authored-by: Henri Sivonen <hsivonen@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D176967
Upcoming :has invalidation (Bug 1792501) requires 4 more flags, and we're out of space.
This change consumes the remaining 32-bit hole in `nsINode` to migrate selector-specific
node flags.
This has implications on 32-bit platforms, specifically on text nodes.
Differential Revision: https://phabricator.services.mozilla.com/D184718
This allows us to deprecate `mozInputSource` for the Web while
avoiding console warnings for internal uses, which now use the
ChromeOnly `inputSource` attribute.
Differential Revision: https://phabricator.services.mozilla.com/D183643
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
This doesn't change behavior on its own. It could be split up a bit more
if needed though over all it shouldn't be hard to follow.
Unify nsHTMLStyleSheet and nsHTMLCSSStyleSheet into AttributeStyles
because the fact that we have two right now is pretty silly. They are
also not stylesheets (they used to be pre-stylo).
Differential Revision: https://phabricator.services.mozilla.com/D181414
With this change, Selections are also registered into StaticRanges,
ultimately making them visible to `nsINode::IsSelected()`,
which is necessary to paint them.
Differential Revision: https://phabricator.services.mozilla.com/D175784
With this change, Selections are also registered into StaticRanges,
ultimately making them visible to `nsINode::IsSelected()`,
which is necessary to paint them.
Differential Revision: https://phabricator.services.mozilla.com/D175784
HasBoxFFI and HasArcFFI aren't great, see bug 1831242 as for examples of
why.
HasArcFFI requires a bit more care, but HasBoxFFI doesn't give us much
benefit. Instead use the same type in the FFI boundary.
Differential Revision: https://phabricator.services.mozilla.com/D177252
This is a tentative way to avoid any timeout in WPT because other
brower vendors may expect getAnimations() works for scroll animations.
The original implementation is error-prone because the user can use the
declarative way to create a CSS animation associated with the document-timeline,
and then changes animation-timeline property to any other scroll-timeline.
If the user calls getAnimations() before changing its style, we still expose
the Animation objects in JS and may crash or have other unexpected bahaviors
if the user tries to access Animation.timeline.
Besides, another benefit of this patch is that we can use other Web Animation
APIs for scroll animations in WPT, e.g. Animation.ready.
Differential Revision: https://phabricator.services.mozilla.com/D176966
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
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