This gets set to a non-zero value when we have an inactive ContainerLayer ancestor (filter in this case).
The current code assumes we'd never call BuildLayer on an image when that happen, but we force the pseudo-active
state here because background-position is animated (all properties have a transition).
MozReview-Commit-ID: 6pL8EJTNgWy
--HG--
extra : rebase_source : 6370fc79d5f47f0b5c4bbe86c0b605b90256b653
Patch originally developed on bug 1458921 but needs to land with the WR update.
MozReview-Commit-ID: 82BYyNWBAfn
--HG--
extra : rebase_source : e6bca2f446c019fd41a37c2c28db73bbe1cfc216
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : source : 653c6b7480997c4e1dbead5f0441bc06a0605b7a
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : rebase_source : 540e68ffff618a6dc3c14b3702b2c042988061a3
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : rebase_source : 6c61fa95a3b01e7b439be46a2498b4f893d8b84b
The clip chain API in webrender allows us to build the clip state in WR
so that it matches the gecko display list more closely. This patch throws
away ScrollingLayersHelper.* and introduces ClipManager.* which pushes
the clip state to WR using the new method. A quick summary of the new
method is below.
Each display item in gecko has a DisplayItemClipChain which is a chain
of individual clips. The individual clips are defined in WR, and the
clip ids for those clips are put into a WR clip chain using the new
define_clip_chain API. Furthermore, each clip chain can also have a
parent chain, which is used to link a DisplayItemClipChain to the parent
display item's DisplayItemClipChain. This allows the WR clip state to
closely match the structure of the gecko display list clip state,
resulting in more correct behaviour.
There are a few other major changes that are lumped into this patch and
that were tricky to separate into their own patches:
- The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR
side all the clip ids are treated the same anyway. Trying to preserve
the arbitrary distinction on the gecko side was resulting in
increasingly convoluted code, with different kinds of Variant<..>
types in the method signatures. It was much simpler and resulted in a
bunch of code deletion to just collapse the types.
- Moving the "override" mechanism from WebRenderAPI to ClipManager. The
override mechanism (explained in ClipManager.h) was simplified by
moving it into ClipManager, because it removed the need for tracking
additional clip stack state in WebRenderAPI.
MozReview-Commit-ID: GGbdFyJGprK
--HG--
extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
If the canvas is cleared by setting the width or height attributes, its
opaqueness should not be affected.
This patch keeps support for moz-opaque, and also keeps the behavior that
changing the moz-opaque attribute clears the canvas, even if this does not
affect the actual opaqueness of the canvas.
MozReview-Commit-ID: LOlsJxiP9kc
--HG--
extra : rebase_source : 8bb95b1d5932c39a8085e007f9fd1b88b97afe55
This covers all the reftests that have lower fuzz (or zero fuzz) and
were producing an UNEXPECTED-PASS result with webrender on windows. In
many cases I just adjusted the lower bound of the existing webrender
fuzz. In other cases existing fails-if conditions had to be tweaked to
exclude webrender.
MozReview-Commit-ID: 49LvS0vuYWR
--HG--
extra : rebase_source : d194e24affb87fe4560a127ff4016f9c38f414fd
Many of these could probably be fuzzed but in the interests of getting
the reftest suite turned on sooner I'm doing a blanket fails-if. This
covers all the reftests where there is more fuzz with webrender on
windows than any of existing annotations account for. In some cases the
fuzz is only a few pixels more than the equivalent Linux fuzz already
annotated, but I'll clean that up in a future bug.
MozReview-Commit-ID: IaKarbnL46d
--HG--
extra : rebase_source : 71889340305b0b12fa8eace722e42bb3faf14419