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
Bug 1259889 Part 2 [1] cannot be reverted cleanly, so I manually undo those
changes in this patch. That is, remove the ability for html.css to
invalidate dynamically since it was added specifically for details element.
Although reftest-stylo.list explicit mentions "DO NOT EDIT!", but I still
remove details pref from the file, since it doesn't harm to edit it anyway.
[1] https://hg.mozilla.org/mozilla-central/rev/30aaf3805b56
MozReview-Commit-ID: FsyTGQTxujh
--HG--
extra : rebase_source : 25e5a05a8a5a47642772da69f427631fa07e232d
Excessive clamping can cause incorrect behaviour in the presence of negative
margins.
MozReview-Commit-ID: AkQEqcQpAxx
--HG--
extra : rebase_source : 33cde31c15608792299a1dbef475e0fe0936270d
clip-path-invalidation-1a.html/mask-invalidation-2a.html:
Verify the rendering result of changing scale transform of masked/clipped
element on LAYER_INACTIVE path.
clip-path-invalidation-1b.html/mask-invalidation-2b.html:
Verify the rendering result of changing scale transform of masked/clipped
element on LAYER_ACTIVE path.
clip-path-invalidation-1c.html/mask-invalidation-2c.html:
Verify the rendering result of changing the content of mask/clipPath element
on LAYER_INACTIVE path.
clip-path-invalidation-1d.html/mask-invalidation-2d.html:
Verify the rendering result of changing the content of mask/clipPath element
on LAYER_ACTIVE path.
MozReview-Commit-ID: 1ZFgzAea8T8
--HG--
extra : rebase_source : 6e04c6521db5862595f3051e54d8aa853e6ac9d6
In GetFlowArea(), "Shrink our band's height if needed." computation was
moved to the end because we need to pass the unmodified |blockEnd| to
compute LineRight() and LineLeft().
Revamp OutsetBorderRadii() to allow negative margin to reduce the radius,
but not below zero. Also implement the cubic formula required by the spec.
https://drafts.csswg.org/css-shapes/#valdef-shape-box-margin-box
OutsetBorderRadii() is now tailored only for margin-box with border-radius,
so it might no longer be suitable for other scenarios.
MozReview-Commit-ID: HKxW7rp6sIA
--HG--
extra : rebase_source : d416433016304feefc9ed9dcd1c22f7f2f92e27e
Per spec, float positioning and stacking is not affected by defining a float
area with a shape.
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
So all the call sites of GetFloatAvailableSpace() related to adding a
float are replaced by GetFloatAvailableSpaceForPlacingFloat().
<shape-box> with border-radius will be implemented in next part.
MozReview-Commit-ID: 1RXEeXDhdWo
--HG--
extra : rebase_source : 42cdb0c81b16168e4e30ee2261ceccb562e278cf
In nsBlockFrame::PlaceLine(), we query the float available space by
using the line's BSize(), which may cause the line to reflow again due
to available space shrunk.
The first issue lies in the second reflow. That is, we do not leverage
the line's BSize() computed in the first reflow to query the float
available space when updating the inline reflow engine in
BlockReflowInput::AddFloat(). So some tall inline elements could still
overlap the floats as in the first reflow.
To solve this, we cache current line's BSize so that it could be
used to update the inline reflow engine when redo the line.
Another issue is in nsBlockFrame::PlaceLine(). When determined whether
the available space is shrunk, we use the float manager's state *before*
placing the line. So if current line has floats, they're not considered.
To solve this, we use the current set of floats to get the float available
space for comparison, and leave the original aFloatAvailableSpace to provide
the information when redoing the line.
MozReview-Commit-ID: GqqNlphgxYS
--HG--
extra : rebase_source : e2c64ab1ac363c7a08e532dc043bee69d6455049
cku
Ting-Yu Lin
Botond Ballo
Carsten "Tomcat" Book
Mike Conley
Lee Salzman
Phil Ringnalda
Jeremy Chen
Wes Kocher
Ehsan Akhgari
Mats Palmgren
Markus Stange
Xidorn Quan
Manish Goregaokar
Xidorn Quan
Daniel Holbert
Ethan Lin
Neerja Pancholi