This ensures that you can't observe an inconsistent state while we go
through the list.
It should also be marginally better as we don't build an array with all
the media queries unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D82260
We need to notify unconditionally because even if we didn't have
stylesheets, we could have responsive content which needs to change
source.
We need to notify the document even if the pres shell is not
initialized, as it might be our last chance to notify the responsive
content. This happens for printing, and makes my srcset test fail.
MANUAL PUSH: Somehow phabricator still thinks it needs review, even
though it was accepted.
Differential Revision: https://phabricator.services.mozilla.com/D81778
This is a straightforward conversion except that
`NS_SUBTREE_DIRTY(this)` can be written terser as `IsSubtreeDirty()`.
Differential Revision: https://phabricator.services.mozilla.com/D82811
If the root scrollframe has the zoomable flag set, it automatically returns
true from WantAsyncScroll which makes it the "primary" scrollframe, and
automatically gets a displayport. However, this can be undesirable in cases
where the root scrollframe is not actually scrollable (i.e. document content
doesn't overflow) because we don't actually need that displayport on the root
scrollframe and instead want it on a scrollframe that is actually scrollable.
This patch removes the behaviour of WantAsyncScroll returning true for such
scrollframes, but maintains the layerization changes needed to support zooming.
This reduces the set of differences between running with apz.allow_zooming on
and off, which in turn eliminates a bunch of test failures when that pref is
enabled.
Depends on D82777
Differential Revision: https://phabricator.services.mozilla.com/D82778
Per discussion on matrix, printing mState in hex format is
indecipherable. Remove it to reduce the rate of wrapping of a long line.
Differential Revision: https://phabricator.services.mozilla.com/D82606
This is equivalent to `aFrame->DumpFrameTreeLimited()` or `ftl` gdb /
lldb command. It appears only in nsIFrame.cpp, I doubt it's actually
used by developers.
Differential Revision: https://phabricator.services.mozilla.com/D82605
This affects the output of flex, grid, fieldset, etc.
Given a snippet like the following.
```
<fieldset style="position: relative; display: flex">
<div style="position: absolute">
```
Currently, the frame tree output looks as if the AbsoluteList is under
the FieldSet, but it's actually under the FlexContainer.
```
FieldSet(fieldset)(8)@7f4ae9e73508 ... <
FlexContainer(fieldset)(8)@7f4ae9e735c0 ... <
Placeholder(div)(1)@7f4ae9e73738
>
AbsoluteList 7f4ae9dcb8c0 <
Block(div)(1)@7f4ae9e73670 ... <
>
>
>
```
After this patch, the frame tree looks like:
```
FieldSet(fieldset)(8)@7f4ae9e73508 ... <
FlexContainer(fieldset)(8)@7f4ae9e735c0 ... <
Placeholder(div)(1)@7f4ae9e73738
AbsoluteList 7f4ae9dcb8c0 <
Block(div)(1)@7f4ae9e73670 ... <
>
>
>
>
```
Another minor difference is that for a empty container, the end angle
bracket is now on its own line, which is consistent with an empty block
frame's output.
This old output
```
FlexContainer(div)(4)@7f4ae9e73390<>
```
becomes
```
FlexContainer(div)(4)@7f4ae9e73390<
>
```
Differential Revision: https://phabricator.services.mozilla.com/D82604
Make the following tweak so that they are consistent with others.
* Add a space before the open angle bracket. This is at the end of
`Block(div)(1)@7f10e25de5d0 ... <`
* Tweak nsLineBox format.
`line 7f10e25de808: count=1` becomes `line@7f10e25de808 count=1`.
* Tweak child list format.
`AbsoluteList 0x7f10e3c7e560` becomes `AbsoluteList@7f10e3c7e560`
Differential Revision: https://phabricator.services.mozilla.com/D82603
`ListChildLists` lives in nsContainerFrame because I'm going to use it
to improve nsContainerFrame::List() in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D82602
Note: This optimization saves us from doing an extra unnecessary reflow in the
mochitest test_bug1505254.html, so I'm adjusting that test to remove its
magical "+1" fudge-factor in its expectations (and the corresponding
explanatory comment). Similarly, I'm dropping the assertion-count for
crashtest 1488762-1.html because we now do a little bit less reflow work (and
hence assert a little bit less) in that test.
Depends on D78821
Differential Revision: https://phabricator.services.mozilla.com/D78822
Note: this patch doesn't change behavior of current mozilla-central - it's just reordering some logic, basically.
Background/explanation: in current mozilla-central, we intentionally force a
"final reflow" for flex items (i.e. we return true from NeedsFinalReflow) if we
see that there's a constrained AvailableBSize (i.e. if we're fragmenting). However, the
logic to do that is buried within a basically-unrelated "if
(HadMeasuringReflow())" special case.
This patch pulls that check out of this unrelated special-case, so that we
detect the constrained AvailableBSize earlier and return earlier (indicating
more eagerly/up-front that we need a final reflow).
This patch is necessary because a later patch in this queue will add additional
special cases to FlexItem::NeedsFinalReflow, which will aim to make us *skip*
the final reflow in more cases. But for now, we want this
contrained-AvailableBSize check to "dominate" and eagerly force a reflow,
regardless of that soon-to-be-added logic.
Differential Revision: https://phabricator.services.mozilla.com/D78821
When a document has a fullscreen element, zooming is disabled, so we don't need
to build the async zoom container. But also, fullscreen is implemented via
hoisting the fullscreen element out of the normal layout flow, and making it
position:fixed. If the nsDisplayAsyncZoom display item is still in the display
list, it has a clip that doesn't account for fullscreen-ness, but still wraps
the nsDisplayPositionFixed items that are rendering the fullscreen elements.
This can result in hit-testing failing on those fullscreen items, because the
nsDisplayAsyncZoom item incorrectly clips away hit-test points. Instead, a
simple solution here is to just skip building the nsDisplayAsyncZoom item
entirely when in a fullscreen state.
Differential Revision: https://phabricator.services.mozilla.com/D82422
nsTArray::StableSort() requires the Comparator to be a class/struct with
Equals() and LessThan() members, or a tri-state function like strcmp.
This patch adapts the original comparators to tri-state functions to
fulfill this contract.
Using StableSort() can also avoid the array bound checking in the array
iterator as described in bug 1147091 comment 8.
Change the include to <limits> because std::stable_sort is removed but
we still use std::numeric_limits.
Differential Revision: https://phabricator.services.mozilla.com/D82118
Both methods are implementation details specific to this iterator, not
public interfaces that can be cooperated with C++ standard library, so
move them into private section.
Differential Revision: https://phabricator.services.mozilla.com/D82117
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
Instead of using overflow:hidden on the body to hide the scrollbar, this
patch sets scrollbar-width:none on the html element. In some cases
overflow:hidden is set on non-root scrollers (i.e. div elements); in those
cases it is replaced by overflow:scroll;scrollbar-width:none to get an
equivalent effect.
One test had a pre-existing visible scrollbar on a nested scrollframe, but
which started failing with a small fuzz difference. I left the scrollbar as-is
and added an annotation to the reftest.list file.
Note that this only updates the tests that use reftest-async-scroll as those
were the cases that were easily detectable, and causing problems with the
apz.allow_zooming=true pref.
Differential Revision: https://phabricator.services.mozilla.com/D82032
Instead of using overflow:hidden on the body to hide the scrollbar, this
patch sets scrollbar-width:none on the html element. In some cases
overflow:hidden is set on non-root scrollers (i.e. div elements); in those
cases it is replaced by overflow:scroll;scrollbar-width:none to get an
equivalent effect.
One test had a pre-existing visible scrollbar on a nested scrollframe, but
which started failing with a small fuzz difference. I left the scrollbar as-is
and added an annotation to the reftest.list file.
Note that this only updates the tests that use reftest-async-scroll as those
were the cases that were easily detectable, and causing problems with the
apz.allow_zooming=true pref.
Differential Revision: https://phabricator.services.mozilla.com/D82032
Instead of checking for the visual viewport *size* being set, we check for
the *offset* being set. This makes more sense becuase we're going to be
reading the offset, not the size.
Depends on D81740
Differential Revision: https://phabricator.services.mozilla.com/D81741
This adds another case to this test, which is specifically intended to bypass
any short-circuit resulting from the clamped scroll offset being the same as
the scrollframe's existing scroll offset. The pre-existing case in the tests
shortens the scrollframe to be non-scrollable, so the clamped mRestorePos for
the scrollframe is 0, which is the same as the default scroll position of the
reconstructed scrollframe. The new case ensures the clamped mRestorePos is
greater than zero, to verify that scroll restoration works as intended in that
scenario as well.
Differential Revision: https://phabricator.services.mozilla.com/D81739
For some reason that I don't want to dig into after a whole day of
debugging, nsDocumentViewer::GetGlobalPrintSettings always returns a new
object. Make sure to get a hand on the initial settings objects and use
that. That way we can remove the XXX comment, and use the print
settings as expected, which is useful because I'm going to add a test
whose reference is using background-color, and I need to change the
settings for us to print backgrounds.
Differential Revision: https://phabricator.services.mozilla.com/D81776
Aligning the displayport position in large increments can cause issues when the displayport is small enough to be smaller than the alignment itself. The risk is higher for small frames with no displayport margin as the alignment might have previously be rounded up to 512. Luckily not having margins is an indication that we aren't trying hard to benefit from APZ and a large alignment isn't benefiting us. This patch takes that into consideration and defaults to small alignements when there is no margins. The alignment is also rounded to a multiple of 256 instead of 512 to further reduce the likelihood of running into issues with small displayports.
Differential Revision: https://phabricator.services.mozilla.com/D80614
Apply the fix for bug 1592416 to submenus.
This adds the NSWindowCollectionBehaviorMoveToActiveSpace behavior to
submenu popups so that they override the "Assign To" space setting and display
on the active space. And, when mutiple displays are in use, recreates the
submenu widget each time it is displayed.
Differential Revision: https://phabricator.services.mozilla.com/D81812
It's incorrect to use childFrame's next sibling to check whether we have
more children since we iterate the children with respect to the CSS
'order' property.
Rather than creating a new flex line immediately, we keep a boolean when
a flex item requested "break-after", and create a new flex in the next
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D81283
When sorting frames in DOM order, we need to be careful to avoid using
an anonymous flex item's content node to make ordering decisions;
otherwise, all such items would incorrectly end up being sorted to the
front of the list. We need to dig through it to find the content node
that was wrapped in the anonymous wrapper, and use that content node for
sorting/ordering.
Differential Revision: https://phabricator.services.mozilla.com/D81001
Also, rename it to GetFirstNonAnonBoxInSubtree() to reflect its
functionality more precisely that it can return the argument aFrame
itself.
Differential Revision: https://phabricator.services.mozilla.com/D81000
Note that on Chrome table-row-pagination-001-print.html doesn't generate the
second page at least in the print preview. The second page is actually just a
blank page, but the height of a table element in the test is `160%` so that
there should be overflowed area from the first page.
It may be possible that it's an optimization in Chrome to reduce paper
consumption, but the second page in the reference, it's also a blank page, is
generated in the print preview, so I suppose it's either a bug or an
inconsistent optimization in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D81635
It's incorrect to use childFrame's next sibling to check whether we have
more children since we iterate the children with respect to the CSS
'order' property.
Rather than creating a new flex line immediately, we keep a boolean when
a flex item requested "break-after", and create a new flex in the next
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D81283
There's two code changes in this patch:
- The update to the visual viewport that was happening just before positioning
the fixed items gets moved to happen after determining the scrollbars for
the root scrollframe. This moves it a little bit earlier, to basically the
earliest point at which the visual viewport can actually be computed, since
it depends on the presence of the root scrollframe's scrollbars.
More importantly, this change sets the visual viewport without checking to
see if one was already set, as the old code did. This means every reflow
of the root scrollframe on a presShell with an MVM will now have a visual
viewport set. Previously the visual viewport would only get set for the first
time when the MVM got a load or first-paint event, and then would get updated
for subsequent reflows. The net effect here is that the visual viewport is
set earlier, and this can sometimes eliminate extra reflows from after the
load event, because everything is already in a consistent state.
- The NotifyResizeReflow call to MVM is replaced by a NotifyReflow call that
runs before every reflow, instead of just on resizes. Note that the
NotifyReflow also doesn't update the visual viewport like NotifyResizeReflow
used to do, because that is taken care of by the above-mentioned code change
to set the visual viewport.
This is desirable because there are things that run during reflow that attempt
to read the display size from the MVM, and they were getting a zero size
for reflows that happened before the first resize or load/first-paint events.
Now they get a valid display size on every reflow, and so again this allows
fewer overall reflows as the code converges to a stable state faster.
Together these changes ensure that every reflow has access to up-to-date
properties (display size, mobile viewport size, visual viewport size) from the
MVM. This eliminates unnecessary reflows because of out-of-order computations
based on stale values and such. Therefore the number of reflows goes down,
which is reflected by the changes to the crashtest assertion counts.
Differential Revision: https://phabricator.services.mozilla.com/D81375
When positioning overlay scrollbars, the code was previously taking the
visual viewport size and scaling it back up to the composition size using
the resolution. This works because overlay scrollbars don't take up any
space, and so the visual viewport size is exactly equal to the composition
size divided by the resolution. However, it's simpler to just use the
composition size because we can get that easily enough. And this fixes the
scrollbar positioning on the very first reflow, before the visual viewport
has been set on the presShell.
Eventually this might make it easier to do this for non-overlay scrollbars
as well, since those do take up layout space, and can't be positioned using
the "VV size multiplied by resolution" quantity, as that doesn't exactly
equal the composition size.
Differential Revision: https://phabricator.services.mozilla.com/D81277
The TryLayout code uses the composition size to figure out if the
scrollbar is needed or not. It computes something similar to the visual
viewport size (but assuming no scrollbars are taking up space) to do this.
There's no reason this code should be depending on whether or not the
visual viewport size is set in the presShell, so we can just remove the
condition. That way even on the very first reflow, when the visual viewport
will definitely not be set, we can correctly determine if the scrollbars
need to be laid out or not.
Differential Revision: https://phabricator.services.mozilla.com/D81276
It leaves parent pointers nulled out when it really shouldn't when
cloning shared sheets (if there's another suitable parent, we should use
that instead of nulling out).
Fix the code in StyleSheetInfo::RemoveSheet to handle all cases
(including nulling out when removing the only remaining sheet), and rely
on that instead.
Differential Revision: https://phabricator.services.mozilla.com/D81569
Consider the case where we have an expired entry in the cache, and we
load a new document.
We get an speculative load from the HTML parser. That's great, and we
see the entry is expired and actually fired the load.
But then, we actually get to the load that the <link> element performs,
and we see that we've already performed this load, so instead of peeking
the in-progress load, we go ahead and peek the expired "complete" cache
entry, which is not what we want.
By marking a load as performed only once it has finished, we avoid the
complete sheet cache, and glom onto the existing load instead, which is
the correct thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D81318
Consider the case where we have an expired entry in the cache, and we
load a new document.
We get an speculative load from the HTML parser. That's great, and we
see the entry is expired and actually fired the load.
But then, we actually get to the load that the <link> element performs,
and we see that we've already performed this load, so instead of peeking
the in-progress load, we go ahead and peek the expired "complete" cache
entry, which is not what we want.
By marking a load as performed only once it has finished, we avoid the
complete sheet cache, and glom onto the existing load instead, which is
the correct thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D81318
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