This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
This tests triggers the problem that we ran into with bug 1565231. It
triggers the somewhat rare scenario where we update a blob and have a
new visible area.
Often changes in the visible area cause a bounds change which causes a
complete rebuild of the blob.
Differential Revision: https://phabricator.services.mozilla.com/D38550
--HG--
extra : moz-landing-system : lando
This patch adds an assertion that documents the invariant that this code
needs to maintain to manage the line iterator correctly. Failing to
meet that invariant would also cause additional assertions in my
work-in-progress on bug 1300293.
It then adds two assignments of mPrevFrame to null that make that
assertion hold.
The first assignment to null is tested by a number of tests already in
our test suite, including
layout/reftests/w3c-css/received/css-writing-modes/block-plaintext-004.html
and layout/reftests/bidi/unicode-bidi-plaintext.html , which would hit
the added assertion if that assignment to null were not present.
The second assignment to null was untested in our test suite (though it
showed up when doing view-source: of https://html.spec.whatwg.org/ ), so
I've added a reftest (1567036-1.html) that hits the added assertion if
that second assignment to null is not present.
Differential Revision: https://phabricator.services.mozilla.com/D38438
--HG--
extra : moz-landing-system : lando
If the embedding element uses `object-fit`, then that indicates it's precisely
positioning and/or sizing the embedded SVG document's viewport to fit inside
the embedding element's content area. So, when the internal SVG viewBox
changes, then the embedding element needs to redo that positioning/sizing. For
now, this specifically requires a reflow (and in particular, the nsViewManager
adjustments at the end of nsSubDocumentFrame::Reflow).
Differential Revision: https://phabricator.services.mozilla.com/D37910
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
This reduces a bit of code complexity, fixes bugs where we weren't
reflowing enough, and optimizes additional cases that we couldn't
optimize in the past.
Co-authored-by: Chris Pearce <cpearce@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Differential Revision: https://phabricator.services.mozilla.com/D37610
--HG--
extra : moz-landing-system : lando
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Co-authored-by: Chris Pearce <cpearce@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D37609
--HG--
extra : moz-landing-system : lando
Currently items are painted with a context that has a transform of
-mLayerBounds.TopLeft(). This means that if TopLeft() changes the commands
will be in the wrong place because the -TopLeft() offset is baked into the
recording.
I don't think we've ever needed to support painting without this transformed
baked in so there were some infrastructure changes that needed to be made to
make this possible. Most of the problems come from the use of
gfxContext::GetClipExtents which expose the bounds of the underlying surface.
The biggest of these was fixed by the CreateClippedDrawTarget rewrite. The rest
should be handled by ensuring that the DrawTarget has bounds that are at least
as big as the union of the individual item bounds. i.e. GetClipExtents should
never intersect with bounds of the item.
This change has a couple of parts:
1. Store mLayerBounds.TopLeft() in the recording so that it will be subtracted
during replay
2. Use mLayerBounds as the Rect of the RecordingDrawTarget
3. Don't include mLayerBounds.TopLeft() in the transform during recording.
4. Adjust the dirty rect by recordingOrigin before we use it as a clip so that
it stays in the right place.
5. In PaintContainerItem the bounds parameter of PushLayer is in device space
so we need to account for the shift in the location of device space in the
DrawTargetRecording.
Differential Revision: https://phabricator.services.mozilla.com/D37513
--HG--
extra : moz-landing-system : lando
Inheriting block-size is just plain wrong in presence of calc or percentages.
The layout without these rules also matches other browsers, so I see no reason
not to do this.
Differential Revision: https://phabricator.services.mozilla.com/D37746
--HG--
extra : moz-landing-system : lando
Inheriting block-size is just plain wrong in presence of calc or percentages.
The layout without these rules also matches other browsers, so I see no reason
not to do this.
Differential Revision: https://phabricator.services.mozilla.com/D37746
--HG--
extra : moz-landing-system : lando
Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:
* It doesn't regress bidi rendering when the pref is disabled (before, the pref
would prevent plaintext.css from applying altogether).
* It's consistent with the way view-source docs work.
* It doesn't use non-standard stylesheet APIs to toggle the stylesheet
(bug 1260720).
Differential Revision: https://phabricator.services.mozilla.com/D37742
--HG--
extra : moz-landing-system : lando
Looks like some users use it, and it's not too much effort to support. This is
somewhat simpler, and IMO better than what existed before bug 1514655 because:
* It doesn't regress bidi rendering when the pref is disabled (before, the pref
would prevent plaintext.css from applying altogether).
* It's consistent with the way view-source docs work.
* It doesn't use non-standard stylesheet APIs to toggle the stylesheet
(bug 1260720).
Differential Revision: https://phabricator.services.mozilla.com/D37742
--HG--
extra : moz-landing-system : lando
Update the existing reftests to not use 3 valued syntax.
I run the script to update the syntax in
`layout/reftests/w3c-css/submitted/images3/*`,
`layout/reftests/w3c-css/submitted/masking/*`,
`layout/reftests/xul/*`, and
`layout/reftests/webm-video/*`:
```
function rename() {
find layout/reftests/\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.html" -or\
-name "*.xul" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "object-position: top 3px center" "object-position: top 3px left 50%"
rename "object-position: center right 25%" "object-position: top 50% right 25%"
```
For `layout/reftests/svg/svg-integration/clip-path/*`, I just manually
update them.
Differential Revision: https://phabricator.services.mozilla.com/D37125
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
Before this patch, we would use fallback for all border images. Now for
all but vector images we will use the WebRender border images
primitives. Vector images are an exception because the fallback is
clever in that it upscales the vector image and clips to only draw the
region it requires. This avoids artifacting but to do something similar
for WebRender as it is currently defined, we would increase our CPU and
memory footprint as we would need to produce the entire vector image
upscaled, not just the parts we need. In the future we should change
WebRender to accept different image resources for each of the segments.
Differential Revision: https://phabricator.services.mozilla.com/D37093
Without the change a green rectangle in each reftest in this commit covers whole
screen.
Differential Revision: https://phabricator.services.mozilla.com/D37328
--HG--
extra : moz-landing-system : lando
Due to the sheer number of tests that exhibit a random fuzz with maxDifference=1
and maxDifference=2 with WR on Android, it's easier to just tweak the harness
to autofuzz these away. This adds machinery to do so, and also adds a new
annotation that can be used to disable the autofuzzing on specific tests.
Depends on D36794
Differential Revision: https://phabricator.services.mozilla.com/D36796
--HG--
extra : moz-landing-system : lando
Due to the sheer number of tests that exhibit a random fuzz with maxDifference=1
and maxDifference=2 with WR on Android, it's easier to just tweak the harness
to autofuzz these away. This adds machinery to do so, and also adds a new
annotation that can be used to disable the autofuzzing on specific tests.
Depends on D36794
Differential Revision: https://phabricator.services.mozilla.com/D36796
--HG--
extra : moz-landing-system : lando
The sideways-rl test is fuzzy (even without webrender) because we get a 1px discrepancy
in baseline positioning for the rotated text; presumably the rotation done by sideways-rl
and that done by CSS transform end up rounding the center of rotation differently. That's
probably a bug we should fix, although offhand I'm not sure which is more correct; anyhow,
it's a separate issue from the bug here.
When WebRender is enabled, the test/reference difference is much greater because many of
the glyphs are wildly misplaced, not just shifted by 1px, so it still fails despite the
fuzzy() annotation.
Differential Revision: https://phabricator.services.mozilla.com/D36793
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
Note that this is an imperfect implementation, in that it doesn't exactly
match the sizing behavior of a truly empty `<select>` element. I've filed
followup bug 1562057 on that. However, the behavior that's implemented
here *does* successfully make us ignore a `<select>`'s contents for sizing
purposes, and it's much better than what we do currently (which is pretty
broken via inheriting a partial `contain:size` implementation from our
parent class, nsBlockFrame).
Differential Revision: https://phabricator.services.mozilla.com/D36253
--HG--
extra : moz-landing-system : lando
These changes are needed for consistently green runs with the new emulator with
"-gpu on".
Most changes are simple removal of fuzzy-if(geckoview) but I also needed to add
at least one new fuzzy-if.
In this configuration we can run reftests in just 2 chunks (20 minutes each on
opt/30 minutes on debug).
Differential Revision: https://phabricator.services.mozilla.com/D36258
--HG--
extra : moz-landing-system : lando
The arguments for the respective container elements apply to their immediate
child items, too: They establish a new formatting context as well and presumably
represent page content that can be considered to be logically separate enough to
warrant individual consideration for font inflation.
Differential Revision: https://phabricator.services.mozilla.com/D35881
--HG--
extra : moz-landing-system : lando
Our algorithm for dividing a page up into separate font inflation flow roots
seems mostly based on the idea that a new Block Formatting Context (BFC) should
go hand in hand with a font inflation flow root.
Flex containers so far didn't follow that rule, since they technically create a
new *Flex* Formatting Context (FFC) and possibly also because nobody thought
about font inflation when implementing nsFlexContainerFrame.
This leads to all flex containers being counted against the next higher-level
flow root, meaning that a lot of small flex containers can get inflated if their
sum total of text *collectively* exceeds the font inflation threshold.
This alone is likely undesired most of the time, but is then also aggravated by
the fact that our flexbox behaviour under font inflation is somewhat buggy (bug
1142461).
As apart from the different layout rules inside the container, a FFC behaves
very much like a BFC in that it establishes a new formatting context, flex
containers should therefore correspondingly become font inflation flow roots,
too, and therefore be considered individually for font inflation.
As far as I can tell, with this change we'll also match Blink's behaviour in
that regard.
For completeness's sake, we'll make grid containers follow the same principles,
even though hopefully grids on non mobile-friendly pages should hopefully be
somewhat rarer than flexboxes.
Differential Revision: https://phabricator.services.mozilla.com/D32622
--HG--
extra : moz-landing-system : lando
In this case, the desired end state is *no* inflation, so we don't need separate
ref-versions of the test pages - the only difference is in the prefs being used.
Differential Revision: https://phabricator.services.mozilla.com/D32621
--HG--
extra : moz-landing-system : lando
There is a natural tendency to add new tests at the bottom of the manifest, so
the comment about the lineThreshold pref wasn't entirely accurate anymore.
Differential Revision: https://phabricator.services.mozilla.com/D32620
--HG--
extra : moz-landing-system : lando
This change updates a large number of reftests to link to the
`/fonts/ahem.css` stylesheet. Each file contains a single additional
line before the first `<style>` element:
```
<link rel="stylesheet" type="text/css" href="/fonts/ahem.css" />
```
Differential Revision: https://phabricator.services.mozilla.com/D35958
--HG--
extra : moz-landing-system : lando
reftest manifests have ordering issues, re-organizing the fuzzy-if/random-if clauses to allow random-if to work.
Differential Revision: https://phabricator.services.mozilla.com/D36031
--HG--
extra : moz-landing-system : lando
It caused rendering issues just like a reftest in this commit. We don't know
the reason but fixing it will be some amount of work which couldn't be uplifted
to 68. So we just revert the change here now. Probably we should revisit the
problem once we got a bug report that the lack of the `transform-style: inherit`
causes rendering issues.
Differential Revision: https://phabricator.services.mozilla.com/D35946
--HG--
extra : moz-landing-system : lando
From the CSSOM View spec[1];
The scroll-behavior property of the HTML body element is not propagated to
the viewport.
The reason why this change fixes the test case in this commit is that we don't
have two different scrollable frames for <html> and <body> respectively if we
don't propagate scroll-behavior property from <body> to <html> so that we can
properly find the `flow root` of sticky position elements.
In other words, in the case where both of <html> and <body> have properties
that are propagated from <body> but they are different we have two scrollable
frames as a candidate of the 'flow root' for the sticky position element in
the test case, one is the scrollable frame for <html> and the other is the
scrollable frame for <body>. That means that
nsLayoutUtils::GetNearestScrollableFrame doesn't return what we want in some
places, for example we have a pretty similar issue in case of
overscroll-behavior which is bug 1561107.
Note that the test position-sticky-root-scroller-with-scroll-behavior.html is
almost copy-and-pasted from
/css/css-position/position-sticky-root-scroller.html [2] in wpt, the reason why
we put the test in /css/cssom-view is that there is a handy function to wait
for async scroll completion.
[1] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior
[2] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/testing/web-platform/tests/css/css-position/position-sticky-root-scroller.html
Differential Revision: https://phabricator.services.mozilla.com/D35739
--HG--
extra : moz-landing-system : lando
'<image>' elements will look at the current clip when painting. Puting one
of them at negative coordinates exposes potential bugs in the blob recoord work.
Differential Revision: https://phabricator.services.mozilla.com/D36072
--HG--
extra : moz-landing-system : lando
mark w3c-css/submitted/variables/variable-external-font-face-01.html as random-if on win7/debug
Differential Revision: https://phabricator.services.mozilla.com/D35653
--HG--
extra : moz-landing-system : lando
This patch does the same thing as bug 1548118 Part 3, but for
column-balancing-nested-000.html.
Differential Revision: https://phabricator.services.mozilla.com/D31674
--HG--
extra : moz-landing-system : lando
We're seeing occasional fuzzy-mismatch failures with a single pixel differing,
where an antialiased "a" serif overlaps an adjacent table border. Hopefully a
sans-serif font will reduce the likelihood of this fuzziness.
Differential Revision: https://phabricator.services.mozilla.com/D35266
--HG--
extra : moz-landing-system : lando
This patch implements the majority of the planned picture caching
improvements. It supports most of the functionality required to
(as a follow up) support OS compositor integration. It also improves
on the robustness and functionality of the previous picture caching
implementation.
There are some expected temporary performance regressions in
some cases (such as content that is constantly invalidating) and
during initial page render when many render targets must be drawn
to. These performance regressions will be resolved in follow up
commits by supporting multi-resolution tiles.
The scene is split into a number of slices, determined by the scroll
root of each primitive, which can be found by the primitive's
spatial node indices. If a scene contains too many slices, then
picture caching is disabled on the page, to avoid excessive texture
memory usage, and rendering falls back to rasterizing each frame.
The specific changes in this patch are:
* Support tile caches for multiple scroll roots, allowing the
entire page (including fixed divs and the main UI bar) to be
cached in most cases, in addition to the main content.
* Remove requirement to read tiles back from the framebuffer.
Instead, they are drawn into the picture cache target tiles,
and blitted to the screen. This is slightly slower than the
existing picture caching when content is constantly changing,
however this cost will disappear / become irrelevant when
the OS compositor integration work is complete.
* Switch picture cache render targets to be nearest sampled (they
are always rendered 1:1) and support depth buffer targets.
* Make use of the external scroll offset support to allow removal
of the primitive correlation hacks in the previous picture
caching implementation. Also allows storing of primitive
dependencies in picture space rather than world space, which
reduces floating point inaccuracies.
* Determine if each tile and picture cache can be considered
opaque. This is used to determine whether subpixel AA text
rendering is available on a slice, and for rendering optimizations
related to disabling blending and/or tile clears.
* Use the clip chain instance results from the recent visibility pass
work to determine clip chain dependencies. This results in fewer
clip item dependencies in tiles, which is faster to check validity
and reduces redundant invalidations.
* Remove extra overhead during batching related to batch lists,
and region iteration, as they are no longer required.
* Support PrimitiveVisibilityMask during batching. This allows a
single traversal of a picture (surface) root during batching to
efficiently construct multiple alpha batcher objects (typically
one per invalida tile).
* Picture caching is now handled implicitly by WR, depending on
the content of the scene. There is no requirement for client
code to manually select which stacking context should be cached.
* Simplify how clip chain / transform dependencies are tracked by
picture cache tiles.
* Support pushing / popping enclosing clip chain roots without
the need for a stacking context / picture in some cases. This
simplifies the logic to split the scene into multiple slices.
The main remaining work in this area is (a) extend the code to
optionally provide each slice as an input to the OS compositor
rather than drawing the tiles in WR, and (b) support multi-resolution
tiles so that we reduce the draw call, batching and render target
overhead in cases where much of the page content is changing.
Differential Revision: https://phabricator.services.mozilla.com/D34319
--HG--
extra : moz-landing-system : lando
Note that the geckoview annotation will override the previous Android
annotation, but I verified that on geckoview debug the test seems to
pass so overriding the Android&&debug annotation should be ok.
Depends on D34727
Differential Revision: https://phabricator.services.mozilla.com/D34728
--HG--
extra : moz-landing-system : lando
