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
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
Make all UA widgets also NAC.
Keep the UA widget flag but break at anonymous subtree boundaries, so
that only nodes inside the UA widget directly (and not NAC from those)
get the flag.
This is important because two callers depend on this difference:
* The style system, since we still want to match content rules from
stylesheets in the UA widget. We also match user rules, which is a
bit sketchy, but that was the previous behavior, will file a
follow-up for that.
* The reflector code, since we want the scope for UA widgets to not
include the NAC nodes inside that UA widget. nsINode::IsInUAWidget
got it wrong.
After this patch, ChromeOnlyAccess is equivalent to
IsInNativeAnonymousSubtree, so we should probably unify the naming.
That's left for a follow-up patch because I don't have a strong
preference.
Differential Revision: https://phabricator.services.mozilla.com/D174310
Starts to add part of the basic functionality for popover. Including
[1] :open & :closed CSS pseudo class
[2] showPopover(), hidePopover() and togglePopover() interfaces. Much of the
functionality is still to-do.
[3] PopoverData interface
Differential Revision: https://phabricator.services.mozilla.com/D171719
This ensures that repeated calls to Element::GetGridFragments will return
an array of idempotent Grid objects for each fragment. This is
accomplished by making the Grid object hold a WeakFrame back to its
originating frame, and updating a property on construction and
destruction.
Differential Revision: https://phabricator.services.mozilla.com/D169724
Remove code on bind/unbind that requested a restyle on an unstyled
element, and that canceled that on an unbound element.
Instead, deal with detached nodes in EffectCompositor.
Tweak test restyles since we now expect one restyle as a result of the
initial composing of the animation that before happened eagerly.
Drive-by remove an unused test function in wpt (animationStartsRightNow
is not defined there anyways).
In practice, this makes it consistent with how we handle bind on
elements in shadow trees.
Differential Revision: https://phabricator.services.mozilla.com/D169932
This ensures that repeated calls to Element::GetGridFragments will return
an array of idempotent Grid objects for each fragment. This is
accomplished by making the Grid object hold a WeakFrame back to its
originating frame, and updating a property on construction and
destruction.
Differential Revision: https://phabricator.services.mozilla.com/D169724
This should both be faster and simpler. Also will allow us in the future
to animate more pseudos without having to add a gazillion properties.
I think we should try to clear more stuff (maybe the whole animation
data) on unbind, but that's a bit tangential.
Differential Revision: https://phabricator.services.mozilla.com/D169860
No implementation of nsIDOMXULMenuListElement returns an input field
(this is menulist.js and autocomplete-input.js).
It seems autocomplete-input used to do this, but it got refactored to
extend HTMLInputElement instead, so this code can all go.
Differential Revision: https://phabricator.services.mozilla.com/D169066
When `element.requestFullscreen` is called, we dispatch small task via
`Document::AsyncRequestFullscreen`. But it doesn't append `FullscreenRequests`
to `PendingFullscreenChangeList` immediately. So if we want to check
whether we have pending full screen request, we have to run an event loop.
Although I would like to check whether we have pending full screen request for
`screen.orientation.lock` compatibility, since we don't append it to pending
list immediately, we don't have the easy way to detect it.
`RequestFullscreen` doesn't wait for the completion if it runs on content
process since `RequestFullscreenInContentProcess` doesn't wait for the result
of chrome event. If runs on chrome process, `RequestFullscreenInParentProcess`
is synchronous. So this change removes `AsyncRequestFullscreen` and simply
calls `RequestFullscreen`.
By not using AsyncRequestFullscreen, we will append `FullscreenRequests` to
pending list immediately, so we can check it without event loop.
Differential Revision: https://phabricator.services.mozilla.com/D163583
The blur is a regression from bug 1740989, but it's really uncovering a
regression from bug 1729342, sorta. Before that, we used to focus the
inner text field on rebuild via focusInnerTextBox().
One could argue that the focus fixup rule should really deal with this,
but I guess since content can't really unattach shadow DOM, it's less of
a general issue and more of an implementation detail.
The test uncovers another pre-existing issue (switching from date ->
test was also broken, and we left a bogus ElementState::FOCUS state in
the element).
Differential Revision: https://phabricator.services.mozilla.com/D158167
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
