SVG Stabilization

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

SVG Stabilization

Maciej Stachowiak

Hi Everyone,

As part of our stabilization effort, SVG has been raised as an area  
of concern. Some of the newer SVG features have been sources of  
crashes, some of which could potentially be security issues (the ones  
that are buffer overruns).

Specifically, here are some of the risks we see from SVG in our  
current state:

* Non-security hole crashes in normal SVG content on the web - may  
affect user perception of quality, but SVG content is not yet very  
common.

* Security holes - potentially exploitable buffer overruns and such.  
These are really bad, because anyone that shipped an engine exposing  
these would be forced to issue high priority security updates as they  
get discovered. SVG content being relatively rare will not help

* Sites developing a dependency on WebKit-specific SVG bugs - we are  
not as worried about this, since there are a number of other SVG  
implementations out there, and Gecko at least has more market share.


To address these concerns, a few of us came up with a plan which I'd  
like to propose now for discussion. I would especially like to hear  
from WebKit SVG hackers on this.

1) Disable newer/experimental features   (we'd probably guard these  
with a single SVG_EXPERIMENTAL_FEATURES ifdef)
   * SVGImage -- already disabled
   * Animation -- not tested anywhere enough yet, and still noticably  
unstable
   * Filters -- still unstable, and can cause problems with buggy  
graphics drivers which take down the whole machine
   * Use -- untested/unstable
   * foreignObject -- might have issues with html inside svg,  
particularly for hit testing, etc


2) Additional testing
   * Fuzz-test for custom parsers - the biggest security risk is  
buffer overruns in some of the custom parsers, so we'd like to  
develop a fuzz-testing tool for attributes that trigger these, and  
fix resulting crashes.
   * XSS testing - SVG has many elements that reference external  
content, these should be tested for cross-site scripting risk.
   * Additional ad-hoc testing - we will need community help with this
   * Look into generating new results for pixel tests and keep them  
passing, once experimental features are off on trunk.

Thoughts?


Regards,
Maciej

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Alexander Kellett
no idea how much my vote counts in this area anymore :)
but i fully agree with the ideas expressed in this mail

Alex

On 20 Feb 2007, at 03:13, Maciej Stachowiak wrote:

> Hi Everyone,
>
> As part of our stabilization effort, SVG has been raised as an area  
> of concern. Some of the newer SVG features have been sources of  
> crashes, some of which could potentially be security issues (the  
> ones that are buffer overruns).
>
> Specifically, here are some of the risks we see from SVG in our  
> current state:
>
> * Non-security hole crashes in normal SVG content on the web - may  
> affect user perception of quality, but SVG content is not yet very  
> common.
>
> * Security holes - potentially exploitable buffer overruns and  
> such. These are really bad, because anyone that shipped an engine  
> exposing these would be forced to issue high priority security  
> updates as they get discovered. SVG content being relatively rare  
> will not help
>
> * Sites developing a dependency on WebKit-specific SVG bugs - we  
> are not as worried about this, since there are a number of other  
> SVG implementations out there, and Gecko at least has more market  
> share.
>
>
> To address these concerns, a few of us came up with a plan which  
> I'd like to propose now for discussion. I would especially like to  
> hear from WebKit SVG hackers on this.
>
> 1) Disable newer/experimental features   (we'd probably guard these  
> with a single SVG_EXPERIMENTAL_FEATURES ifdef)
>   * SVGImage -- already disabled
>   * Animation -- not tested anywhere enough yet, and still  
> noticably unstable
>   * Filters -- still unstable, and can cause problems with buggy  
> graphics drivers which take down the whole machine
>   * Use -- untested/unstable
>   * foreignObject -- might have issues with html inside svg,  
> particularly for hit testing, etc
>
>
> 2) Additional testing
>   * Fuzz-test for custom parsers - the biggest security risk is  
> buffer overruns in some of the custom parsers, so we'd like to  
> develop a fuzz-testing tool for attributes that trigger these, and  
> fix resulting crashes.
>   * XSS testing - SVG has many elements that reference external  
> content, these should be tested for cross-site scripting risk.
>   * Additional ad-hoc testing - we will need community help with this
>   * Look into generating new results for pixel tests and keep them  
> passing, once experimental features are off on trunk.
>
> Thoughts?
>
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> http://lists.webkit.org/mailman/listinfo/webkit-dev

---
Alexander Kellett
PGP - 0x6BFA8EF3, FPR: DA65 D6DE 56A9 D715 EFB6 A948 B2EF 6622 6BFA 8EF3


_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Andreas Neumann
In reply to this post by Maciej Stachowiak
Hello Maciej and others,

I am not a Webkit SVG developer, but a SVG developer and webkit user. I
think it is important that SVG is turned on in Webkit. The main reason
that SVG isn't widely used today is the fact that some major browsers
don't support it. So please turn it on but disable experimental features.

 From your list in 1) I agree that SVGImage, Animation, Filters and
ForeignObject probably need more effort and testing and they are
candidates to be disabled. This also matches what Firefox can do today.
However, the support of the <use/> element is very important. <use/> is
widely used in SVG content out there and I would welcome it if it could
make it into the next main Webkit version, even if this means additional
efforts from your side. I volunteer to do testing regarding the <use/>
element. Webkit would be the only major browser/UA that doesn't support
<use/>, which would be limiting content wise. This doesn't mean that
<use/> is correctly implemented everywhere.

Regarding 2) I also volunteer to do more testing. What is the timeframe
for releasing webkit? When do you need the testing? I guess ASAP? There
will also be more test cases in the upcoming SVG testsuite regarding the
<use/> element.

Thank you for considering my feedback.

Andreas

Maciej Stachowiak wrote:

>
> Hi Everyone,
>
> As part of our stabilization effort, SVG has been raised as an area  
> of concern. Some of the newer SVG features have been sources of  
> crashes, some of which could potentially be security issues (the ones  
> that are buffer overruns).
>
> Specifically, here are some of the risks we see from SVG in our  
> current state:
>
> * Non-security hole crashes in normal SVG content on the web - may  
> affect user perception of quality, but SVG content is not yet very  
> common.
>
> * Security holes - potentially exploitable buffer overruns and such.  
> These are really bad, because anyone that shipped an engine exposing  
> these would be forced to issue high priority security updates as they  
> get discovered. SVG content being relatively rare will not help
>
> * Sites developing a dependency on WebKit-specific SVG bugs - we are  
> not as worried about this, since there are a number of other SVG  
> implementations out there, and Gecko at least has more market share.
>
>
> To address these concerns, a few of us came up with a plan which I'd  
> like to propose now for discussion. I would especially like to hear  
> from WebKit SVG hackers on this.
>
> 1) Disable newer/experimental features   (we'd probably guard these  
> with a single SVG_EXPERIMENTAL_FEATURES ifdef)
>   * SVGImage -- already disabled
>   * Animation -- not tested anywhere enough yet, and still noticably  
> unstable
>   * Filters -- still unstable, and can cause problems with buggy  
> graphics drivers which take down the whole machine
>   * Use -- untested/unstable
>   * foreignObject -- might have issues with html inside svg,  
> particularly for hit testing, etc
>
>
> 2) Additional testing
>   * Fuzz-test for custom parsers - the biggest security risk is  
> buffer overruns in some of the custom parsers, so we'd like to  
> develop a fuzz-testing tool for attributes that trigger these, and  
> fix resulting crashes.
>   * XSS testing - SVG has many elements that reference external  
> content, these should be tested for cross-site scripting risk.
>   * Additional ad-hoc testing - we will need community help with this
>   * Look into generating new results for pixel tests and keep them  
> passing, once experimental features are off on trunk.
>
> Thoughts?
>
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> http://lists.webkit.org/mailman/listinfo/webkit-dev



--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093  Zurich, Switzerland

Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: [hidden email]
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Antoine Quint
Hi everyone, Maciej,

On 20 févr. 2007, at 10:12, Andreas Neumann wrote:

> From your list in 1) I agree that SVGImage, Animation, Filters and  
> ForeignObject probably need more effort and testing and they are  
> candidates to be disabled. This also matches what Firefox can do  
> today. However, the support of the <use/> element is very  
> important. <use/> is widely used in SVG content out there and I  
> would welcome it if it could make it into the next main Webkit  
> version, even if this means additional efforts from your side. I  
> volunteer to do testing regarding the <use/> element. Webkit would  
> be the only major browser/UA that doesn't support <use/>, which  
> would be limiting content wise. This doesn't mean that <use/> is  
> correctly implemented everywhere.

I agree with Andreas. Although it is a bit of a shame that advanced  
features such as SVGImage, animation, filters and foreignObject won't  
be supported in the stable WebKit, it is a fact of life that I assume  
we have to live with for the time being.

However, <use> is a feature you'll often encounter in SVG content  
given that both Opera and Firefox have supported this feature from  
their first release supporting SVG onwards. If any kind of push is  
required on a single feature at risk for stable, it should definitely  
be this one.

Sorry to say that I can't commit resources in terms of making it  
happen, but I thought I'd voice my support for Andreas's opinion.

Antoine
--
Blog — http://the.fuchsia-design.com



_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Bugzilla from staikos@kde.org
In reply to this post by Maciej Stachowiak

On 20-Feb-07, at 3:13 AM, Maciej Stachowiak wrote:

> As part of our stabilization effort, SVG has been raised as an area  
> of concern. Some of the newer SVG features have been sources of  
> crashes, some of which could potentially be security issues (the  
> ones that are buffer overruns).
>
> Specifically, here are some of the risks we see from SVG in our  
> current state:
>
> * Non-security hole crashes in normal SVG content on the web - may  
> affect user perception of quality, but SVG content is not yet very  
> common.
>
> * Security holes - potentially exploitable buffer overruns and  
> such. These are really bad, because anyone that shipped an engine  
> exposing these would be forced to issue high priority security  
> updates as they get discovered. SVG content being relatively rare  
> will not help

    Have you tried using a static checker for these?

> 2) Additional testing
>   * Fuzz-test for custom parsers - the biggest security risk is  
> buffer overruns in some of the custom parsers, so we'd like to  
> develop a fuzz-testing tool for attributes that trigger these, and  
> fix resulting crashes.

    It's a bit worrisome that we could still have issues like this.

--
George Staikos
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/



_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Alexander Kellett
On 21 Feb 2007, at 17:12, George Staikos wrote:
>  Have you tried using a static checker for these?

good question.

> It's a bit worrisome that we could still have issues like this.

from what i understand the svg path parser code among other parts is  
relatively new.
more review is probably always welcome.

Alex

---
Alexander Kellett
PGP - 0x6BFA8EF3, FPR: DA65 D6DE 56A9 D715 EFB6 A948 B2EF 6622 6BFA 8EF3


_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Geoffrey Garen
In reply to this post by Andreas Neumann
Andreas,

More testing would be great!

Our existing tests are in LayoutTests/svg/. They include the W3C  
tests, version 1.1. You can run our tests with the run-webkit-tests  
script, passing it --pixel to generate pixel results. I don't think  
pixel tests work very well for SVG right now, so you probably just  
want to verify your results in the browser. More information is, of  
course, available at webkit.org and on #webkit on the  
irc.freenode.net IRC server.

I would recommend adding unit tests to LayoutTests/svg/ on a feature  
by feature basis, starting with the features that you see as most  
important. As you probably know, it's important for tests to cover  
default behavior as well as edge cases. Edge cases for attributes  
includes no value, an empty string, 1 above and 1 below a numeric  
limit, very huge positive and negative numbers, very long strings,  
etc. Edge cases for elements includes use in incorrect context, CSS  
cascading, overflow, scrolling, and dynamic movement through  
JavaScript. Edge cases for both includes dynamic insertion and  
removal through JavaScript. I'm sure you can think of more.

We also want to test SVG in different contexts: <object>, <embed>,  
<iframe>.

As far as timeframe is concerned, we can't comment specifically on  
the next Apple release of WebKit, but we are hard at work on  
stabilizing WebKit in order to make it suitable for release.

Thanks,
Geoff

> I volunteer to do testing regarding the <use/> element. Webkit  
> would be the only major browser/UA that doesn't support <use/>,  
> which would be limiting content wise. This doesn't mean that <use/>  
> is correctly implemented everywhere.
>
> Regarding 2) I also volunteer to do more testing. What is the  
> timeframe for releasing webkit? When do you need the testing? I  
> guess ASAP? There will also be more test cases in the upcoming SVG  
> testsuite regarding the <use/> element.

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Maciej Stachowiak
In reply to this post by Bugzilla from staikos@kde.org

On Feb 21, 2007, at 8:12 AM, George Staikos wrote:

>
> On 20-Feb-07, at 3:13 AM, Maciej Stachowiak wrote:
>
>> As part of our stabilization effort, SVG has been raised as an  
>> area of concern. Some of the newer SVG features have been sources  
>> of crashes, some of which could potentially be security issues  
>> (the ones that are buffer overruns).
>>
>> Specifically, here are some of the risks we see from SVG in our  
>> current state:
>>
>> * Non-security hole crashes in normal SVG content on the web - may  
>> affect user perception of quality, but SVG content is not yet very  
>> common.
>>
>> * Security holes - potentially exploitable buffer overruns and  
>> such. These are really bad, because anyone that shipped an engine  
>> exposing these would be forced to issue high priority security  
>> updates as they get discovered. SVG content being relatively rare  
>> will not help
>
>    Have you tried using a static checker for these?

We're looking into applying a static checker for all of WebKit; we  
need to work out the logistics, to make sure there are up-to-date  
results regularly available to the community.

>> 2) Additional testing
>>   * Fuzz-test for custom parsers - the biggest security risk is  
>> buffer overruns in some of the custom parsers, so we'd like to  
>> develop a fuzz-testing tool for attributes that trigger these, and  
>> fix resulting crashes.
>
>    It's a bit worrisome that we could still have issues like this.

On the one hand, all browsers have uncaught security holes. But on  
the other hand, some of the SVG code is indeed less tested and less  
hardened than other portions of the code, which is why we are  
considering disabling some of it and want to do additional automated  
and manual testing.

I think we need to make better use of tools like fuzz testers and  
static checkers over time. With BuildBot, it's relatively simple to  
add more kinds of automated testing that happens on every checkin.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Bugzilla from staikos@kde.org

On 22-Feb-07, at 1:22 AM, Maciej Stachowiak wrote:

>>> 2) Additional testing
>>>   * Fuzz-test for custom parsers - the biggest security risk is  
>>> buffer overruns in some of the custom parsers, so we'd like to  
>>> develop a fuzz-testing tool for attributes that trigger these,  
>>> and fix resulting crashes.
>>
>>    It's a bit worrisome that we could still have issues like this.
>
> On the one hand, all browsers have uncaught security holes. But on  
> the other hand, some of the SVG code is indeed less tested and less  
> hardened than other portions of the code, which is why we are  
> considering disabling some of it and want to do additional  
> automated and manual testing.
>
> I think we need to make better use of tools like fuzz testers and  
> static checkers over time. With BuildBot, it's relatively simple to  
> add more kinds of automated testing that happens on every checkin.

    Also: I'm regularly running Valgrind on it, but now that we have  
a Qt buildbot we could actually set that up to do runs with valgrind  
too.  I did that with another project before and it worked very nicely.

--
George Staikos
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/



_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Krzysztof Kowalczyk
In reply to this post by Maciej Stachowiak
On 2/21/07, Maciej Stachowiak <[hidden email]> wrote:
> >    Have you tried using a static checker for these?
>
> We're looking into applying a static checker for all of WebKit; we
> need to work out the logistics, to make sure there are up-to-date
> results regularly available to the community.

I can recommend Coverity (if you can afford it). In my experience it
works quite well.

-- kjk
_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Nikolas Zimmermann-2
In reply to this post by Maciej Stachowiak
Hey Maciej,

sorry for the really late reply. But I forgot to send the reply :/
First of all I'm very happy to see there is real interesst in a WebKit release
with SVG included - after all that's why me/Rob started to work on WebKit
as our main code base :-)

> To address these concerns, a few of us came up with a plan which I'd
> like to propose now for discussion. I would especially like to hear
> from WebKit SVG hackers on this.
>
> 1) Disable newer/experimental features   (we'd probably guard these
> with a single SVG_EXPERIMENTAL_FEATURES ifdef)
>    * SVGImage -- already disabled
>    * Animation -- not tested anywhere enough yet, and still noticably
> unstable
>    * Filters -- still unstable, and can cause problems with buggy
> graphics drivers which take down the whole machine
>    * Use -- untested/unstable
>    * foreignObject -- might have issues with html inside svg,
> particularly for hit testing, etc
>

I totally agree with disabling SVGImage/Animation/Filters/foreignObject, for
several reasons:

Animation is not even finished from a designed perspective, nor would I call
it a reliable implementation. Disabling is a must for a release.

Filters are "fishy". They don't work correctly, they leak, have SVG DOM
updating issues, and relies on some dirty hacks. Needs to be disabled, too.

SVGImage was a quick hack to show "it works", and isn't really meant to
be enabled yet in a stable build.

foreignObject is rather untested - at least from my side. I never touched
it at all, and we already have several bug reports about problems with it.
So disabling is also a must here.

For <use> I see it a bit different. You're right that the code was a source
of crashes lately - but mostly because of the stupid fact that I forgot the
toNode() implementation (I think you've fixed it in ToT some weeks ago).

I have tested it extensively when implementing it - as it's one of the most
important features in SVG. We have Andreas Neumann around who stated
to be happy doing a lot of more <use> testing in the future.
All the carto.net examples involving <use> work excellent already.
The SVGElementInstance support is something most viewers do NOT have,
and it would be nice to have us including it in a release :-)

I hope I can get you convinced that <use> is a must - I'd be happy
to fix all issues that are reported (already looking forward to Andreas mail
flood ;-)

> 2) Additional testing
>    * Fuzz-test for custom parsers - the biggest security risk is
> buffer overruns in some of the custom parsers, so we'd like to
> develop a fuzz-testing tool for attributes that trigger these, and
> fix resulting crashes.
Definately. There have been too many crashes around involving the svg
path parsing code etc. Any idea how to develop such a fuzz-testing tool?
Simple perl/ruby/<whatever> script producing static test files?

>    * XSS testing - SVG has many elements that reference external
> content, these should be tested for cross-site scripting risk.
Fortunately we don't allow ie <tref> / <use> external references so far.
I think there is no support at all for external referencing, except the usual:
external JS scripts / external CSS sheets. Though that is using WebCore
code itself - no additional SVG trickery - so that should be safe.
SVGImage is disabled, so referencing external SVG content is not possible
- shouldn't be a problem.

Did I miss anything?

>    * Additional ad-hoc testing - we will need community help with this
Agreed.

>    * Look into generating new results for pixel tests and keep them
> passing, once experimental features are off on trunk.
Agreed.

Thanks for getting the discussion started, Maciej!
Short resume: I agree with all points of your mail, except for <use>.
That needs further discussion :-)

Niko
_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Krzysztof Kowalczyk
On 2/24/07, Nikolas Zimmermann <[hidden email]> wrote:
> > 2) Additional testing
> >    * Fuzz-test for custom parsers - the biggest security risk is
> > buffer overruns in some of the custom parsers, so we'd like to
> > develop a fuzz-testing tool for attributes that trigger these, and
> > fix resulting crashes.
> Definately. There have been too many crashes around involving the svg
> path parsing code etc. Any idea how to develop such a fuzz-testing tool?
> Simple perl/ruby/<whatever> script producing static test files?

You might try http://sam.zoy.org/zzuf/ - I never tried it but from the
description it seems to fit the bill perfectly.

-- kjk
_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Maciej Stachowiak
In reply to this post by Maciej Stachowiak

Hi everyone,

Seems like there is rough consensus around this plan. So I filed bugs  
to disable the experimental features for now:
http://bugs.webkit.org/show_bug.cgi?id=12883

And to do some kind of additional testing/review of the various SVG  
microsyntax parsers (it turns out there are a lot):
http://bugs.webkit.org/show_bug.cgi?id=12884


Some people have suggested that <use> should also be left on. I think  
to make this possible would require significant additional testing,  
including test cases of unusual situations like circular references,  
nested references, etc. If anyone wants to do that testing, feel  
free, and ideally please document it with test cases. Note: rewriting  
<use> in a completely different way is unlikely to make it more  
suitable for prime time, since the biggest problem with it is that it  
is new, relatively untested code.


Regards,
Maciej

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Nikolas Zimmermann-2
Hey Maciej,

> Seems like there is rough consensus around this plan. So I filed bugs
> to disable the experimental features for now:
> http://bugs.webkit.org/show_bug.cgi?id=12883
>
> And to do some kind of additional testing/review of the various SVG
> microsyntax parsers (it turns out there are a lot):
> http://bugs.webkit.org/show_bug.cgi?id=12884

Perfect. I think this covers most cases.

> Some people have suggested that <use> should also be left on. I think
> to make this possible would require significant additional testing,
> including test cases of unusual situations like circular references,
> nested references, etc. If anyone wants to do that testing, feel
> free, and ideally please document it with test cases. Note: rewriting
> <use> in a completely different way is unlikely to make it more
> suitable for prime time, since the biggest problem with it is that it
> is new, relatively untested code.

Agreed, it's definately new code, though the scenarios you are mentioning
are covered by tests (LayoutTests/svg/custom). In detail:

SVGElementInstance tests / (SVG) DOM scripting:
use-elementInstance-event-target.svg
use-elementInstance-methods.svg
use-instanceRoot-modifications.svg
use-modify-container-in-target.svg
use-modify-target-container.svg
use-modify-target-symbol.svg
use-property-changes-through-dom.svg
use-property-changes-through-svg-dom.svg

All of these tests operate on the new SVGElementInstance interfaces.
(instanceRoot method of SVGUseElement, returns the root SVGElementInstance).

The built SVGElementInstance tree is tested automatically within
use-elementInstance-methods.svg (checks instance tree consistency)

event handling on <use>:
use-event-handler-on-referenced-element.svg
use-event-handler-on-use-element.svg

Tests the various ways to set up event listeners on <use> elements:
either on the <use> element itself, or on the referenced element.
events have to be propagated to the SVGElementInstance (!) object, not
the original referenced element, nor our internal clone.
 
<use> on <use> tests:
use-forward-refs.svg
use-recursion-1.svg (<use> on <g> which references the <use> itself again.)
use-recursion-2.svg (<use> direct self-referencing>
use-recursion-3.svg (<use> on <g>, containing a <use> which references itself)
use-recursion-4.svg (same like -3.svg, but one level deeper referencing)

This covers the "hairy" parts. Complex deep references, circular references,
self-references. All test work excellent w/o crashs or leaks.

Simple <use> examples (no deep referencing):
use-on-g-containing-use.svg
use-on-g.svg
use-on-rect.svg
use-on-symbol-inside-pattern.svg
use-on-symbol.svg
use-on-text.svg
use-on-use.svg

The usual suspects: simple tests - w/o fancy features.

Misc:
use-events-crash.svg
use-symbol-overflow.svg
use-transform.svg

Other simple tests.

--
I hope the <use> on <use> tests are quite sufficient to test the tricky parts
of the new SVGUseElement / SVGElementInstance code.

I'd like to invent anyone interessed to stress test the <use> code.
We're already much better than Opera/FF/Batik (yes even Batik) with the
current implementation - and all it needs is heavy testing IMHO.

Niko

P.S. The only known <use> problem is that the event dispatching is not
completely implemented. IIRC the last missing issue is: (quote from 1.1 spec)

"An element and all its corresponding SVGElementInstance objects share an
event listener list. The currentTarget attribute of the event can be used to
determine through which object an event listener was invoked."
_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Maciej Stachowiak

On Feb 25, 2007, at 3:32 AM, Nikolas Zimmermann wrote:

> Hey Maciej,
>
>> Seems like there is rough consensus around this plan. So I filed bugs
>> to disable the experimental features for now:
>> http://bugs.webkit.org/show_bug.cgi?id=12883
>>
>> And to do some kind of additional testing/review of the various SVG
>> microsyntax parsers (it turns out there are a lot):
>> http://bugs.webkit.org/show_bug.cgi?id=12884
>
> Perfect. I think this covers most cases.
>
>> Some people have suggested that <use> should also be left on. I think
>> to make this possible would require significant additional testing,
>> including test cases of unusual situations like circular references,
>> nested references, etc. If anyone wants to do that testing, feel
>> free, and ideally please document it with test cases. Note: rewriting
>> <use> in a completely different way is unlikely to make it more
>> suitable for prime time, since the biggest problem with it is that it
>> is new, relatively untested code.
>
> Agreed, it's definately new code, though the scenarios you are  
> mentioning
> are covered by tests (LayoutTests/svg/custom). In detail:
>
> SVGElementInstance tests / (SVG) DOM scripting:
> use-elementInstance-event-target.svg
> use-elementInstance-methods.svg
> use-instanceRoot-modifications.svg
> use-modify-container-in-target.svg
> use-modify-target-container.svg
> use-modify-target-symbol.svg
> use-property-changes-through-dom.svg
> use-property-changes-through-svg-dom.svg
>
> All of these tests operate on the new SVGElementInstance interfaces.
> (instanceRoot method of SVGUseElement, returns the root  
> SVGElementInstance).
>
> The built SVGElementInstance tree is tested automatically within
> use-elementInstance-methods.svg (checks instance tree consistency)
>
> event handling on <use>:
> use-event-handler-on-referenced-element.svg
> use-event-handler-on-use-element.svg
>
> Tests the various ways to set up event listeners on <use> elements:
> either on the <use> element itself, or on the referenced element.
> events have to be propagated to the SVGElementInstance (!) object, not
> the original referenced element, nor our internal clone.
>
> <use> on <use> tests:
> use-forward-refs.svg
> use-recursion-1.svg (<use> on <g> which references the <use> itself  
> again.)
> use-recursion-2.svg (<use> direct self-referencing>
> use-recursion-3.svg (<use> on <g>, containing a <use> which  
> references itself)
> use-recursion-4.svg (same like -3.svg, but one level deeper  
> referencing)
>
> This covers the "hairy" parts. Complex deep references, circular  
> references,
> self-references. All test work excellent w/o crashs or leaks.

How about cases like this:

- <use> referencing <g> which contains another <use> referencing  
something else (valid double use chain).
- valid <use> chains of larger size, like 2 or 3
- <use> inside one <g> referencing another <g> which contains a <use>  
reference back to the original <g> (loop with two <use> elements  
referencing each other's parents)
- <use> inside a marker
- <use> referencing a path with markers
- <use> referencing a path with markers which themselves contain  
<use> references (valid ones)
- <use> referencing a path with markers which themselves contain  
<use> references to a parent of the original <use> (invalid loop via  
markers)

I'm sure there must be other complex cross-referencing cases along  
these lines.

I'd also like to hear from others what they think of this level of  
testing. For now I will disable <use> along with other experimental  
features, but we could bring it back, given evidence of sufficient  
testing.

Regards,
Maciej


>
> Simple <use> examples (no deep referencing):
> use-on-g-containing-use.svg
> use-on-g.svg
> use-on-rect.svg
> use-on-symbol-inside-pattern.svg
> use-on-symbol.svg
> use-on-text.svg
> use-on-use.svg
>
> The usual suspects: simple tests - w/o fancy features.
>
> Misc:
> use-events-crash.svg
> use-symbol-overflow.svg
> use-transform.svg
>
> Other simple tests.
>
> --
> I hope the <use> on <use> tests are quite sufficient to test the  
> tricky parts
> of the new SVGUseElement / SVGElementInstance code.
>
> I'd like to invent anyone interessed to stress test the <use> code.
> We're already much better than Opera/FF/Batik (yes even Batik) with  
> the
> current implementation - and all it needs is heavy testing IMHO.
>
> Niko
>
> P.S. The only known <use> problem is that the event dispatching is not
> completely implemented. IIRC the last missing issue is: (quote from  
> 1.1 spec)
>
> "An element and all its corresponding SVGElementInstance objects  
> share an
> event listener list. The currentTarget attribute of the event can  
> be used to
> determine through which object an event listener was invoked."
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> http://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Oliver Hunt
>>
>> This covers the "hairy" parts. Complex deep references, circular  
>> references,
>> self-references. All test work excellent w/o crashs or leaks.
>
> How about cases like this:
>
> - <use> referencing <g> which contains another <use> referencing  
> something else (valid double use chain).
> - valid <use> chains of larger size, like 2 or 3
> - <use> inside one <g> referencing another <g> which contains a  
> <use> reference back to the original <g> (loop with two <use>  
> elements referencing each other's parents)
> - <use> inside a marker
> - <use> referencing a path with markers
> - <use> referencing a path with markers which themselves contain  
> <use> references (valid ones)
> - <use> referencing a path with markers which themselves contain  
> <use> references to a parent of the original <use> (invalid loop  
> via markers)
>
> I'm sure there must be other complex cross-referencing cases along  
> these lines.

Dealing with loops is relatively trivial (we already have do this for  
the toString and join methods on JS/DOM arrays) so i don't think  
those are significant problems (though obviously we would need a few  
test cases to ensure that we actually stop them -- saying we have,  
when we haven't would cause badness).  Briefly the paint method would  
require (very-pseudo-code, and i'm not sure whether this logic should  
occur in the paint code, or when constructing the render tree)
SVGUseElemenT::paint(...)
{
   static HashSet<SVGUseElement*> paintedElems;
   if (paintedElems.contains(this))
     return;
   paintedElems.add(this)
   ...
   magical painting code
   ...
   paintedElems.remove(this)
}

Now this might cause us to incorrectly filter out some nodes (i  
vaguely recall svg provides a few flow control structures, which  
might in effect cause they same use element to render differently in  
different cases, i haven't really looked into it).  That said, I  
doubt this will occur in a significant number of cases, and in the  
mean time at least this seems to be an acceptable mechanism for  
preventing looping badness.

As for the non-looping issues, i haven't really though about it in  
enough detail to be able to comment

--Oliver
_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: SVG Stabilization

Eric Gouriou-2
On Feb 25, 2007, at 16:26 , Oliver Hunt wrote:
[...]

> Dealing with loops is relatively trivial (we already have do this  
> for the toString and join methods on JS/DOM arrays) so i don't  
> think those are significant problems (though obviously we would  
> need a few test cases to ensure that we actually stop them --  
> saying we have, when we haven't would cause badness).  Briefly the  
> paint method would require (very-pseudo-code, and i'm not sure  
> whether this logic should occur in the paint code, or when  
> constructing the render tree)
> SVGUseElemenT::paint(...)
> {
>   static HashSet<SVGUseElement*> paintedElems;
>   if (paintedElems.contains(this))
>     return;
>   paintedElems.add(this)
>   ...
>   magical painting code
>   ...
>   paintedElems.remove(this)
> }

  If space (one bit) is available and if painting is guaranteed to be  
single-threaded,
a simple boolean flag in the element should suffice for this purpose  
(is_being_painted).

  Given that a static HashSet doesn't solve the threading issue anyway,
the only issue is whether there is a bit available in the Elements and
if the objects can be (temporarily) mutated during painting.

  The actual code may have to deal with abnormal termination of the  
painting sequence
though (all flags must be cleared).

   Eric

> Now this might cause us to incorrectly filter out some nodes (i  
> vaguely recall svg provides a few flow control structures, which  
> might in effect cause they same use element to render differently  
> in different cases, i haven't really looked into it).  That said, I  
> doubt this will occur in a significant number of cases, and in the  
> mean time at least this seems to be an acceptable mechanism for  
> preventing looping badness.


--
Eric Gouriou                                        
[hidden email]


_______________________________________________
webkit-dev mailing list
[hidden email]
http://lists.webkit.org/mailman/listinfo/webkit-dev