Apparently we sometimes fall back to skia canvas with WebRender if ANGLE
fails to initialize. This makes the azureSkia condition true, but the
test still passes because of WebRender's magical properties. This patch
updates the annotation to reflect reality, so we don't get unexpected
passes.
Differential Revision: https://phabricator.services.mozilla.com/D21012
--HG--
extra : moz-landing-system : lando
This is a new implementation of mix-blend compositing that is meant to be more idiomatic to WR and efficient.
Previously, mix-blend mode was composed in the following way:
1. parent stacking context was forced to isolate
2. source picture is also isolated
3. when rendering the isolated context, the framebuffer is read upon reaching the source. Both the readback and the source are placed in the RT cache.
4. a mix-blend draw call is issued to read from those cache segments and blend on top of the backdrop
The new implementation works by using the picture cutting (intruduced for preserve-3D contexts earlier) and some bits of magic:
1. backdrop stacking context is isolated with a special composition mode that prevents it from actually rendeing unless the suorce stacking context is invisible.
2. source stacking context is isolated with mix-blend composition mode that has a pointer to the backdrop picture
3. the instance of the backdrop picture is placed as a peer of the source picture (not a child)
4. if the backdrop is invisible, the source is drawn as a simple blit
5. otherwise, it's a draw call that reads from the isolated backdrop and source textures
Note the differences:
- parent stacking context is not isolated, but backdrop is
- no framebuffer readback is involved
- the source and backdrop pictures are rendered in parallel in a pass, improving the batching
- we don't blend onto the backdrop while reading from the backdrop copy at the same time
- the depth of the render pass tree is reduced: previously the parent and the source were isolated, now the source and the backdrop, which are siblings
Differential Revision: https://phabricator.services.mozilla.com/D20608
--HG--
rename : gfx/wr/wrench/reftests/blend/multiply-2-ref.yaml => gfx/wr/wrench/reftests/blend/multiply-3-ref.yaml
rename : gfx/wr/wrench/reftests/blend/multiply-3.yaml => gfx/wr/wrench/reftests/blend/multiply-4.yaml
extra : moz-landing-system : lando
If there's ::first-letter pseudo element on the multicol container,
ColumnSetWrapperFrame will have the first letter style, but it won't get
the NS_BLOCK_HAS_FIRST_LETTER_STYLE bit during frame construction. The
actual first-letter frame construction happens under -moz-column-content
anonymous block.
This patch excludes ColumnSetWrapperFrame from the debug check to meet
the expectation.
Add a reftest to make sure ::first-letter and ::first-line still work
after introducing ColumnSetWrapperFrame, and no assertion is fired.
Differential Revision: https://phabricator.services.mozilla.com/D20757
--HG--
extra : moz-landing-system : lando
Without this patch, if we got a display item with the root clip id, we
would always clip that display item with the root clip of the enclosing
pipeline. However, this violates the documented semantics on
ClipId::root() which states that it effectively does no clipping.
Specifically, it could end up doing clipping if the display item was
part of a scrollframe that was scrolled such that the display item
extended beyond the enclosing pipeline.
This patch adds an extra argument to some of the flattening functions -
the flag is true when recursing the DL between a pipeline item and the
first stacking context that has a clip. For these items, the pipeline
clip is applied. Once inside the stacking context, the pipeline clip is
not applied.
Differential Revision: https://phabricator.services.mozilla.com/D20483
--HG--
extra : moz-landing-system : lando
Technically Bug 1524774 only has 1 fuzzy pixel, but I'm aiming to also address
bug 1525568 which has 2 fuzzy pixels on a different platform (mac).
--HG--
extra : rebase_source : 1be608959d17bfa0de555820f1270a9ca6759163
With these changes, XBL just runs in the window scope of whatever document it's
attached to. Since (outside of tests and "remote XUL") we no longer attach XBL
to web documents, this is fine. And "remote XUL" already ran without the XBL
scope.
Native anonymous content, which used to be placed in the XBL scope to hide it
from the page, is now placed in the unprivileged junk scope, so it stays hidden
from the page.
dom/xbl/test/test_bug944407.xul is being removed because we are changing the
behavior it's trying to test for. Since we now always put the XBL in the same
scope as the page, script is enabled for the XBL if and only if it's enabled for
the page.
dom/base/test/test_bug419527.xhtml, dom/events/test/test_bug391568.xhtml,
dom/xbl/test/test_bug1086996.xhtml are being switched to a chrome test because
otherwise the XBL can't see the getAnonymousNodes method.
All the XBL bits are being removed from test_interfaces because we no longer
have a separate XBL scope to test the behavior of.
js/xpconnect/tests/mochitest/test_nac.xhtml is being removed because XBL no
longer has access to NAC unless the page it's attached to does too, so the test
doesn't really make sense.
layout/xul/test/test_bug1197913.xul is being switched to a chrome test because
its XUL elements use bindings that rely on APIs that are not exposed to normal
web content.
layout/reftests/bugs/495385-2f.xhtml is being removed because I can't think of
a sane way to test that in the new world, short of running the reftest as
chrome. And it doesn't seem worthwhile to look for a way to do that.
dom/xbl/test/test_bug1098628_throw_from_construct.xhtml now needs to
expectUncaughtException(), because the exception is now being thrown in Window
scope.
dom/xbl/test/test_bug1359859.xhtml needs to expectUncaughtException() as needed
and not use XPCNativeWrapper (which it doesn't need to anyway now).
dom/xbl/test/test_bug389322.xhtml, dom/xbl/test/test_bug400705.xhtml,
dom/xbl/test/test_bug401907.xhtml, dom/xbl/test/test_bug403162.xhtml,
dom/xbl/test/test_bug526178.xhtml, dom/xbl/test/test_bug639338.xhtml don't need
to use XPCNativeWrapper anymore.
dom/xbl/test/test_bug821850.html is being removed because it exists only to test XBL scopes.
dom/xbl/test/file_bug950909.xml is being changed to work without a separate XBL
scope (though whether the test still makes sense at that point is a bit questionable).
Differential Revision: https://phabricator.services.mozilla.com/D19260
--HG--
extra : moz-landing-system : lando
remove line-height:normal rule from html.css for <sub> and <sup> for interop.
Differential Revision: https://phabricator.services.mozilla.com/D18636
--HG--
extra : moz-landing-system : lando
Both of reftests in this commit are based on an exmaple [1] in the Viewports
Explainer written by David Bokan.
position-fixed-out-of-view.html fails without the fix because the position:fixed
element is rendered at the right edge of the visual viewport so that it's
visible in the first place.
position-fixed-on-minimum-scale-size.html does NOT fail without the fix either
because the position:fixed element sticks at the right edge of the visual
viewport so that it still be there even after the visual viewport offset has
been changed.
[1] https://github.com/bokand/bokand.github.io/blob/master/web_viewports_explainer.md#chrome-2
Differential Revision: https://phabricator.services.mozilla.com/D18797
--HG--
extra : moz-landing-system : lando
For elements that have box-sizing:border-box specified, the aspect ratio
calculation code subtracts out border & padding from any specified property
values.
So, when we create a fake "override" specified property value for a flex item
whose main size has been resolved, we need to add in the border and padding to
account for the fact that they're going to be subtracted out later.
Differential Revision: https://phabricator.services.mozilla.com/D17712
--HG--
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001-ref.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007-ref.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001v.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007v.html
extra : moz-landing-system : lando
It seems like we intermittently get fuzz on the clip-path-inset tests.
It's better for us to accept that fuzz than intermittently fail.
Differential Revision: https://phabricator.services.mozilla.com/D18277
--HG--
extra : moz-landing-system : lando