Bug 50543 – Problems with filter attribute and SMIL

• Status: UNCONFIRMED
• Component: SVG

[marek]

Happens in latest Chrome public stable build (8.0.552.215).
There are two bugs actually. 
One is, that it is not possible to "unset" already applied filter to some element, setting its value to empty string "" nor "none" (which is according to spec possible) does not help.
However, more serious problem is in my opinion this:
if there is applied filter effect to some element and at the same time there is set SMIL animation affecting the same filter attribute, filter is not initially applied, although it should be.
To be more explicit, this case doesn't work:

<g filter="url(#glow)">
  <set attributeName="filter" to="url(#glow)" begin="butGlowOn.click"/>
  ...
</g>

but this one does

<g filter="url(#glow)">
  <set attributeName="filter" to="url(#glow)" begin="butGlowOn.click"/>
  ...
</g>

It would be great to have it fixed...

[marek]

Created attachment 75635 [details]
Reduced testcase of broken behavior

[marek]

Created attachment 75636 [details]
Reduced testcase of working behavior (without SMIL animation for filter attribute)

Both attachments also represent broken behavior of reseting already applied filter (by clicking the button)

[marek]

Actually, this demo includes also third error, introduced in latest stable Chrome build (previous 7.x stable release was working properly).
Bug is that filter region is computed wrongly and applied BLUR effect is visible on outside of the bouncing box...
Can be seen also on other demos using filters, like: http://svg.kvalitne.cz/adobe/fePixels.svg

[Dirk Schulze]

(In reply to comment #3)
> Actually, this demo includes also third error, introduced in latest stable Chrome build (previous 7.x stable release was working properly).
> Bug is that filter region is computed wrongly and applied BLUR effect is visible on outside of the bouncing box...
> Can be seen also on other demos using filters, like: http://svg.kvalitne.cz/adobe/fePixels.svg

I cant reproduce the third bug you mentioned. Can you test it with WebKit nightly? Nevertheless this should have it's own bug report. Can you open a new bug and attache a screenshot, if the third bug is not fixed on trunk?

[Dirk Schulze]

(In reply to comment #4)
> (In reply to comment #3)
> > Actually, this demo includes also third error, introduced in latest stable Chrome build (previous 7.x stable release was working properly).
> > Bug is that filter region is computed wrongly and applied BLUR effect is visible on outside of the bouncing box...
> > Can be seen also on other demos using filters, like: http://svg.kvalitne.cz/adobe/fePixels.svg
> 
> I cant reproduce the third bug you mentioned. Can you test it with WebKit nightly? Nevertheless this should have it's own bug report. Can you open a new bug and attache a screenshot, if the third bug is not fixed on trunk?

To your bug, it looks like another problem with the cached filter. I ask my self if we should temporary disable saving the filter result, since it does not get covered by repaint :-/.

[marek]

OK, I created https://bugs.webkit.org/show_bug.cgi?id=50559, but I'm not able to test it in nightly build right now...