Realistically we're not going to bother investigating these, I suspect,
and Thunderbird seems to hit these too often in their tests.
Differential Revision: https://phabricator.services.mozilla.com/D75683
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
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
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
In this case aAncestor is an SVGOuterSVGFrame, and aItem is a transform item for
its AnonChildFrame.
I'm not sure if it's quite expected to have such a frame generating a
transform...
Let me know if not and I can try to dig more, but this looks intentional given
the comment in nsSVGOuterSVGAnonChildFrame.
Differential Revision: https://phabricator.services.mozilla.com/D10955
--HG--
extra : moz-landing-system : lando
In some cases we get a gecko display list that looks like this:
WrapList with asr(<A>, <B>)
Item with asr (<B>) and clipchain(<something> [A])
In this case, we would initialize the WebRenderLayerScrollData for the
nested item using a stop-at ancestor of A (because that was the leafmost
ASR from the containing WrapList) but the item itself has an ASR of B,
which is an ancestor of A. So when walking up from B we'd never hit the
stop-at ancestor, and so we'd end up duplicating metrics from the
containing WRLSD onto the nested WRLSD. This generated an assertion
failure in the APZ code.
This patch detects this scenario and skips adding metrics on the nested
WRLSD. This produces an APZ tree equivalent to what the non-WebRender
path would produce.
MozReview-Commit-ID: 8eo6pzXXKBd
--HG--
extra : rebase_source : 0581c54c4d9fa6ca08249e42b306c7155022bec7
Botond Ballo
Emilio Cobos Álvarez
Kartik Gautam
Dorel Luca
Kartikaya Gupta
Razvan Maries
Jonathan Kew
Miko Mynttinen
Bogdan Tara
Geoff Brown
Ting-Yu Lin
Sylvestre Ledru
Charlie Marlow
Matt Woodrow
Cosmin Sabou
Noemi Erli
Narcis Beleuzu
Csoregi Natalia
Tyson Smith
Hiroyuki Ikezoe
Lee Salzman
Morris Tseng