Created attachment 62522 [details]
Given a div with SVG background and border, div's background doesn't resize when div's dimensions are changed (no matter if using JS animation, CSS transition, or just :hover)
Steps to reproduce:
1. Make a <div> with SVG background
2. Add a border or an outline to this <div> (bug won't appear without this)
3. Change its dimensions in some way (easiest way is to use :hover)
Border changes its dimensions, but background stays in the same position
Background changes its dimensions accordingly to div
Build Date & Platform:
Safari 5.0 (6533.16) - which is WebKit 533, right?
Additional Builds and Platforms:
Works just fine on Opera 10.60
Sorry for my English ;)
I can't reproduce it locally with trunk. Have you tested it with a nightly?
(In reply to comment #1)
> I can't reproduce it locally with trunk. Have you tested it with a nightly?
No until now (sorry for that - I'm the new one), but I can reproduce it on nightly.
CC'in Dan Bernstein.
Dan, do you know off-hand what might be the difference that the SVG background image doesn't resize anymore when a border is applied to the <div>? I'd be thankful for any hints.
As far as I can tell, this is a regression in r62922, which added RenderSVGRoot ::clippedOverflowRectForRepaint, which redirects the call to SVGRenderSupport instead of the superclass, RenderBox.
SVGRenderSupport's implementation uses the m_repaintBoundingBox on the RenderSVGRoot, which is calculated using computeContainerBoundingBoxes, which only takes into account the bounding boxes of the children of the container! (that is to say, ignores the bounding box of the RenderSVGRoot, which includes the background!)
We could fix this by making RenderSVGRoot::updateCachedBoundaries include the RenderSVGRoot's bounding box *in the case where it has a background*, but I'm not sure if that would break anything. Alternatively, we could just remove RenderSVGRoot::clippedOverflowRectForRepaint, leaving it to be forwarded to RenderBox, but I have a feeling it's done the way it is right now for performance reasons, so we should be careful with it.
Nevermind! This is actually separate from the r62922 regression, which I'll file a separate bug for tomorrow because it needs some discussion. Sorry!
47156 fixes this.
Fixed in r98852. Thanks for the testcase!