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
Having a base class with a single static member doesn't buy us much, and
actually MSVC-compatible compilers don't optimize empty base classes out
(plus the empty base is at the end so it might even take space on Linux
and macOS, untested).
Just put the values in Element.h / Element.cpp which is the common base
class of the relevant elements.
Differential Revision: https://phabricator.services.mozilla.com/D200825
Given some markup like:
```html
<div id=popover popover>
<button id="openDialog">Open Dialog</button>
<dialog id=dialog>
I'm a dialog!
</dialog>
</div>
<button id="openPopover">Open Popover</button>
<button>I do nothing!</button>
```
With some JS like
```js
openDialog.onclick = () => {
dialog.showModal();
}
openPopover.onclick = () => {
popover.showPopover();
}
```
Clicking the "Open Popover" button followed by the "Open Dialog" button results in both the Dialog and Popover being hidden, however the dialog will still be open as modal, rendering the whole page inert, nothing is clickable and there seems to be no way to undo this (unless you use a CloseWatcher gesture such as the Esc key - if you have one available on your device).
It is expected that the popover should not close the dialog, as it causes the invisible Modal Dialog to make the whole page inert, and it is very difficult for users (and developers) to discover how to undo this action (pressing escape).
This was reported in https://github.com/whatwg/html/issues/9998, and WhatWG resolved to fix this, which in https://github.com/whatwg/html/pull/10116.
Differential Revision: https://phabricator.services.mozilla.com/D200686
The root cause of issue is that the link elements have not yet adopted the
activation behavior defined in the specification. This patch add a hacky way to
avoid link elements perform activation behavior if it has a child input element
which will perform activation behavior. This patch introduces new flags instead of
reusing the exiting ones, allowing us to uplift this patch more safely.
Differential Revision: https://phabricator.services.mozilla.com/D197393
