Bug 103304 – REGRESSION: SVG setAttribute does not force a layout/repaint

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Philip Rogers]

Created attachment 176088 [details]
Testcase

Setting width via setAttribute does not force a layout/repaint whereas setting it via style does.

Original bug: http://code.google.com/p/chromium/issues/detail?id=162628

[Alexey Proskuryakov]

Is it known when this regressed? It fails even in Safari 6.0.2.

[Dirk Schulze]

Philip, does this just happen with inline SVG? Does it just happen with SVG root elements? I think we have a lot of tests for pure SVG covering this. So it might be a problem between HTML and SVG.

[Philip Rogers]

I think this may be caused by the supremely confusing fact that style="width:x" and width="x" are different. For the most part, this affects the svg/html boundary and is present on <svg>.

[Patrick Ruzand]

(In reply to comment #1)
> Is it known when this regressed? It fails even in Safari 6.0.2.

[for the log: I'm the one who filled the original chromium bug, working on Dojo Toolkit dojox/gfx api).

From my tests, and using the webkit number as it appears in the browser user agent, it looks like the problem appears for webkit version > 534 (AppleWebKit/534.x ). 536 and 537 have the problem, 534 don't.

[Philip Rogers]

(In reply to comment #4)
> (In reply to comment #1)
> > Is it known when this regressed? It fails even in Safari 6.0.2.
> 
> [for the log: I'm the one who filled the original chromium bug, working on Dojo Toolkit dojox/gfx api).
> 
> From my tests, and using the webkit number as it appears in the browser user agent, it looks like the problem appears for webkit version > 534 (AppleWebKit/534.x ). 536 and 537 have the problem, 534 don't.

You're right that this is a regression after all.

I looked into this further and did a bisect on the chromium tree. I think the regression range is:
https://trac.webkit.org/log/?verbose=on&stop_rev=105127&rev=105862&limit=10000

There are two likely regressees:
https://bugs.webkit.org/show_bug.cgi?id=76447
https://bugs.webkit.org/show_bug.cgi?id=76446

Assigning this bug to myself.

[Philip Rogers]

Created attachment 177132 [details]
Invalidate SVG width on width attribute changes.

[Dirk Schulze]

Comment on attachment 177132 [details]
Invalidate SVG width on width attribute changes.

View in context: https://bugs.webkit.org/attachment.cgi?id=177132&action=review

> Source/WebCore/svg/SVGSVGElement.cpp:285
> +    bool widthChanged = attrName == SVGNames::widthAttr;

This looks strange. Why isn't it the case for height as well?

[Dirk Schulze]

Comment on attachment 177132 [details]
Invalidate SVG width on width attribute changes.

Discussed height on IRC. A test covers height as well. LGTM. r=me.

[WebKit Review Bot]

Comment on attachment 177132 [details]
Invalidate SVG width on width attribute changes.

Clearing flags on attachment: 177132

Committed r136424: <http://trac.webkit.org/changeset/136424>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Philip Rogers]

*** Bug 106923 has been marked as a duplicate of this bug. ***

[Dominik Röttsches (drott)]

Philip, could bug 99996 be a duplicate of this as well?

[Philip Rogers]

(In reply to comment #12)
> Philip, could bug 99996 be a duplicate of this as well?

I don't think so because this bug is about the root element, whereas 99996 is a drop shadow element. I haven't run the tests to verify this though.

[Dirk Schulze]

(In reply to comment #12)
> Philip, could bug 99996 be a duplicate of this as well?

Definitely not. The problem is that FilterFunctions don't have a renderer and don't react correctly on style changes. Everything else is just a hack.