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
The spec is still using `Scroll-linked`, so we exclude the change of WPT tests.
I believe WPT will get updates once the spec doc is renamed.
Differential Revision: https://phabricator.services.mozilla.com/D165914
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
We always use the document timeline of the cloned document, and clone the
paused animation with the preserved progress, even if the original
timeline is null.
Differential Revision: https://phabricator.services.mozilla.com/D164712
This change adds support for `content-visibilty: auto` as well as
showing and hiding content based on the relevancy of the content as
defined in the specification. Changes to relevancy are handled by
triggering updates in a set of `content-visibility: auto` frames stored
in PresShell at the appropriate time in the document lifecycle.
Some tests are now failing due to this feature exposing the failures,
but they will be fixed in later changes.
This change is a reland of an earlier version that properly updates
intrinsic sizes and triggers an update of remembered size for the
purposes of contain-intrinsic-size when content relevancy changes.
Co-authored-by: Jihye Hong <jihye@igalia.com>
Differential Revision: https://phabricator.services.mozilla.com/D159693
This change adds support for `content-visibilty: auto` as well as
showing and hiding content based on the relevancy of the content as
defined in the specification. Changes to relevancy are handled by
triggering updates in a set of `content-visibility: auto` frames stored
in PresShell at the appropriate time in the document lifecycle.
Some tests are now failing due to this feature exposing the failures,
but they will be fixed in later changes.
Co-authored-by: Jihye Hong <jihye@igalia.com>
Differential Revision: https://phabricator.services.mozilla.com/D159693
The Element caller only cares about avoiding a flush and can use the
observable parent layout stuff.
The scrollframe one clearly wants the cross-process version according to
the comment.
Differential Revision: https://phabricator.services.mozilla.com/D162477
This doesn't change behavior, but clarifies a bit the naming to match
the scrollIntoView() API. Also makes the name generic (rather than
Top/Left/etc), since for scrollIntoView we want to make the axes be
logical.
That will be done in bug 1789464 (probably via an extra ScrollFlag).
Differential Revision: https://phabricator.services.mozilla.com/D162286
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
Two tweaks:
* Use nsPresContext::Medium to decide whether to start transitions.
This catches both the print emulation and the before/afterprint event
dispatching code too, which is desirable.
* Don't clone transition effects for print docs. This seems to match
other browsers (click "trigger transition", then Ctrl+P in Chromium
for example).
Move our existing css-animations tests to WPT. They were written for
compat with other browsers so we want to know if other browsers behave
differently.
Differential Revision: https://phabricator.services.mozilla.com/D161086
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
