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
This patch doesn't change behavior. The changes were auto-generated by the
following command:
./mach clang-format -p layout/
Differential Revision: https://phabricator.services.mozilla.com/D160552
This patch doesn't change behavior, and eliminates copy construction of
nsFrameList via utilizing const-references to store the return value of
`GetChildList()`.
nsFrameList::Clone() is added in case the caller wants a copy of a list.
This is the first step toward making nsFrameList a move-only class.
Differential Revision: https://phabricator.services.mozilla.com/D160013
This patch doesn't change behavior, and eliminates copy construction of
nsFrameList via utilizing const-references to store the return value of
`GetChildList()`. This is the first step toward making nsFrameList a move-only
class.
Differential Revision: https://phabricator.services.mozilla.com/D160013
After this patch, we still need nsFrameList::Enumerator to iterate
nsFrameList::Slice. We might enhance nsFrameList::Iterator to support Slice, but
I'll leave this for another day.
Differential Revision: https://phabricator.services.mozilla.com/D158809
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
The main issue here is that we have a dynamic change request from the
embed load. That would usually not get honored, because we're printing.
But we call into ReconstructFrames() and flush style _before_ asking to
reconstruct the document, which means that replicated fixed frames that
don't get properly cleaned-up.
This is not a correctness issue because we're about to reconstruct the
whole frame tree anyways, but the intermediate state is invalid and
caught by our assertions.
Differential Revision: https://phabricator.services.mozilla.com/D157674
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D157306
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D157306
(This assert should be trivially satisfied, but nonetheless we get crash
reports that suggest we have null pointers here, so let's see...)
Differential Revision: https://phabricator.services.mozilla.com/D157293
This API only should never receive a null frame pointer; but we occasionally
get crash reports in this function where a null frame pointer seems to be
involved. This patch's diagnostic asserts might help us catch these crashes
slightly earlier and more directly, and might help us reason about what's going
on a bit better.
Differential Revision: https://phabricator.services.mozilla.com/D157236
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D156473
As per spec, see https://drafts.csswg.org/css-color-adjust/#color-scheme-effect:
> In order to preserve expected color contrasts, in the case of embedded
> documents typically rendered over a transparent canvas (such as
> provided via an HTML iframe element), if the used color scheme of the
> element and the used color scheme of the embedded document’s root
> element do not match, then the UA must use an opaque canvas of the
> Canvas color appropriate to the embedded document’s used color scheme
> instead of a transparent canvas.
After bug 1782596 we were using the preferred rather than used
color-scheme, which is the right thing to do for prefers-color-scheme,
but not for the canvas background.
Differential Revision: https://phabricator.services.mozilla.com/D155831
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
The code that bug 1754436 deleted checked to make sure there was a widget for the returned view, but it looks like it's possible in some edge cases to have an open popup that doesn't have a widget (most likely just for a split second). We need a widget to dispatch the event, and if it doesn't have a widget it's not visible so no point in touching it at all anyways.
Differential Revision: https://phabricator.services.mozilla.com/D155819
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
This still doesn't fire on print settings changes, so it uses the
default page size. Which is probably better than nothing, but...
To make viewport-size media-query listeners work more generally for
printed documents, we would need to re-clone the top document
unconditionally for all print settings changes, which needs front-end
work at least, and is dubious if the page changes dynamically.
Differential Revision: https://phabricator.services.mozilla.com/D150499
This is far from fully perfect (specially when dealing with nested
containers, we need to be smarter when updating there), but it's
incremental progress.
Differential Revision: https://phabricator.services.mozilla.com/D151496
This is far from fully perfect (specially when dealing with nested
containers, we need to be smarter when updating there), but it's
incremental progress.
Differential Revision: https://phabricator.services.mozilla.com/D151496
In order to support record the last user input for touch given APZ won't
synthesize mouse event for touch in parent process. Using pointer event could
support pen input nicely, too.
Differential Revision: https://phabricator.services.mozilla.com/D151282
