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
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
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
That was about XBL constructors being able to run script. But XBL is
gone and this should just be wasted work.
I want to land this in preparation for container queries substantially
changing the model here.
Differential Revision: https://phabricator.services.mozilla.com/D151495
And remove one unused caller.
This might change behavior of some selection contrast checks and backplating
which will potentially use the right background-color after this patch. The
next patch ensures this is also accounted for for scrollbars.
Unfortunately selection contrast checks are non-trivial to test because we only
do the contrast check with system colors, and we'd need a default selection
color close to the highlight color to do this.
Differential Revision: https://phabricator.services.mozilla.com/D151017
That was about XBL constructors being able to run script. But XBL is
gone and this should just be wasted work.
I want to land this in preparation for container queries substantially
changing the model here.
Differential Revision: https://phabricator.services.mozilla.com/D151495
The existing frame label was reusing the function name, but we already
have it when using native stacks. Renaming it to a more understandable
name should make it easier for our javascript developers users without
impairing gecko developers.
Differential Revision: https://phabricator.services.mozilla.com/D150976
The basic machinery to trigger re-snap is same as what scroll anchoring does,
queueing a triggering request and flush the queued requests after reflows
finished.
Depends on D148862
Differential Revision: https://phabricator.services.mozilla.com/D148863
The current implementation of TimelineConsumers contains some unnecessary
complexity due to how it is initialized as a singleton, and the need for it to
be initialized and used in a threadsafe way. This patch attempts to simplify it
by making all members static, and removing the need to explicitly observe
shutdown for cleanup.
In addition, this approach avoids the risk of the type being accessed from
off-main-thread during initialization or shutdown.
Depends on D150442
Differential Revision: https://phabricator.services.mozilla.com/D150443
nsImageGeometryMixin is used to redraw images with sync decoding. Without it,
if we paint an image with non-sync decoding, we won't know that it will be
drawn differently with sync decoding and so don't have a mechanism to include
it in the invalid region.
Currently the main situation where we draw images with non-sync decoding and
then with sync decoding is during reftests. If we unconditionally use sync
decoding during reftests we don't have to worry about the situation where we
switch. This will let us resolve the problems associated with nsImageGeometryMixin.
Differential Revision: https://phabricator.services.mozilla.com/D149657
nsImageGeometryMixin is used to redraw images with sync decoding. Without it,
if we paint an image with non-sync decoding, we won't know that it will be
drawn differently with sync decoding and so don't have a mechanism to include
it in the invalid region.
Currently the main situation where we draw images with non-sync decoding and
then with sync decoding is during reftests. If we unconditionally use sync
decoding during reftests we don't have to worry about the situation where we
switch. This will let us resolve the problems associated with nsImageGeometryMixin.
Differential Revision: https://phabricator.services.mozilla.com/D149657
Implements showing a "Paste" popup at the last mouse position (which
overlapped the browser window) when a certain custom event is received.
Creating and dispatchting that event is implemented in one of the
following parts.
Differential Revision: https://phabricator.services.mozilla.com/D135333
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
After bug 1730284 we don't use it for throttling iframes, so the only
remaining use the test-only nsIDOMWindowUtils.paintCount. None of the
tests using it rely on the empty transaction case, so we should be able
to just remove this.
Differential Revision: https://phabricator.services.mozilla.com/D146589
After bug 1730284 we don't use it for throttling iframes, so the only
remaining use the test-only nsIDOMWindowUtils.paintCount. None of the
tests using it rely on the empty transaction case, so we should be able
to just remove this.
Differential Revision: https://phabricator.services.mozilla.com/D146589
Although not needed right now (checkerboarding backgrounds get
a slice anyway due to being a different scroll root), this will
be important for the upcoming work to make backdrop filter
roots implicit. This allows WR to know when slicing up a content
slice if the prim is relevant to the backdrop root.
Differential Revision: https://phabricator.services.mozilla.com/D146145
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
There are cases where we want to scroll across documents (like
scrollIntoView), and bailing out for those is incorrect. This
usually can't happen because in HTML documents we always have a root
scroll frame, but for fixed positioned elements it can happen, as those
are not parented to it.
This came up in https://github.com/w3c/csswg-drafts/issues/5492, and
fixes the only case where Firefox and Safari differ (C).
ScrollFrameRectIntoView knows how to deal with non-scroll-frames, and
takes care of jumping across documents if necessary, so passing the root
frame is fine. We only needed to walk out the parent chain to be able to
accumulate all our continuation bounds relative to the same frame.
In practice the bail out code should now be unreachable. Add an
assertion to that effect.
Tests for this are already upstream in WPT, and pass with this patch,
see:
* https://github.com/web-platform-tests/wpt/pull/33572
* https://github.com/web-platform-tests/wpt/pull/33633
Differential Revision: https://phabricator.services.mozilla.com/D143250
Also, remove unnecessary/implied "#ifdef" in code-comment alongside #endif a
few lines below, for consistency with the similar code-comment that I'm adding
in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D143846
If allocation fails, we'll now just discard the entire contents of
mAllocatedPointers and stop using it going forward.
See the documentation alongside the mAllocatedPointers declaration (in this
patch) for more details.
Differential Revision: https://phabricator.services.mozilla.com/D143416
This patch doesn't change behavior. As of this patch, this variable gets
instantiated immediately (in the PresShell constructor) and is never null, so
no logic/beheavior has changed.
This lays the groundwork for the next patch, which will add one case where this
variable does get nulled out (and add logic to handle that).
Differential Revision: https://phabricator.services.mozilla.com/D143411
The regular scroll position restoration code will restore it.
Specifically, in ScrollFrameHelper::SaveState
https://searchfox.org/mozilla-central/rev/44ae61c5eeb150cb77b6b8511ceee7ddd6892cb7/layout/generic/nsGfxScrollFrame.cpp#7376
we store the visual viewport offset. ScrollFrameHelper::ScrollToRestoredPosition will try to restore both the layout scroll offset and the visual viewport offset by calling ScrollToWithOrigin (which leads to ScrollToImpl) and PresShell::ScrollToVisual respectively.
I observed the following sequence of events when running gfx/layers/apz/test/mochitest/browser_test_background_tab_load_scroll.js in one of the cases that it fails for me locally.
-ScrollFrameHelper::NotifyApzTransaction is called after sending a transaction to webrender, this sets mAllowScrollOriginDowngrade = true.
-the scroll frame is destroyed and re-created (I'm not sure why this destroy and re-create happened, I didn't investigate), we call SaveState and RestoreState. So now mLastScrollOrigin == Other, and mAllowScrollOriginDowngrade == true.
-the test calls ScrollBy, so we get a call to ScrollToImpl with aOrigin == Relative
-aOrigin gets changed to Other here https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#2979
-the code just below that determines that it is not a downgrade, so we update mLastScrollOrigin to Other (not a change) and set mAllowScrollOriginDowngrade = false
-ScrollFrameHelper::NotifyApzTransaction is _not_ called (probably because we are in a background tab), so mAllowScrollOriginDowngrade remains false
-the scroll frame is now at position 20000 and the visual viewport offset (stored on the presshell) is also 20000.
-the scroll frame is destroyed and re-created (this one I investigated, it's because the font subsystem has finished loading and asks for a global reconstruct https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/base/PresShell.cpp#9830), we call SaveState and RestoreState. So mLastScrollOrigin == Other, and mAllowScrollOriginDowngrade == true (the same values.
-we get a call to ScrollToRestoredPosition for the newly re-created scroll frame, we are trying to scroll from the current layout scroll position of 0 to the one we had before destruction and re-creation (20000). The visual viewport offset that is stored on the presshell has not been affected, it is still 20000.
-this gets to ScrollToImpl and with aOrigin == Restore
-we arrive at https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#3000 and Restore is a downgrade from Other, and mAllowScrollOriginDowngrade is false so we do not change mLastScrollOrigin (still Other) and mAllowScrollOriginDowngrade remains false
-we arrive at the code in ScrollToImpl that updates the visual viewport offset on the presshell https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#3232
-mLastScrollOrigin is Other, which can clobber apz, so we enter the if and add the difference between the before/after layout scroll position from this ScrollToImpl call (20000-0 = 20000) to the visual viewport offset (20000), getting 40000, which gets clamped to the max ~38000.
-and now the layout scroll position and the visual viewport offset have been detached when they shouldn't be.
If we reset the visual viewport offset when the scroll frame is destroyed we avoid the problem here.
Differential Revision: https://phabricator.services.mozilla.com/D139792
We only have to iterate over the open popups list (which is usually 0 or single digits) instead of every view.
Now that comboboxes definitely cannot create views, only xul menu popups can be floating popups.
Differential Revision: https://phabricator.services.mozilla.com/D138290
nsPresContest::RegisterManagedPostRefreshObserver still lets us add a managed post refresh observer until the mPresShell pointer on the prescontent is nulled out. That means that between the call to CancelManagedPostRefreshObservers and mPresContext->DetachPresShell() (which nulls out the mPresShell pointer on the prescontext) in PresShell::Destroy we can add a managed post refresh observer that will never get removed. Notably, destroying the frame tree happens between these two calls.
So move the CancelManagedPostRefreshObservers call to happen right after we null out the mPresShell pointer on the prescontext.
In bug 1737503 I want to add a managed post refresh observer when we destroy a subdocument frame (it's only interested in the recreate frames case not the destruction case, but not an easy way to tell them apart afaik), so it triggers this bug. The patch and test I have for that bug exercise this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135340
Extensions are using getComputedStyle(body).backgroundColor, which is
wrong at multiple levels.
The one that matters for this bug is that it is not color-scheme aware.
Depends on D133770
Differential Revision: https://phabricator.services.mozilla.com/D133771
No behavior change (you can't have an in-process frame container and a
BrowserChild at the same time), but avoids some needless refcounting
overhead and makes it simpler to follow.
Differential Revision: https://phabricator.services.mozilla.com/D133770
I guess we need to do this every time we get a new APZC tree manager (because that is where the zoom constraints map/cache is stored). I'm not sure how to detect that or if there are other cases we haven't covered.
Differential Revision: https://phabricator.services.mozilla.com/D113608
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
We only need to clean up the frames for its flat tree children which are
about to go away from the flat tree, but we don't need to do anything
else. This avoids issues with the following patches because menupopups
depend a lot on their frame tree state.
Differential Revision: https://phabricator.services.mozilla.com/D131083
Otherwise if we get an event targeting a different suppressed pres shell
while we're unsuppressing we might get stuck delaying the event over and
over, see the links in comment 33.
Not sure how to get a repro for this, the patch is written based on the
pernosco session, but suggestions welcome.
Differential Revision: https://phabricator.services.mozilla.com/D130100
Remove the follow-firefox-theme pref as now that's default everywhere,
and document better the behavior of the color-scheme property by
reworking and commenting the logic on it a bit.
Differential Revision: https://phabricator.services.mozilla.com/D128610
We have JS listeners that are expected to run once the LookAndFeel
caches have been cleared and such, so split the look-and-feel-changed
notification into an internal and external notification.
Differential Revision: https://phabricator.services.mozilla.com/D128097
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
The issue here is that we don't clear the cached intrinsic size of the
flex item, but this reproduces without flex at all.
The main issue is that we choose whether to clear the intrinsic sizes
from a reflow root (the outer svg in this case) based on whether the
reflow changes size or position:
https://searchfox.org/mozilla-central/rev/3fa5cc437a4937c621ea068ba5dc246f75831633/layout/base/RestyleManager.cpp#1224-1229
This is ~fine, except the nsChangeHint_ReflowChangesSizeOfPosition hint
can be "inherited" (and thus be cleared if already subsumed by a
parent):
https://searchfox.org/mozilla-central/rev/3fa5cc437a4937c621ea068ba5dc246f75831633/layout/base/nsChangeHint.h#465-469
This is ~fine, as we'll already start the reflow further up the tree (so
we don't need to start go past the reflow root), but we still need to
clear the ancestor intrinsics. We still get to StyleChangeReflow with
the ClearAncestorIntrinsics hint. We could pass that information down,
but the information is really already in via the IntrinsicChange.
I think it's just not correct to stop clearing intrinsic sizes if the
target is a reflow root and we get a TreeChange/StyleChange, regardless
of whether it changes size/position. It should also be a few less
instructions, though not that it matters.
Depends on D126812
Differential Revision: https://phabricator.services.mozilla.com/D126813
Unsuppressing is done only if the page can use stylesheet cache. That should mean the
load isn't a cold load and also some other resources may be cached and thus
painting could happen sooner.
There is currently a regression around dom.ipc.processCount.webIsolated handling, but the
testing has been done with dom.ipc.processCount.webIsolated==1, and the patch for bug 1731792
should give back similar behavior as what process count 1 has.
Differential Revision: https://phabricator.services.mozilla.com/D125878
One caveat is that this change doesn't mean we handle frame visibility in
iframes in a same manner regardless whether the iframe is out-of-process or not.
In fact, we handle OOP iframe cases in a slightly different way since in OOP
iframes if the iframe is invisible because it's scrolled out or some such, then
we can't tell how far the iframe is from the visible scroll port. For example;
```
<div style="height: 100px; overflow: scroll;">
<div id="spacer" style="width: 100%; height: 200px;"></div>
<iframe style="height: 100px;"></iframe>
</div>
```
In this case, we consider all frames inside the iframe are invisible because
the iframe position is out of our frame visibility tracking margins. But if
the #spacer element's height is 100px, we consider all frames inside the iframe
viewport are visible if the iframe is in-process iframe, whereas we consider
all frames are invisible if the iframe is out-of-process iframe.
So in short, the frame visibilityn inside OOP iframes is depending on whether
the iframe gets painted in the parent document, i.e. depending on display port
and other factors controlling the paint stuff, the visibility inside in-process
iframes is depending on same factors for normal scrollable frames.
Differential Revision: https://phabricator.services.mozilla.com/D125125
Before this patch, PresShell.cpp tries to reuse a LazyLogModule that's defined
in MobileViewportManager.cpp, which isn't actually declared in any header. This
prevents the build from linking, unless we're lucky enough to have these two
source files concatenated together via our unified build.
This patch promotes this LazyLogModule to be an actual static member-var on the
MobileViewportManager class, so that it can be exported and used externally in
a more structured way. This makes it consistent with the very-similar
"PresShell::gLog" member-variable.
Differential Revision: https://phabricator.services.mozilla.com/D125600
Disabled by default, browser.places.interactions.enabled, this adds scrolling metrics (time spent scrolling and distance scrolled) to the history metadata.
Differential Revision: https://phabricator.services.mozilla.com/D120656
Decisions about visual or layout viewport type coordinates are made based on cross process root content docoument (not in process).
Differential Revision: https://phabricator.services.mozilla.com/D124271
Remove the need to post a runnable to coalesce them (we still coalesce
theme changes because those do non-trivial work).
What can go on is that on cold load we load the font list async, and
that goes through this code via a faked font.internaluseonly.changed
pref change, which stores a reframe change hint in
mChangeHintForPrefChange.
If the page flushes after this code runs, but before the next refresh
driver tick, we will be just wasting work. So instead do the
RebuildAllStyleData call synchronously. It just schedules a flush and
posts a hint, so it doesn't do the work right there, but makes the next
flush do the work as needed, so it should be faster and also more
correct.
Also improve handling of preference sheet prefs and such to avoid more
wasted work when we go through this code, as the assumption their
handling was doing was that it gets called infrequently, but it's not
the case due to the font list updates.
Differential Revision: https://phabricator.services.mozilla.com/D123103
To look up/instantiate platform fonts based on CSS font properties, we create a gfxFontGroup from an nsFont and other attributes; this is currently cached in an nsFontCache attached to the nsDeviceContext.
However, this assumes that the mapping to platform fonts will be the same for all documents using the given device context. In a world where visibility of platform fonts to the page may be restricted, and may depend on the individual document (e.g. if the user disables tracking protection for a particular site), the mapping represented by nsFontCache may vary, and determining how to resolve a given font request will need access to the requesting document in order to know what visibility it is allowed.
To support this, this patch moves the nsFontCache from nsDeviceContext to nsPresContext. In itself, this should cause no visible change in behavior, but it provides a basis for the patches that will follow in bug 1715501.
It's likely that this will have some effects on individual performance tests, depending on the exact content and sequencing of page loads, because of changed caching behavior. E.g. having a per-presContext cache may sometimes mean that we no longer take advantage of a cached gfxFontGroup that a previously-loaded page created; but on the other hand the caches will tend to be smaller and have faster lookups.
My testing so far suggests that we will see some apparent regressions, alongside some improvements, but that overall there should be little change. I'd like to get this change landed separately, before any of the actual font-visibility behavior changes, so that we can more clearly see and isolate any unexpected effects.
Differential Revision: https://phabricator.services.mozilla.com/D122715
Font inflation isn't required for pages whose viewport is narrow enough that we
don't have to zoom *out* when doing zoom-to-fit.
As the viewport scale is given as a CSSToScreenScale, this means that what we're
actually doing at the moment, though, is comparing the width of the viewport in
CSS pixels to the width of the screen in physical pixels, *without* taking the
default scale on a high-DPI device into account.
This issue affects neither pages using a "width=device-width" viewport (the
IsAutoSizeEnabled() check handles those), nor pages without an explicitly
specified viewport at all (the viewport info returns the minimum zoom level in
that case, i.e. 25 %, which would therefore require a device scale of > 4 in
order for us to erroneously turn off font inflation - even modern phones don't
seem to quite reach *that* sort of pixel density, e.g. a Pixel 5 only reports a
default scale of ~2.73.
For pages with an explicitly sized viewport this can however mean that we turn
off font inflation too early: Slashdot e.g. uses "width=1000", which means that
on a phone with a 720 px screen font inflation is correctly enabled, but on a
different phone squeezing 1080 px into the same physical screen width (i.e.
higher DPI, but *not* a physically larger screen), font inflation is suddenly
and incorrectly turned off.
Differential Revision: https://phabricator.services.mozilla.com/D122059
For pages with an explicitly sized viewport, whether or not we enable font
inflation depends on whether the viewport is larger than content viewer size (so
it will be displayed zoomed out) or not.
For historical reasons, so far we've used the screen size as a proxy for the
content viewer size. On a phone this is a reasonable approximation (albeit a bit
less so now that Android also offers split-screen and picture-in-picture modes),
but when testing/debugging on a desktop computer, this means that the results
will depend on the screen size of the machine in question, which makes it rather
hard writing sensible test cases for that scenario.
Therefore, we're finally following up with that TODO comment in the existing
code and start using the content viewer size of the top-level document instead.
Fission means that approach won't easily work for cross-process iframes, but
given that the current calculations don't make much sense for frames anyway, we
just accept that limitation, since a proper solution as per bug 1724311 would
obsolete any work done here anyway.
Differential Revision: https://phabricator.services.mozilla.com/D122057
It's possible to observe an element in the iframe while the
ResizeObserver object lives in the outer document, so we have to make
sure we also schedule the observer for all documents in the same
BrowsingContext tree.
Differential Revision: https://phabricator.services.mozilla.com/D119843
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
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
This should pretty much match our non-fission behavior. I found the
original approach of keeping the frameloader from nsSubDocumentFrame
quite hard to get green on try unfortunately, because among other
things, the new frameloader wouldn't get the right viewport sizes /
position / etc.
Differential Revision: https://phabricator.services.mozilla.com/D121198
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
* Per advice from Emilio on Matrix, I consolidated overflow checks into `ScrollFrameHelper::GetOverflowState()`.
* In `ScrollFrameHelper::ReflowFinished` we detect the condition requring the app to expand the toolbar.
(Hiro, I know that you suggested a second place to detect this. If you feel that it is important enough to add that,
we'd prefer filing a follow-up bug in Layout for that case that your team can follow up on.)
* We then propagate the notification through `PresShell`, up through `PBrowser`, through the `nsWindow`, then into the `GeckoSession`
* We invoke a new method on the `ContentDelegate`. This seemed like the reasonable delegate to use given other existing
callbacks in the similar vein (such as going fullscreen), but let me know if this should go elsewhere.
* We update GVE and JUnit tests to test this.
Differential Revision: https://phabricator.services.mozilla.com/D120499
In the most common case the first call to FindViewContaining has aRelativeToView = aView = the root view of the root content document, and we start in visual coords. Then we convert to layout coords and call FindViewContaining recusively with aRelativeToView = the root view again, aView = a child of the root view and working in layout coords. And we still satisfy the conditions to set crossingZoomBoundary to true, which is incorrect because we already crossed. We need to check that we are also in visual coords.
Differential Revision: https://phabricator.services.mozilla.com/D105438
Since bug 1717726 we've disallowed having remote <browser> or remote <iframe>
inside nsDeckFrame which means `captureingFrame` in ClearMouseCapture(nsIFrame*)
function will never be called in an out-of-process thus we can use
IsAncestorFrameCrossDocInProcess there.
Also add an assertions that the function gets called only with a child frame of
nsDeckFrame since this function is used only inside nsDeckFrame.
Depends on D119068
Differential Revision: https://phabricator.services.mozilla.com/D119069
GeckoView always calls preserveLayers(true) on all <browser> elements,
which causes the puppet widget to always be considered visible.
Given how the code worked before, aBrowsingContext.isActive = false
after that call would deactivate the pres shell, but after my patch it
stops doing so.
We don't really want to un-throttle the refresh driver etc just because
we're preserving layers, so propagate the state to the child process and
account for that in the logic to determine PresShell activeness.
Depends on D118703
Differential Revision: https://phabricator.services.mozilla.com/D118884
This moves the logic of whether a pres shell should be active to a
single place to make it sane to reason about, and fixes the
subdocument propagation when a BrowserChild becomes visible.
Differential Revision: https://phabricator.services.mozilla.com/D118703
This moves the logic of whether a pres shell should be active to a
single place to make it sane to reason about, and fixes the
subdocument propagation when a BrowserChild becomes visible.
Differential Revision: https://phabricator.services.mozilla.com/D118703
See rationale in bug 1698693 comment 9.
The added flags ensure we stop at the RSF even if it's overflow:hidden,
or if the starting frame is in fixed content.
Depends on D117387
Differential Revision: https://phabricator.services.mozilla.com/D117388
