Precondition:
In an SVG doc, giving an invalid local-ref mask, e.g. mask="url"#foo"", and
clipState.mDirtyRectInDevPx be empty. e.g. apply mask onto a path object which
the size of area is zero(Please refers to the reftest in Part 2)
1. PaintStyleImageLayerWithSC early continue at [1], and the value of result is
still the initial value, DrawResult::SUCCESS.
2. The caller is not aware of that the mask image was left unresolved since it get
DrawResult::SUCCESS from #1.
This patch fixed this problem by calling PrepareImageLayer before early return
for updating correct drawing result.
[1]
https://hg.mozilla.org/mozilla-central/file/ebf68ba9b098/layout/painting/nsCSSRendering.cpp#l2682
MozReview-Commit-ID: DjJ0Nni1gDl
--HG--
extra : rebase_source : 949101547b6cb4db93c8a889210c768fb81cff7a
This propagates the StackingContextHelper to the rest of the code that
builds WR display items, because we will need it in future patches to
stop using RelativeToParent.
MozReview-Commit-ID: 3PlQrJRhH36
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
In nsCSSRendering::PaintBorderWithStyleBorder:
DrawResult
nsCSSRendering::PaintBorderWithStyleBorder()
{
if (aStyleBorder.IsBorderImageLoaded()) {
(1)
}
(2)
}
At (1), we create a nsCSSBorderImageRenderer object. While creating it, we call
imgRenderer.PrepareImage() to ensure a full image decode at [1]. PrepareImage is
used in both bg-image/mask-image and border-image. The difference is, in
bg-image/mask-image painting path, we unconditionally use PrepareImage(in
nsCSSRendering::PrepareImageLayer), whereas in border-image painting path we
use it only after border-image was downloaded. This difference does cause a
problem. After border image was downloaded, the decoder will not do full decoding
since we did not ask for it, so there will be no repaint notification and no
chance to paint border-image again.
In this patch, I try to align the behavior between bg-image/mask-image and
border-image: always call nsImageRenderer::PrepareImage.
This is a generic fix for both stylo-enable and stylo-disable build. We do not
find this problem in reftest is because we use SYNC_DECODE in reftest harness, which
hides this race condition. When daily using firefox, if
nsCSSRendering::PaintBorderWithStyleBorder is called after border-image was
loaded, your program run into (1), border-image will be drawn correctly; In the
case that nsCSSRendering::PaintBorderWithStyleBorder is called before
border-image is loaded, your program run into (2), and you can only see
border-color.
[1]
https://hg.mozilla.org/mozilla-central/file/a6f35285bd1e/layout/painting/nsCSSRenderingBorders.cpp#l3598
MozReview-Commit-ID: 6pidHJdPG8I
--HG--
extra : rebase_source : 2be402f59a42ef767ab6bae2962cd2ec55b36c50
A few includes and namespace annotations are missing. And
nsImageRenderer.cpp is calling two functions that are static functions in
nsCSSRendering.cpp.
MozReview-Commit-ID: BLVPwpKB7On
--HG--
extra : rebase_source : d6111d093de47b88b5beba6478de4b6ed75b2a52
This function is not a virtual function and always returns CAIRO_STATUS_SUCCESS
after the patch in bug 1054838 landed. There is no reason to keep it anymore.
MozReview-Commit-ID: EadrrFQyjfY
--HG--
extra : rebase_source : 3f6a284dc9fa396d5cfd3f64190562373801a0a2
This change is to use gecko_enum_prefix in helpers.mako.rs, so that we do not
need to manually write code for nsStyleDisplay::mTransformBox.
MozReview-Commit-ID: 7UAL0iUcSIO
--HG--
extra : rebase_source : e99b7c163991df7ef3e7c0404fcef1832718a150
If mask-mode is luminace, we will create a temporary context at [1]. It's
obvious we do not use this gfxContext at all in PaintGradient path. This patch is
trying to fix this problem by pass gfxContext, instead of RenderingContext,
directly to PaintGraident.
[1] https://hg.mozilla.org/mozilla-central/file/991f5724e58f/layout/painting/nsCSSRendering.cpp#l5811
MozReview-Commit-ID: LLmg4k6IEm3
--HG--
extra : rebase_source : ed42e3f5ddf1314300259c3f74d43aac8b4683de
There is no direct relation between this patch and the bug. Read through the code
and think we may reuse some logic.
MozReview-Commit-ID: HGEvDNGoIBS
--HG--
extra : rebase_source : b349702a787203317c6e66be0b9aa6818d532788
extra : source : b4ca22d03b6ba3e8eb9d0e3551830149ec99de82
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
With the ActiveScrolledRoot changes, we will need to set up different state on
the display list builder prior to creating the nsDisplayBackgroundImage item.
MozReview-Commit-ID: CgeffVPccfj
--HG--
extra : rebase_source : e2e1481a2e9df8becf56b969f151915694d62a8d
Each concrete class of imgIContainer is able to handle opacity already. All we
need to do is pass opacity value to them.
MozReview-Commit-ID: EMkLnG3YXA1
--HG--
extra : rebase_source : b0a0aad1fec0c2765e96d23ed9b627345c793795
