This change will allow the border drawing code to deal with the following
changes, which will make us no longer force the fieldset to be wider than the
legend. Without this patch, allowing the fieldset to be narrower than the
legend causes the vertical inline-start-side and inline-end-side borders of the
fieldset to paint under the legend, because the current code only modifies the
painting of the block-start-side border (the one the legend is positioned on).
This does change behavior in one situation, which the new tests test. For
relatively positioned legends, we used to use the original vertical location but
the positioned horizontal location of the legend to decide which parts of the
border to not paint. In the new setup, we use the original location for both.
I did check that this new behavior matches Chrome and Safari. Edge seems to
have our old behavior.
This reduces the time to import by ~30% with css-writing-modes included.
MozReview-Commit-ID: JsnkRfTFnp6
--HG--
extra : source : 76731753ce13d2d9e427935112b02df2781cd44a
This change will allow the border drawing code to deal with the following
changes, which will make us no longer force the fieldset to be wider than the
legend. Without this patch, allowing the fieldset to be narrower than the
legend causes the vertical inline-start-side and inline-end-side borders of the
fieldset to paint under the legend, because the current code only modifies the
painting of the block-start-side border (the one the legend is positioned on).
This does change behavior in one situation, which the new tests test. For
relatively positioned legends, we used to use the original vertical location but
the positioned horizontal location of the legend to decide which parts of the
border to not paint. In the new setup, we use the original location for both.
I did check that this new behavior matches Chrome and Safari. Edge seems to
have our old behavior.
When we are composing style for the Animations level of the cascade,
if we have transitions-level animations, we *also* need to compose them if we
have animations-level animations that build on top of them using additive or
accumulative composite modes.
However, we should not build those transitions-level animations unless they will
be built on or overridden by a regular animations-level animation. Otherwise
we will end up with transitions-level animations in the animations-level and
while transitions-level will override the animations-level in the cascade,
once the transition finishes there will be nothing to remove the cached
animations-level animation rule.
MozReview-Commit-ID: LaRabzDSsO5
--HG--
extra : rebase_source : 256efb5779a8cbcc8ae906295b40b160a55641c9
The tests cases are designed based on the integer solution to the ellipse
equation (x/a)^2 + (y/b)^2 = 1, where x=36, y=32, a=60, b=40.
MozReview-Commit-ID: De2fXcb6ypP
--HG--
extra : rebase_source : a64f490ff41c020b84025266c0c255d93a158eea
We need to consider the case when only one of the four corner radius is
specified. The two reftests are added to test 'border-top-right-radius' and
'border-bottom-right-radius', respectively.
MozReview-Commit-ID: De2fXcb6ypP
--HG--
extra : rebase_source : 51da04a7a7d60d580b46d9ac8ed4bfd7e9666766
I talked to mstange about this, and what might be happening here is that there's
a difference in rounding going on during (I think) rasterization. The change is
very small and not human-noticable, so I think taking this fuzzyness is worth
the cost considering the gain in functionality.
MozReview-Commit-ID: C0CPNrIdCDu
--HG--
extra : rebase_source : 1101651250d5593ee84c661d9b91c8c6edb7c531
At the caller side of nsSVGMaskFrame::GetMaskForMaskedFrame(nsSVGIntegrationUtils
& nsSVGUtils), we do skip masked frame painting when this function return value
other then DrawResult::SUCCESS. So there is no need to return an empty surface
anymore.
And add a test case to verify it.
MozReview-Commit-ID: DHl6krJ1ABF
--HG--
extra : rebase_source : 46d653d4e35833e3e816d252ce3f08d2d8190602
At the caller side of nsSVGMaskFrame::GetMaskForMaskedFrame(nsSVGIntegrationUtils
& nsSVGUtils), we do skip masked frame painting when this function return value
other then DrawResult::SUCCESS. So there is no need to return an empty surface
anymore.
And add a test case to verify it.
MozReview-Commit-ID: DHl6krJ1ABF
--HG--
extra : rebase_source : a4e23896a84c5dd1b5df9c6e8505a2b32ee17b84
1. Remove the preference setting in reftest.list
2. Remove the preference guard in property_database.js
3. Remove the callback function of preference change
4. Remove the preference from all.js
MozReview-Commit-ID: 6aqYmhz6c9M
Xidorn Quan
Mats Palmgren
Cameron McCormack
sotaro
Thomas Wisniewski
Boris Zbarsky
Ryan VanderMeulen
Hiroyuki Ikezoe
Tom Puttemans
Neerja Pancholi
Carsten "Tomcat" Book
Sebastian Hengst
Wes Kocher
Phil Ringnalda
Botond Ballo
cku
Ting-Yu Lin
Mike Conley
Lee Salzman
Jeremy Chen