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
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
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
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
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
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
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
Now that there is no Gecko-contributed background color in the window any more,
there's nothing that needs to be cleared away. This simplifies things.
Differential Revision: https://phabricator.services.mozilla.com/D51464
This seems to match what other browsers do, and seems saner layout-wise,
at least.
I only annotated outline-width-interpolation.html because it's already
fixed upstream in:
8a489657bc
Differential Revision: https://phabricator.services.mozilla.com/D75360
If |nsDisplayItem::CreateWebRenderCommands()| returns false, the items that have been pushed to |DisplayListBuilder::pending_chunk| need to be cleared, because the item will be pushed as an image instead. This happens, for example, when nsDisplayText encounters unsupported features.
Differential Revision: https://phabricator.services.mozilla.com/D77095
Previously, WR would attempt to detect at the start of frame
building if the spatial node of any picture cache contained
a non-axis-aligned transform, and disable picture caching in
that edge case.
However, picture caching can't (currently) be disabled when the
native compositor is active. In this mode, picture caching was
force enabled, causing an assertion failure due to unexpected
coordinate systems when updating pictures.
This patch changes the way the detection of scroll root logic
works such that we don't consider any scroll frame inside a
reference frame to be a valid scroll root for picture caching
purposes. Thus it's not possible to create a picture cache
where the reference spatial node has a non-axis-aligned transform.
Differential Revision: https://phabricator.services.mozilla.com/D75890
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
The rects need to be transformed already by the time they are
used in MarkOutOfFlowFrameForDisplay() to see if the out of
flow frame intersects them.
Differential Revision: https://phabricator.services.mozilla.com/D75664
longsonr
Kagami Sascha Rosylight
Kartikaya Gupta
Hiroyuki Ikezoe
Narcis Beleuzu
Brindusan Cristian
Simon Giesecke
Emilio Cobos Álvarez
Mihai Alexandru Michis
Timothy Nikkel
Andrew Osmond
Razvan Maries
Markus Stange
Dorel Luca
Miko Mynttinen
Glenn Watson
Ting-Yu Lin
Botond Ballo