We have to use wayland to position popup windows and we need to propagate the modified
position (if happens) back to nsView. The mScreenRect in the nsMenuPopupFrame is in the CSS units
and that produce rounding error when font scale factor is not 1. To fix that we will use appunits
for the mScreenRect.
Differential Revision: https://phabricator.services.mozilla.com/D114577
This will cause to paint items that would've previously been occlusion culled,
but we shouldn't be using this code in any performance critical areas and
removing the occlusion culling infrastructure will let us make the fast path
faster.
Differential Revision: https://phabricator.services.mozilla.com/D124108
Add an interface (and update Gecko to provide) a stable unique
identifier for each spatial node that is consistent across
display lists.
Although this patch doesn't _do_ anything useful with this yet,
we'll use this in future to allow interning, persisting and caching
a lot more information related to primitives and clips.
For now, it just asserts that the calling code never supplies a
duplicate unique identifier - which will be useful to have running
in nightly for a couple of weeks before starting to make use of
these identifiers.
Differential Revision: https://phabricator.services.mozilla.com/D123177
After CollectClientRectsAndText is eliminated from the profiles here, SelectionStateChanged
is the next obvious hotspot, and it can similarly be accelerated by binary-searching the continuations.
Depends on D122999
Differential Revision: https://phabricator.services.mozilla.com/D123000
This allows us to binary-search the continuations from nsRange::CollectClientRectsAndText,
instead of linear-searching the linked list for every range we need to look up.
Depends on D122998
Differential Revision: https://phabricator.services.mozilla.com/D122999
This is helpful when we have extremely long continuation chains, to avoid having to
follow all the back-pointers to find the primary frame. By itself it makes little
difference to the testcase here, but is a basis for the patch that follows.
Differential Revision: https://phabricator.services.mozilla.com/D122998
If so, `dependsOnCBBSize` will be set to true, and later in
`ReflowInput::InitResizeFlags()` we will add
`NS_FRAME_CONTAINS_RELATIVE_BSIZE` to the appropriate ancestor.
Sorted the #include statements in ReflowInput.cpp because I added
nsFlexContainerFrame.h.
Differential Revision: https://phabricator.services.mozilla.com/D123703
mVisibleRegion was added in bug 530686 as an optimization for when the invalid
region was vertically discontiguous. WebRender doesn't call ComputeVisibility
and so never had an updated mVisibleRegion and so never used it during drawing.
WebRender fallback drawing has limited invalidation support and currently only
passes a rect to ComputeVisibility so it also wasn't taking advantage of this
optimization. This is also true of nsDisplayList::Paint.
In summary, we're not currently using this optimization and supporting it bloats
the display items. If we were to reintroduce it, I think it would make more sense
for the paint region to show up in the Paint function and not be stored in the
display item.
Differential Revision: https://phabricator.services.mozilla.com/D123791
CLOSED TREE
Backed out changeset d0864a5c8e90 (bug 1725555)
Backed out changeset 22b941581212 (bug 1725555)
Backed out changeset f2357e055668 (bug 1725555)
After CollectClientRectsAndText is eliminated from the profiles here, SelectionStateChanged
is the next obvious hotspot, and it can similarly be accelerated by binary-searching the continuations.
Depends on D122999
Differential Revision: https://phabricator.services.mozilla.com/D123000
This allows us to binary-search the continuations from nsRange::CollectClientRectsAndText,
instead of linear-searching the linked list for every range we need to look up.
Depends on D122998
Differential Revision: https://phabricator.services.mozilla.com/D122999
This is helpful when we have extremely long continuation chains, to avoid having to
follow all the back-pointers to find the primary frame. By itself it makes little
difference to the testcase here, but is a basis for the patch that follows.
Differential Revision: https://phabricator.services.mozilla.com/D122998
Since WebRenderLayerScrollData nodes are emitted on the way out
of the recursion over the display list, we need to be careful
that a deferred transform doesn't end up on a deeper node than
it should be.
Differential Revision: https://phabricator.services.mozilla.com/D123397
Add an interface (and update Gecko to provide) a stable unique
identifier for each spatial node that is consistent across
display lists.
Although this patch doesn't _do_ anything useful with this yet,
we'll use this in future to allow interning, persisting and caching
a lot more information related to primitives and clips.
For now, it just asserts that the calling code never supplies a
duplicate unique identifier - which will be useful to have running
in nightly for a couple of weeks before starting to make use of
these identifiers.
Differential Revision: https://phabricator.services.mozilla.com/D123177
Looks like they are some leftovers from the previous profiler Rust API changes.
I thought they were removed already, but apparently they were forgotten during
a rebase or somethig.
Differential Revision: https://phabricator.services.mozilla.com/D123619
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
GetOffsetToCrossDoc takes a valid non null pointer of nsIFrame, so it will not
walk up the frame tree across process boundaries.
If the call site needed the offset up to a frame in a different process, which
means the function call used for obtaining the nsIFrame needs to be audited such
as bug 1727229, which is for auditing GetReferenceFrame call sites
(GetOffsetToCrossDoc is often used with GetReferenceFrame, something like
`GetOffsetToCrossDoc(GetReferenceFrame())`.
FWIW, I did skim all GetOffsetToCrossDoc call sites [1], all look okay to me,
they are in auto scrolling, event handling, display list building, in the parent
process (i.e. XUL), etc. etc. Those features have been addressed in Fission.
[1] https://searchfox.org/mozilla-central/search?q=nsIFrame%3A%3AGetOffsetToCrossDoc&path=&case=true®exp=false
Differential Revision: https://phabricator.services.mozilla.com/D123553
The assertion is testing the sign of `availableFreeSpace` and `isUsingFlexGrow`.
After we use 64-bit arithmetic, it's likely that the stronger assertion holds.
Differential Revision: https://phabricator.services.mozilla.com/D123519
The idea of this patch is to use 64-bit coord type when resolving the
main size for flex items to avoid integer overflow when individual flex
items have huge hypothetical main sizes, which can happen with
percent-width table-layout:fixed descendants. We have to avoid integer
overflow to shrink flex items properly in that scenario.
Delete the "Note:" in `AddLastItemToMainSizeTotals()` since we remove
`AddChecked()` in favor of regular 64-bit addition for
`mTotalOuterHypotheticalMainSize`.
The wpt testcase is adapted from bug 1469649 comment 12.
Differential Revision: https://phabricator.services.mozilla.com/D123268
The precision of `double` is needed when we are distributing large
`sizeDelta` via `availableFreeSpace * myShareOfRemainingSpace`.
Without this patch, the wpt test added in Part 2 will fail.
Differential Revision: https://phabricator.services.mozilla.com/D123267
IsVisibleConsideringAncestors has a PresShell::IsUnderHiddenEmbedderElement which
is representing ancestor's visibility state in different process (but only for
contents processes). so it doesn't need to walk up the frame tree across process
boundaries.
Differential Revision: https://phabricator.services.mozilla.com/D123556
After CollectClientRectsAndText is eliminated from the profiles here, SelectionStateChanged
is the next obvious hotspot, and it can similarly be accelerated by binary-searching the continuations.
Depends on D122999
Differential Revision: https://phabricator.services.mozilla.com/D123000
This allows us to binary-search the continuations from nsRange::CollectClientRectsAndText,
instead of linear-searching the linked list for every range we need to look up.
Depends on D122998
Differential Revision: https://phabricator.services.mozilla.com/D122999
This is helpful when we have extremely long continuation chains, to avoid having to
follow all the back-pointers to find the primary frame. By itself it makes little
difference to the testcase here, but is a basis for the patch that follows.
Differential Revision: https://phabricator.services.mozilla.com/D122998
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
After CollectClientRectsAndText is eliminated from the profiles here, SelectionStateChanged
is the next obvious hotspot, and it can similarly be accelerated by binary-searching the continuations.
Depends on D122999
Differential Revision: https://phabricator.services.mozilla.com/D123000
This allows us to binary-search the continuations from nsRange::CollectClientRectsAndText,
instead of linear-searching the linked list for every range we need to look up.
Depends on D122998
Differential Revision: https://phabricator.services.mozilla.com/D122999
This is helpful when we have extremely long continuation chains, to avoid having to
follow all the back-pointers to find the primary frame. By itself it makes little
difference to the testcase here, but is a basis for the patch that follows.
Differential Revision: https://phabricator.services.mozilla.com/D122998
Collapsing selection with middle click is compatible behavior with Chrome.
However, some Firefox users don't like this behavior, and we have not done it
before. Therefore, this patch adds a hidden pref to prevent the new Chrome
compatible behavior.
Keeping compatible behavior is important and middle click is mainly used for
autoscroll. Therefore, if auto scroll is disabled, we should ignore the new
pref for better compatibility.
Unfortunately, we collapse selection before `AutoScrollChild` handles
`mousedown` event with the listener in the system group (
`nsIFrame::HandleEvent()` is called before that). Therefore, we cannot prevent
the selection change from `AutoScrollChild` only when it starts scroll.
For solving this issue, we need a lot of big changes. Therefore, for now,
this patch just checks whether the pref is enabled or not.
And also the new pref is ignored when middle click paste is enabled because
it may be followed by "paste" event even when user clicks non-editable nodes.
Then, if web apps handle "paste" event, the new selection range may be
important. Therefore, we should ignore the new pref in this case.
Differential Revision: https://phabricator.services.mozilla.com/D122931
This *mostly* gets us the latest WebIDL API of WebGPU. There is a few limits we are missing, and maybe some things I didn't notice.
But it gets us the new `GPUCanvasContext`, `GPUSupportedLimits`, and `GPUVertexStepMode`.
Differential Revision: https://phabricator.services.mozilla.com/D120764
This *mostly* gets us the latest WebIDL API of WebGPU. There is a few limits we are missing, and maybe some things I didn't notice.
But it gets us the new `GPUCanvasContext`, `GPUSupportedLimits`, and `GPUVertexStepMode`.
Differential Revision: https://phabricator.services.mozilla.com/D120764
This effectively reverts the behavior to the one before bug 1711437
(making the CC setup sound again), but without a big backout.
Fixing the CC setup of @import rules properly is a bit more involved
than what I anticipated and I don't want to have DevTools folks blocked
for too long, nor have this crash in-tree for too long either.
Differential Revision: https://phabricator.services.mozilla.com/D122819
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
Though the test funtion is called twice since the parent document reloads the
iframe document, but the test will not run for the second call since it's
prevented by `testRunning` flag in test_bug851485.html.
Differential Revision: https://phabricator.services.mozilla.com/D122662
Scaling currently doesn't work in print preview tests. This adds a test that
will begin to fail if scaling gets fixed, to tell us to enable the actual
scaled content test instead.
See bug 1725486 for the scaling issue.
Differential Revision: https://phabricator.services.mozilla.com/D122292
This test was disabled for some sort of failure on Windows ASAN configurations,
several years ago.
The bug doesn't have details on the failure, but it's likely the failure was a
version of the same race condition that turned up (and was recently fixed) in
bug 1720485. So, let's see if we can reenable this test on Windows ASAN now.
Differential Revision: https://phabricator.services.mozilla.com/D122314
In an incremental reflow, if a flex item has a valid bsize cache , we
skip its measuring reflow. However, we may still need to set relevant
bsize flags if the flex container is changing its definiteness in the
block-axis. See bug 1611303 comment 2 for an analysis.
This patch is playing safe by always calling SetHasBSizeChange() if we
override bsize for the item. Of course this can be solved in a more
sophisticated way by checking whether the item really has a block-axis
resize, but that means we'll need to duplicate a lot of logic in
FlexItem::NeedsFinalReflow().
Differential Revision: https://phabricator.services.mozilla.com/D122041
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
Touching layout.css.devPixelsPerPx during a reftest seems to cause a few
peculiarities:
- On OS X, increasing layout.css.devPixelsPerPx almost immediately runs into
bug 1263092, so I'm skipping that test there.
- Likewise, under Webrender on Android using a value > 1 causes some weird
display corruption issues during all subsequent tests running within the same
task (bug 1724608).
- We're randomly hitting the "can't mark frame dirty during reflow" assertion
again (bug 1724623).
Differential Revision: https://phabricator.services.mozilla.com/D122058
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
And make sure the caret ends up being visible, rather than _not_
visible.
This should be implementable on windows as well. It seems macOS doesn't
have a timeout thing.
Differential Revision: https://phabricator.services.mozilla.com/D122132
This takes the logic used for Image/CanvasLayer::ComputeEffectiveTransforms and uses it to get matching rendering for the Paint path.
Depends on D122175
Differential Revision: https://phabricator.services.mozilla.com/D122176
nsPresContext has a flag that caches the value of this pref, and the flag gets
updated in the next refresh driver tick after a pref-change occurs. Right now
we don't have a strong guarantee that the flag will have been updated by the
time the test assumes that it has, which is why we're seeing intermittent
failures.
This patch adjusts the test so that it waits for a double-rAF before proceeding
from its pref adjustment. I believe this is the recommended way of forcing &
waiting-out at least one refresh driver tick; and this should let the test
reliably assume the pref-adjustment has taken effect.
Differential Revision: https://phabricator.services.mozilla.com/D122169
This is useful so that author rules for :autofill also work for the
autofill preview.
It also makes the UA sheet in forms.css simpler (otherwise we'd need to
tweak the selectors to put :-moz-autofill-preview everywhere we put
:autofill).
Differential Revision: https://phabricator.services.mozilla.com/D122014
CachedBAxisMeasurement::mAscent caches the ascent of a flex item after
the measuring reflow, but the ascent may change after the final reflow
if the item is stretched and does some vertical alignment internally.
However, we don't cache the new ascent. Therefore, when we reflow the
item incrementally, if the CachedBAxisMeasurement::Key is valid, we just
skip the measuring reflow, and retrieve the wrong ascent from the cache.
Instead of fixing this bug by updating the cached ascent or rejecting
the ascent cache for a stretching flex item in block axis, this patch
removes the cache and sets ReflowOutput's BlockStartAscent() to the flex
item after the item's measuring reflow. (We've done the same after the
item's final reflow.) If the ascent is ReflowOutput::ASK_FOR_BASELINE,
we resolve in FlexItem::ResolvedAscent() anyway.
Differential Revision: https://phabricator.services.mozilla.com/D121404
Emilio Cobos Álvarez
stransky
Jeff Muizelaar
criss
Andrew Osmond
Jonathan Kew
Michelle Goossens
Nicolas Silva
Glenn Watson
Matt Woodrow
Ting-Yu Lin
Alexandru Michis
Gerald Squelart
Botond Ballo
Butkovits Atila
Daniel Holbert
Nazım Can Altınova
Andi-Bogdan Postelnicu
Hiroyuki Ikezoe
Sebastian Hengst
Brindusan Cristian
Marian-Vasile Laza
Cosmin Sabou
Timothy Nikkel
Gijs Kruitbosch
Masayuki Nakano
Dzmitry Malyshau
Nicklas Boman
Patrick
Emily McDonough
Iulian Moraru
Olli Pettay
Mats Palmgren
Jan Henning
Mike Hommey