Someone contacted me to complain that the new SVG site banner they're writing for Firefox 3 doesn't work. Their problem is that when the width of an <object> embedding SVG comes from the SVG's intrinsic width, we don't resize the <object> when the CB width increases if the SVG's intrinsic width is a percentage. Apparently I forgot to implement nsSubDocumentFrame::GetIntrinsicSize despite putting in the checks for nsSubDocumentFrame having a percentage intrinsic width/height (bug 294086): http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsLineLayout.cpp&rev=3.307&mark=732-734#726 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsHTMLReflowState.cpp&rev=1.297&mark=412#404
Created attachment 309971 [details] [diff] [review] patch
This is a brain dead patch to fix a stupid and unfortunate rendering issue, so let's block on this.
Priority: -- → P1
Does this patch require a beta cycle? Must it block beta 5? Side note, please, when determining blocker status, erase the knowledge from your brain that there is a patch. The bug should block on merits of severity and impact alone, not on how fast it would be to fix. :)
Fair enough, point taken. Still we should definitely take this IMO, but we can probably take it after beta 5.
Priority: P1 → P2
Comment on attachment 309971 [details] [diff] [review] patch r+sr=dbaron, but could you parenthesize the &&-ed stuff in the nsHTMLReflowState.cpp change so that it's clearer that there's an && in the middle of a long chain of ||s?
Sure. Checked in with that change. I'm going to check in some reftests for this just as soon as I figure out why it seems to be okay to resize the window once in a reftest, but not a second time (to restore it to its original size for the tests that follow it).
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.