246514 - Errors in SVG content don't cause SVG rendering to abort

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Hixie (not reading bugmail)]

According to:
   http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing
..., when an element or attribute is encountered in the document which is not
part of the SVG DTD and which is not properly identified as being part of
another namespace, and when an element has an attribute or property value which
is not permissible according to the specification, the document shall be
rendered up to, but not including, the first element which has an error, and a
highly perceivable indication of error shall occur.

We don't do this:
   http://www.hixie.ch/tests/adhoc/svg/error/001.xml
   http://www.hixie.ch/tests/adhoc/svg/error/003.xml
   http://www.hixie.ch/tests/adhoc/svg/error/007.xml
   http://www.hixie.ch/tests/adhoc/svg/error/008.xml
   http://www.hixie.ch/tests/adhoc/svg/error/009.xml

For the purposes of this bug, I propose that "document" be interpreted as "SVG
document fragment". That is, we should skip to the end of the <svg> element, but
further processing should continue (since SVG can't give error handling rules
for non-SVG content).

Comment 1

[Jonathan Watt [:jwatt]]

Mass reassign of SVG bugs that aren't currently being worked on by Alex to
[e-mail]. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later. 

Comment 2

[Hixie (not reading bugmail)]

IMHO this should be a blocker for turning SVG on by default.

Comment 3

[Boris Zbarsky [:bzbarsky]]

We're not a validating parser... so I don't think we can reasonably implement this.

Comment 4

[Hixie (not reading bugmail)]

You wouldn't have to be validating (indeed in SVG 1.2, since it doesn't have a
DTD, being a validating parser wouldn't help anyway; even in SVG 1.1, the fact
that documents can pass in and out of error by DOM changes would mean that a
validating parser wouldn't help).

The SVG code just needs to keep track of when constraints are violated, and
abort rendering while it is.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Would the SVG version to check against be keyed off the <svg> "version" attribute?

Comment 6

[Hixie (not reading bugmail)]

My understanding is that you would check against the version that the UA implements.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That is a very crappy backward compatibility story.

Comment 8

[Hixie (not reading bugmail)]

Tell the SVG working group.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I guess I will.

Comment 11

[Jonathan Watt [:jwatt]]

WONTFIX

Comment 12

[Helder "Lthere" Magalhães]

(In reply to comment #11)
> WONTFIX

Just to clear up my understanding of this: does not fixing this means that an effort to render the document as much as possible will always be made? (Even if/when portions of the document are in error.)

Comment 13

[Jonathan Watt [:jwatt]]

Pretty much. It means that we will not be following the error handling model linked to in comment 0. We'll be looking to SVG Tiny 1.2 (which defines much saner error handling) on a case by case basis. Where it defines behavior we'll do what it defines. When it does not, I'll bring it up in the working group and we'll try to get consensus.