Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
Two changes are introduced:
* LCP has a hashtable called `ContentIdentifiersForLCP` to store
(element, image) pairs to avoid processing the same pair multiple
times. Instead of using weak pointers for elements, this patch changes
it to use raw pointers for better performance. Also, makes the
hashtable to use element alone as the key, so that the entry
can be quickly removed when nsINode::LastRelease is called.
* Another change to make imgRequestProxy stores the
timestamps for LCP, so we can create LCP entries when the size
is available, instead of creating one temporarily and updating it
later. This allows us to eliminate a hashtable called
`mImageLCPEntryMap` for better performance.
Differential Revision: https://phabricator.services.mozilla.com/D214315
UpdateIntersectionObservation takes some time (see profile in blocked
bug). It it needs to do multiple hashmap lookups unnecessarily.
We can store the observation state in the IntersectionObserver object
and remove the bespoke intersectionobserverlist property, using
BindObject / UnbindObject to keep stuff alive, like ResizeObserver and
MutationObserver do.
Differential Revision: https://phabricator.services.mozilla.com/D215370
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
Also, in EventStateManager, convert `ComputeScrollTarget()` and
`ComputeScrollTargetAndMayAdjustWheelEvent()` to return `ScrollContainerFrame*`
so that we can drop more unnecessarily `do_QueryFrame`.
Due to removing `nsIScrollableFrame` forward declaration in DOM headers, we have
to add `nsIScrollableFrame` forward declaration temporarily in
nsMenuPopupFrame.h to make this patch compile, but we'll remove it once we
remove `nsIScrollableFrame` under layout/.
Differential Revision: https://phabricator.services.mozilla.com/D211496
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
Also, in EventStateManager, convert `ComputeScrollTarget()` and
`ComputeScrollTargetAndMayAdjustWheelEvent()` to return `ScrollContainerFrame*`
so that we can drop more unnecessarily `do_QueryFrame`.
Due to removing `nsIScrollableFrame` forward declaration in DOM headers, we have
to add `nsIScrollableFrame` forward declaration temporarily in
nsMenuPopupFrame.h to make this patch compile, but we'll remove it once we
remove `nsIScrollableFrame` under layout/.
Differential Revision: https://phabricator.services.mozilla.com/D211496
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
Ths patch introduces a new class called `CrossShadowBoundaryRange` to
make cross shadow boundary range related stuff can be isolated into a
single class.
It also tweaks a few functions along the call stack, the goal here
is to make sure nsContentUtils::IsPointInSelection can detect points
in ShadowDOM selection.
There's an additional change to `SelectionUtils.sys.mjs` to make sure
the correct context menu items are displayed when the current selection
crosses the boundary.
Differential Revision: https://phabricator.services.mozilla.com/D204080
So that we get the right screen on Wayland, where ScreenForRect is not
really reliable.
This makes mismatched screen sizes and resolutions work better. In
particular, this matches what window.screen returns.
Differential Revision: https://phabricator.services.mozilla.com/D204753
The CSS Box Sizing specification indicates that last remembered sizes
are recorded "at the time that ResizeObserver events are determined and
delivered" [1].
In bug 1807253, we changed the implementation of when proximity to the
viewport of `content-visibility: auto` nodes are determined and of when
resize observations are broadcast, in order to align with the latest
version of the HTML specification [2]. We continue to use an internal
`Document::mLastRememberedSizeObserver` to update last remembered sizes
but it has been causing issues (e.g. bug 1867090 and bug 1880928) and
could be replaced by a direct update before broadcasting resize
observations.
This is what the current patch is doing. The elements currently observed
by `Document::mLastRememberedSizeObserver` are now stored on a
`Document::mElementsWithLastRememberedSize` hashset and a new function
`Document::UpdateLastRememberedSizes` is called before broadcasting
resize observations, and peforms the work of `LastRememberedSizeCallback`
and of `CalculateBoxSize` (with `aBox=Content_box`).
The only behavior change is in the `while(true)` loop from
`DetermineProximityToViewportAndNotifyResizeObservers`: at each step
we update the last remember sizes for elements of arbitrary depth, and
don't use these depths for calculating `shallowestTargetDepth`. This is
fine, since our `LastRememberedSizeCallback` only records current box
sizes without causing significant side effects (e.g. execution of
JavaScript code) that may require a relayout.
[1] https://drafts.csswg.org/css-sizing-4/#last-remembered
[2] https://html.spec.whatwg.org/#update-the-rendering
Differential Revision: https://phabricator.services.mozilla.com/D202571
Make sure to do no work on insertions if the dir=auto element has
already the right strong directionality, but record that the node might
be the one impacting the dir=auto resolution.
Also get some node flags back.
Differential Revision: https://phabricator.services.mozilla.com/D202071
Accessibility needs to keep track of changes to explicitly set attr-elements.
Since the popovertarget content attribute is "" for any explicitly set attr-element, we won't always get attribute change notifications for the content attribute when .popoverTargetElement is set.
For example, if e1's popovertarget content attribute is absent and you set e1.popoverTargetElement to e2, the popovertarget content attribute will be "".
If you later set e1.popoverTargetElement to e3, there won't be a notification for the content attribute change, since it remains "".
Even if there were, it might occur before the element has changed, which means we can't detect any relevant state changes there; e.g. mPrevStateBits.
To deal with this, we now have DOM notify accessibility before and after the explicitly set attr-element is changed.
Within DocAccessible, this is treated like any other attribute change, but the notification methods get called consistently and at the appropriate time.
Differential Revision: https://phabricator.services.mozilla.com/D201662
This will be needed by accessibility for two reasons:
1. Accessibility will need to keep track of explicitly set attr-elements even if they aren't a descendant of any of the refering element's shadow-including ancestors. Accessibility will enforce that restriction itself before using the attr-element.
2. Accessibility will need to be able to distinguish between an attr-associated element obtained from an explicitly set attr-element vs derived using an id string in the content attribute. There are other ways to do this, but they are somewhat ugly.
Differential Revision: https://phabricator.services.mozilla.com/D201660
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
This the "body propagated to root" case to also set aFrame.
This doesn't change behavior for current callers, but would be useful to
simplify the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D200915
This the "body propagated to root" case to also set aFrame.
This doesn't change behavior for current callers, but would be useful to
simplify the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D200915
