Part of how invalidation works with WebRender is that we assume frames
with a WebRenderUserData object attached to them are in view. This means
for images that we must ensure we create an empty
WebRenderImageProviderData object even when we have no provider or
surface for display. This will allow us to invalidate properly when we
get the FRAME_COMPLETE notification from imagelib indicating that the
redecode has completed.
Differential Revision: https://phabricator.services.mozilla.com/D135077
This shouldn't change behavior but makes following the code a bit
easier. There's no point in using callbacks for touch-action as:
* We return the computed flags anyways.
* Each caller wants to do something different.
* (more importantly) The callback gets called synchronously.
So move the relevant code to TouchActionHelper and make the callers deal
with the flags as they please. I've preserved the behavior of only doing
the thing if the flags array is non-empty.
Differential Revision: https://phabricator.services.mozilla.com/D134933
The assertion here was added during the iterator refactoring in bug 1732349,
but is actually bogus. The old code would have returned via the MOZ_TRY_VAR
that wrapped the call to blockFrame->GetLineNumber(); that's replaced by
iter->FindLineContaining(), so we should now check for an error there and
similarly just return to the caller, not assert.
Differential Revision: https://phabricator.services.mozilla.com/D134950
The background we have on why this exists is in the code comments of the code
that's being removed, and in:
https://bugzilla.mozilla.org/show_bug.cgi?id=193001#c91
It seems very unlikely that this code is necessary. It's run for silent
printing when the new UI is enabled and E10s is disabled. If it was really
necessary it seems likely we'd have seen breakage in our much more common use
cases.
Differential Revision: https://phabricator.services.mozilla.com/D134936
The background we have on why this exists is in the code comments of the code
that's being removed, and in:
https://bugzilla.mozilla.org/show_bug.cgi?id=193001#c91
It seems very unlikely that this code is necessary. It's run for silent
printing when the new UI is enabled and E10s is disabled. If it was really
necessary it seems likely we'd have seen breakage in our much more common use
cases.
Differential Revision: https://phabricator.services.mozilla.com/D134936
We introduced this comment at the very beginning of the flexbox implementation.
Since then, WritingModes.h has obtained the utilities dealing with logical axis,
and CSSAlignUtils.h has supported CSS alignment for both flexbox and grid. All
the helper functions remaining in nsFlexContainerFrame.cpp are related to
flexbox, so I feel it's time we retire this comment.
NPOTB DONTBUILD because this patch changes only comments.
Differential Revision: https://phabricator.services.mozilla.com/D134652
In Flexbox spec 4.1, Example 3 [1]:
... since the absolutely-positioned box is considered to be
"fixed-size", a value of stretch is treated the same as flex-start.
Also, per Alignment 3 spec [2]:
The default fallback alignment for 'stretch' is 'flex-start'.
Thus, when computing the alignment for flexbox's abspos children in
CSSAlignmentForAbsPosChild(), we convert 'stretch' to 'flex-start', and let the
subsequent logic convert 'flex-start' to either 'start' or 'end', because
nsAbsoluteContainingBlock don't know how to deal with the flex-relative axis.
This patch makes us behave the same as Google Chrome on the modified testcases.
[1] https://drafts.csswg.org/css-flexbox/#abspos-items
[2] https://drafts.csswg.org/css-align/#valdef-align-content-stretch
Differential Revision: https://phabricator.services.mozilla.com/D134543
We now support scrollbar-gutter property. So for example, assume the scroll
container has "scrollbar-gutter:stable". When toggling the visibility of
inline-end scrollbar, we can skip the reflow for the scroll inner frame because
the available inline-size for it cannot change.
This patch teaches TryLayout() to consider the sizes of scrollbar gutter rather
than the (assumed) visibility of scrollbars when deciding the need to call
ReflowScrolledFrame().
Also, TryLayout() doesn't need to report an inconsistent layout unless
the (showHScrollbar, showVScrollbar) pair changes the sizes of scrollbar
gutters.
Differential Revision: https://phabricator.services.mozilla.com/D134373
Our mochitest harness doesn't specify meta viewport tags, so the test document
basically gets scaled down on mobile platforms, thus scroll position is aligned
with screen pixels (by ClampAndAlignWithLayerPixels in nsGfxScroll.cpp) rather
than CSS pixels, we should allow a half pixel difference on such platforms.
Differential Revision: https://phabricator.services.mozilla.com/D134349
Hiroyuki Ikezoe
Noemi Erli
Emilio Cobos Álvarez
Andrew Osmond
Jonathan Kew
Jonathan Watt
Butkovits Atila
Narcis Beleuzu
Neia Finch
Ting-Yu Lin
Mike Hommey
Kagami Sascha Rosylight
Cristian Tuns
Norisz Fay
Jeff Muizelaar
Gijs Kruitbosch
Mats Palmgren