In various parts of the picture and mask code, we were casting
the `clipped` rect to i32 (after rounding out). However, this
can cause overflow panics when the origin of the rect is too big.
Instead, treat the origin as f32 (which it was generally being
converted to anyway), and only cast the size part to be i32 as
required. This is safe since we know that the size has been
clipped to the visible screen, so will always be safe to cast
to i32.
Differential Revision: https://phabricator.services.mozilla.com/D80968
GenerateFrameLists.py uses FrameClasses.py as an input. We should add
FrameClasses.py in 'inputs' arguments so that whenever FrameClasses.py
is changed, the build system re-runs GenerateFrameLists.py.
Differential Revision: https://phabricator.services.mozilla.com/D81371
* It's easier to maintain the type aliases of in one place, i.e.
CSSOrderAwareFrameIterator.h, and the iterator's header itself doesn't
include a lot of headers that add complex dependencies to
nsGridContainerFrame.h.
* Make "jump to definition" functionality in editors work
correctly (rather than just jumping to those declarations.)
Differential Revision: https://phabricator.services.mozilla.com/D81281
When we call into LoadSheet when starting pending loads for a given
loader, it may be the case that the original loader may still not care
about the load. However some other loader will, so we can't defer this.
This was also causing our state to get out of sync, because if this
happened, then we'd fail to account for it in other loaders.
Differential Revision: https://phabricator.services.mozilla.com/D81119
* ctrl+d: Dump DOM tree (content). (Use "d" because "c" is for copy.)
* ctrl+f: Dump frame trees.
* ctrl+p: Dump frame trees in CSS pixels.
On macOS, the modified is cmd instead of ctrl.
Differential Revision: https://phabricator.services.mozilla.com/D81234
While it makes sense to do this when the visual viewport offset changes, it
doesn't make as much sense when the visual viewport size changes. The size can
change whenever non-overlay scrollbars are added or removed to the root
scrollframe, which is an operation that seems like it shouldn't interfere with
scroll anchoring at all.
Differential Revision: https://phabricator.services.mozilla.com/D81071
When meta-viewport support is enabled, the call to UpdateResolutionForFirstPaint
from RefreshViewportSize is followed by a call to ShrinkToDispalySizeIfNeeded,
which calls UpdateResolutionForContentSizeChange and uses the scrollable rect
size for the intrinsic scale computation. So the intrinsic scale computation
in UpdateResolutionForFirstPaint causes a transient state where the resolution
and visual viewport size is wrong. It is corrected immediately after, but
changing the visual viewport size like that ends up marking frames dirty for
reflow. Avoiding the transient state avoids those reflows, which is a nice
optimization.
Differential Revision: https://phabricator.services.mozilla.com/D80996
This patch adds the boolean pref mathml.stixgeneral_operator_stretching.disabled, which defaults to true iff nightly.
When the pref is true, stretched operators won’t be rendered with STIXGeneral, because we only use OpenType MATH tables (in fonts that have them) or the generic Unicode table.
When the pref is false, we continue to support STIXGeneral for stretched operators, but warn the author in devtools and bump the use counter (up to once per page). This only happens when a stretched operator actually uses STIXGeneral: not when we successfully render the operator with some other font earlier in the font-family stack, and not when STIXGeneral isn’t installed.
Differential Revision: https://phabricator.services.mozilla.com/D73833
Instead of having callers compute the cssToDev and pass it to the zoom/
resolution conversion functions, we can just do it in those functions directly.
Differential Revision: https://phabricator.services.mozilla.com/D80939
This is a hard diff to read but fundamentally a pretty simple patch. The old
UpdateResolution function had a giant if condition in the middle conditioned
on the update type. Inside the ViewportSize branch there was a further nested
if conditioned on mIsFirstPaint. The function got split into three, with each
new function holding one of the three main blocks of code, along with a copy
of the stuff before and after the if condition. And then I simplified each
function individually to remove unnecessary variables, add some early-exits
and reduce nesting levels, etc.
Depends on D80937
Differential Revision: https://phabricator.services.mozilla.com/D80938
This removes the two parameters to ShrinkToDisplaySizeIfNeeded and corresponding
parameters passed to UpdateResolution. The call site in nsGfxScrollFrame
gets the arguments from the MVM itself, so it seems silly to be getting things
from the MVM just to pass it back in. The other call sites are already in theMVM.
This change might be slightly less efficient because it re-computes the viewport
info when the caller might already have it but this isn't a hot code path so
I'm not too concerned.
Differential Revision: https://phabricator.services.mozilla.com/D80937
Handle grid track lists that are too large in CalculateRepeatFillCount. Check
for repeat tracks that begin or end past the maximum track limit in
InitRepeatTracks, and handle the possible size mismatch in nsComputedDOMStyle.
This may result in there being fewer than the maximum number of tracks again
after removing empty tracks in a repeat(auto-fit), but only limiting the track
count after removing empty tracks would leave the number of repeat tracks
unbounded (or require a separate limit on just the repeat track count).
Differential Revision: https://phabricator.services.mozilla.com/D76191
After the above, I don't think this is needed anymore, because we
shouldn't be looking at the widget size from layout.
It also shouldn't cause more reflows on desktop at least, because of the
early out in ResizeReflowIgnoreOverride before calling
SimpleResizeReflow().
Differential Revision: https://phabricator.services.mozilla.com/D80731
This should be equivalent because:
* Content viewer size and widget size should eventually be the same always
(modulo mid-resize, see bug 1645954).
* Only the root content document has a widget on android (the puppet widget).
* Only the root content document has a dynamic toolbar.
* We were only calling this on the root document, which has no parent pres
context (at least with e10s). Without e10s we could have a chrome
prescontext (not sure it that ends up being a parent in the pres context
chain), but we should never change the resolution of that one, so I think
aScaleContentViewerSize is just useless.
This avoids having two sources of truth by always checking the content viewer
size without subtracting the dynamic toolbar max size.
Differential Revision: https://phabricator.services.mozilla.com/D80723
In FindBestBalanceBSize(), suppose we have aUnboundedLastColumn equals
to true, and the measuring reflow of all the columns is feasible. This
setting represents the most common scenario of multi-column layout as
the multi-column footnote on Wikipedia.
We used to use 600 as the extra block-size added to the estimate column
block-size. However, if the first guess of the column block-size, say
G1, is infeasible, the feasible block-size is still bound to the sum of
all columns S. That leaves us a massive range between G1 and S to
search.
We don't want to use a larger fixed extra block-size. Although it can
reduce the possibility of failing the first guess, but for cases where a
smaller extra block-size is sufficient, it increases the search range
and the iteration number before the binary search converges.
Instead, we can spend the first few iterations doubling the extra
block-size E added to the estimate column block-size until we find the
first feasible block-size. This gives us a smaller upper bound S / N +
E, where N is the number of columns.
Differential Revision: https://phabricator.services.mozilla.com/D80571
The motivation is to replace mFrames.GetLength() in
FindBestBalanceBSize() since it is O(N), where N is the number of
columns.
Also, counting the column number from 1 so that it matches mUsedColCount
without needing to subtract 1 at some places.
Differential Revision: https://phabricator.services.mozilla.com/D80569
* childContentBEnd: this value can be larger than
kidDesiredSize.BSize(wm) if -moz-column-content anonymous blocks has a
child which is overflow-incomplete.
* mLastBSize: last column's block-size is important in column balancing
algorithm because it sets mKnownInfeasibleBSize when a balancing
iteration is feasible.
* The iteration count in column balancing. This is an easy way to
observe column balancing performance.
Differential Revision: https://phabricator.services.mozilla.com/D80568
accessible/tests/browser/bounds/browser_test_resolution.js started flipping on the pref ui.useOverlayScrollbars in order to run it's test properly.
Changing the pref ui.useOverlayScrollbars is first handled in the look and feel code. A "look-and-feel-changed" notification is sent out. PresShell::Observe receives this and calls nsPresContext::ThemeChanged. This queues a runnable. This will eventually reflow all scrollframes via the call MediaFeatureValuesChangedAllDocuments in nsPresContext::ThemeChangedInternal. But before that can happen we can paint, and |LookAndFeel::GetInt(LookAndFeel::IntID::UseOverlayScrollbars)| will return the new value. Which means ScrollFrameHelper::AppendScrollPartsTo will place the scrollbars at their new position in the display list and nothing has marked the scrollbars as modified so we fail to merge.
Differential Revision: https://phabricator.services.mozilla.com/D80585
We did not pass FLAG_HIGH_QUALITY_SCALING down to the document used to
rasterize the SVG to a surface, resulting in embedded raster images to
not use high quality downscaling.
Differential Revision: https://phabricator.services.mozilla.com/D56422
If two loading documents hit the sheet cache and we coalesce the
resource load, there's nothing that prevents the load event on the
second document from firing right now, and there should be.
While at it, also fix the handling of the pending load count, though
it has no correctness impact on the particular test we're fixing here...
We were never decrementing it, which is of course wrong. However it
kinda ended up working because it just causes us to not defer more
loads.
The new assertions and responsibility of the counter should ensure it
stays correct.
Differential Revision: https://phabricator.services.mozilla.com/D80583
So as to make sense in a world where we can coalesce loads across
documents. The per-load object is the SheetLoadData, so this way we
guarantee that we fire the right events in presence of the load
coalescing that the SharedStyleSheetCache does.
Differential Revision: https://phabricator.services.mozilla.com/D80380
This shouldn't have any behavior change, but it makes the code make a
bit more sense. Rather than counting inline stylesheets like a pending
load, we won't (but note that any @import inside it will).
The SheetLoadData::mURL it's supposed to be the url of the stylesheet,
so for StyleSheet::Replace it should be null.
Differential Revision: https://phabricator.services.mozilla.com/D80379
The top end of the scrollbar seems off by a subpixel amount. Some initial
investigation is documented in bug 1646527 and points to a WR internal bug.
Depends on D80089
Differential Revision: https://phabricator.services.mozilla.com/D80090
I looked at the assertion stacks and checked that there were no new kinds of
assertions being triggered, just more of the same old assertions. Seems
reasonable that as the desktop behaviour moves closer to mobile (by turning
on visual viewport codepaths) the assertion count will also match that of
mobile.
Depends on D80088
Differential Revision: https://phabricator.services.mozilla.com/D80089
This fixes a number of scroll-anchoring WPT tests that otherwise fail with the
final patch in this patchset. This patch also fixes a pre-existing failure on
Android, so we remove the corresponding failure annotation here. The guard
being added already exists on some of the codepaths leading to this function,
and is used to short-circuit other bits of code. However, there are still some
codepaths that end up in this function with a zero display size, and it's better
to leave the visual viewport unset in the presShell than to set it to a zero
size.
Depends on D80086
Differential Revision: https://phabricator.services.mozilla.com/D80087
There's a lot of documents that get created (about:blank and friends) and this
makes it easier to figure out which MVM we actually care about.
Differential Revision: https://phabricator.services.mozilla.com/D80085
This makes it easy to see why your test is not failing without your
patch, for example ;)
Note that we log only when the URIs are the same, which
I think is a reasonable compromise in verbosity.
Differential Revision: https://phabricator.services.mozilla.com/D80288
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
The top end of the scrollbar seems off by a subpixel amount. Some initial
investigation is documented in bug 1646527 and points to a WR internal bug.
Depends on D80089
Differential Revision: https://phabricator.services.mozilla.com/D80090
I looked at the assertion stacks and checked that there were no new kinds of
assertions being triggered, just more of the same old assertions. Seems
reasonable that as the desktop behaviour moves closer to mobile (by turning
on visual viewport codepaths) the assertion count will also match that of
mobile.
Depends on D80088
Differential Revision: https://phabricator.services.mozilla.com/D80089
This fixes a number of scroll-anchoring WPT tests that otherwise fail with the
final patch in this patchset. This patch also fixes a pre-existing failure on
Android, so we remove the corresponding failure annotation here. The guard
being added already exists on some of the codepaths leading to this function,
and is used to short-circuit other bits of code. However, there are still some
codepaths that end up in this function with a zero display size, and it's better
to leave the visual viewport unset in the presShell than to set it to a zero
size.
Depends on D80086
Differential Revision: https://phabricator.services.mozilla.com/D80087
There's a lot of documents that get created (about:blank and friends) and this
makes it easier to figure out which MVM we actually care about.
Differential Revision: https://phabricator.services.mozilla.com/D80085
There's no need to put this in nsLayoutUtils since it's so closely bound
to presShell anyway. So we move it from being a static nsLayoutUtils function
that takes a PresShell pointer, to being a method on the PresShell itself.
Two functional changes here:
1. Don't run the MaybeReflowForInflationScreenSizeChange code unless the
visual viewport actually changes
2. Run the MaybeReflowForInflationScreenSizeChange if the visual viewport
is reset.
These functional changes can be logically thought of as "group the font-
inflation reflow stuff together with the other visual-viewport-triggered
reflow stuff".
Depends on D80040
Differential Revision: https://phabricator.services.mozilla.com/D80041
There are two parts here. One is the "backstop" in the scrollframe's
ReflowFinished callback, that recomputes the visual viewport size if layout
scrollbars are being used in the root scrollframe. This ensures that the
visual viewport gets resized properly after a reflow, possibly at the expense
of a second reflow to reposition fixed-pos items.
There is also an update to the visual viewport during the reflow itself, after
we have reflowed the in-flow contents (including the root scrollframe) but
before we reflow the fixed-pos items. This allows us to avoid the second reflow
by using the new visual viewport for positioning the fixed-pos items correctly.
This early reflow also skips marking things for a second reflow.
This patch fixes a problem described in bug 1644271 comment 2, among other
things. Specifically, it ensures that when the scrollbar properties (e.g.
maxpos, minpos) are computed, they are computed using an up-to-date visual
viewport size. The up-to-date visual viewport size correctly excludes the space
taken up by non-overlay scrollbars, which wasn't happening without this patch.
Depends on D80039
Differential Revision: https://phabricator.services.mozilla.com/D80040
mLastPos is supposed to be updated by querying the visual viewport offset from
the presShell. However because of the way the visual viewport offset is updated,
this doesn't return a nonzero value until after APZ sends back a repaint request.
So this patch modifies the query to also check if there's any pending visual
viewport offset update being sent from the main thread, and use that. It also
modifies the scroll restoration code to request a properly clamped visual
scroll offset, so that the value stored as "pending" is not just the unclamped
restore destination.
Depends on D80038
Differential Revision: https://phabricator.services.mozilla.com/D80039
The existing comment in BrowserChild::RecvUpdateDimensions may have been
accurate at some point in the past, but I'm seeing cases where setting
the content viewer size itself triggers a reflow. Since the widget size
hasn't been updated yet, the reflow uses some stale values and produces
incorrect outcomes. This patch ensures both the content viewer and widget
get their sizes updated first, and only then do we do the reflow.
Differential Revision: https://phabricator.services.mozilla.com/D79885
With containerless scrolling we generally always want this clip on the layer,
since there is no container. However on Android apparently we don't want this,
because it seems to break the setVerticalClipping API used by the dynamic
toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D80054
We've had nsNativeBasicTheme enabled since 75, and all reported issues
were fixed real soon (and I haven't heard of any of them recently).
Given the non-native theme is likely changing in the future, I'd rather
not maintain three themes for Android :)
Differential Revision: https://phabricator.services.mozilla.com/D80105
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
Now CompositorAnimationStorage::GetAnimatedValue() and SetAnimatedValue()s
are called on the sampler thread in case of WebRender, are called on the
compositor thread in case of non WebRender, so we drop assertions of
IsInCompositorThread check there. A mLock.AssertCurrentThreadOwns call in
each function should make sure the function gets called on the
sampler/compositor thread with acquiring the lock.
One caveat in this change is that in case we try to get an animation value via
nsIDOMWindowUtils.getOMTAStyle(), we do sample animations on the _compositor_
thread and we never call UpdateDynamicProperties, which means if it gets called
in testing refresh driver mode, visual results will differ from what the value
returned by the getOMTAStyle should look like. But it should be fine because we
disallow using any chrome priviledge APIs in reftests and also we will never use
the testing refresh driver mode in the reftest harness. Also in mochitests the
visual results' differences might make people confusing if the person can notice
it, but in principal getOMTAStyle() is designed to get computed animating values
so that it doesn't matter what the visual result is.
Differential Revision: https://phabricator.services.mozilla.com/D79982
We're converting to nscoord in some places unnecessarily, reducing the
precision of the computed value we return.
This makes some tests unnecessarily fail if we change the base of
nscoord.
Differential Revision: https://phabricator.services.mozilla.com/D79996
Handle grid track lists that are too large in CalculateRepeatFillCount. Check
for repeat tracks that begin or end past the maximum track limit in
InitRepeatTracks, and handle the possible size mismatch in nsComputedDOMStyle.
This may result in there being fewer than the maximum number of tracks again
after removing empty tracks in a repeat(auto-fit), but only limiting the track
count after removing empty tracks would leave the number of repeat tracks
unbounded (or require a separate limit on just the repeat track count).
Differential Revision: https://phabricator.services.mozilla.com/D76191
Andrea Marchesini
longsonr
Glenn Watson
Kagami Sascha Rosylight
Mihai Alexandru Michis
Ting-Yu Lin
Kartikaya Gupta
Emilio Cobos Álvarez
Coroiu Cristina
Timothy Nikkel
Hiroyuki Ikezoe
Daosheng Mu
Narcis Beleuzu
Delan Azabani
Lee Salzman
Emily McDonough
manas
Honza Bambas
Andrew Osmond
tkhan
Simon Giesecke
Jonathan Kew
Razvan Maries
Edgar Chen
Cosmin Sabou
Markus Stange
Butkovits Atila
Brindusan Cristian
Gijs Kruitbosch