It's a more natural place for it to live, since it concerns only the
root view.
Clean up a bit while at it, and factor out the window size constraints,
which we're going to use momentarily.
Differential Revision: https://phabricator.services.mozilla.com/D168461
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
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
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
Instead of keeping a set of frames to update, keep a depth-ordered frame
list. Factor out the DirtyRootList for this.
Make sure that we're updating ancestor containers before children, and
make sure to store the last container state even if we end up not
updating (due to the element being in mUpdatedContainerQueryContents),
so that following layouts are stable.
This fixes the timeout in inline-size-bfc-floats, and the same kind of
instability in auto-scrollbars.html (if you take a profile of that test
you can see us infinitely recursing), as well as fixing various other
tests.
It causes a regression in nested-query-containers.html, probably to do with
ib-splits (since it's a block inside an inline and so on, and the frame
tree depth doesn't match the content tree depth, most likely). That
might need extra tweaks but it doesn't seem terribly concerning, so I'd
rather get this in.
Differential Revision: https://phabricator.services.mozilla.com/D165628
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
PruneOrInsertSubtree already has code to deal with this.
However, layout previously didn't notify a11y about the change if a shadow root was attached without any content, so PruneOrInsertSubtree was never called.
We now schedule re-evaluation of the a11y tree of the shadow host when DOM notifies layout about the attached shadow root.
This will call PruneOrInsertSubtree during the next refresh tick.
Differential Revision: https://phabricator.services.mozilla.com/D162263
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
Webrender uses this flag as a hint to separate mix blend containers so it should only be present on the root content document.
Differential Revision: https://phabricator.services.mozilla.com/D162046
Webrender uses this flag as a hint to separate mix blend containers so it should only be present on the root content document.
Differential Revision: https://phabricator.services.mozilla.com/D162046
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
GetViewManager() may return null if the relevant presshell is being destroyed.
This is a guess fix, but the crash reports seem to hint about this issue.
Differential Revision: https://phabricator.services.mozilla.com/D161587
[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
It's possible to change the timeline if the animation is in pending. So
we still need an animation tracker to track the scroll-linked
animations. Besides, per the spec, we should keep this animation in
pending if its timeline is inactive. So in this patch, we always put the
scroll-linked animations into ScrollTimelineAnimationTracker, and if we
change the timeline but the animation is still in pending, we move the
animation into the correct animation tracker if needed.
Using two different animation trackers because we would like to trigger
scroll-linked animations after frame construction and reflow,
and don't want to ensure the paint is scheduled.
Note:
1. All tests in scroll-timeline-dynamic.tentative.html are failed. We
will fix them in Bug 1774275.
2. Drop `animation-duration: infinite` from
progress-based-animation-animation-longhand-properties.tentative.html,
because infinite is not defined in animation-duration in [css-animations-1].
Differential Revision: https://phabricator.services.mozilla.com/D159650
It's possible to change the timeline if the animation is in pending. So
we still need an animation tracker to track the scroll-linked
animations. Besides, per the spec, we should keep this animation in
pending if its timeline is inactive. So in this patch, we always put the
scroll-linked animations into ScrollTimelineAnimationTracker, and if we
change the timeline but the animation is still in pending, we move the
animation into the correct animation tracker if needed.
Using two different animation trackers because we would like to trigger
scroll-linked animations after frame construction and reflow,
and don't want to ensure the paint is scheduled.
Note:
1. All tests in scroll-timeline-dynamic.tentative.html are failed. We
will fix them in Bug 1774275.
2. Drop `animation-duration: infinite` from
progress-based-animation-animation-longhand-properties.tentative.html,
because infinite is not defined in animation-duration in [css-animations-1].
Differential Revision: https://phabricator.services.mozilla.com/D159650
Before this patch, we had two `checkVisibilty` methods on the
nsISelectionController interface, backed by several layers of implementation,
ultimately backed by a single function on nsTextFrame (which didn't actually
do anything meaningful with any of the parameters).
As it turns out, this API only had one caller, in HTMLEditUtils.cpp.
This patch converts that caller to directly query nsTextFrame (if the given
node's primary frame is indeed a nsTextFrame). The direct function-call is
renamed to HasVisibleText(), to be a bit clearer about it being text-specific
and also to avoid confusion with the (unrelated) recently-specified HTML
checkVisibility() API.
With these changes, we can remove the API from the nsISelectionController
interface and its implementations.
This patch also updates the HTMLEditUtils::IsInVisibleTextFrames documentation
(with s/all/any/) to reflect the reality of what the nsTextFrame impl actually
does.
Differential Revision: https://phabricator.services.mozilla.com/D160563
