Open Bug 1340715 Opened 3 years ago Updated 1 month ago

{inc}nsSVGOuterSVGFrame::GetPrefISize depends on results of previous layout

Categories

(Core :: SVG, defect, P3)

defect

Tracking

()

Tracking Status
firefox54 --- affected

People

(Reporter: dbaron, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

Bug 1162418 made nsSVGOuterSVGFrame::GetPrefISize call GetLogicalSize on ancestors going up the frame tree.  It's incorrect to do this, because it can depend on the results in a *previous* layout rather than the current one.


What led me to this code was trying to explain to fantasai the Firefox behavior in:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22width%3A%20500px%3B%20border%3A%20magenta%20solid%20thick%22%3E%0A%3Cdiv%20style%3D%22float%3A%20left%3B%20border%3A%20orange%20solid%20thick%3B%22%3E%0A%3Csvg%20viewbox%3D%220%200%2010%2010%22%20style%3D%22display%3A%20block%22%3E%0A%20%3Crect%20fill%3Dblue%20width%3D100%25%20height%3D100%25%20%2F%3E%0A%3C%2Fsvg%3E%0A%3C%2Fdiv%3E
which is actually reasonable, and could probably be obtained by returning nscoord_MAX as the pref ISize, but I think this code is incorrect.

I'll try to write a testcase showing the bad results later.
Note that this nearly led the spec authors to specify ... it's not clear what ... but it might not have been implementable:
https://github.com/w3c/csswg-drafts/issues/951
Component: Layout → SVG
Priority: -- → P3
Summary: nsSVGOuterSVGFrame::GetPrefISize depends on results of previous layout → {inc}nsSVGOuterSVGFrame::GetPrefISize depends on results of previous layout
You need to log in before you can comment on or make changes to this bug.