Last Comment Bug 746632 - If no fallback colour is specified we shouldn't draw anything when the URL fails to resolve
: If no fallback colour is specified we shouldn't draw anything when the URL fa...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla15
Assigned To: Robert Longson
:
Mentors:
http://www.w3.org/Graphics/SVG/Test/2...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-18 10:00 PDT by Robert Longson
Modified: 2012-04-25 20:41 PDT (History)
2 users (show)
longsonr: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (1.26 KB, patch)
2012-04-18 10:02 PDT, Robert Longson
dbaron: review+
Details | Diff | Splinter Review

Description Robert Longson 2012-04-18 10:00:18 PDT

    
Comment 1 Robert Longson 2012-04-18 10:02:09 PDT
Per the 2nd edition SVG testsuite test in the URL.
Comment 2 Robert Longson 2012-04-18 10:02:53 PDT
Created attachment 616182 [details] [diff] [review]
patch
Comment 3 Robert Longson 2012-04-18 10:06:26 PDT
The specification text in question is here: http://www.w3.org/TR/SVG/painting.html#SpecifyingPaint 

In this case the document is in error so we shouldn't render that element.
Comment 4 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2012-04-22 15:40:07 PDT
Comment on attachment 616182 [details] [diff] [review]
patch

This seems entirely reasonable, but I really don't see anything in the spec that says this.  All I see in the spec is:

      If the IRI reference is not valid (e.g., it points to an object that doesn't exist or the object is not a valid paint server), then the paint method following the <funciri> (i.e., none | currentColor | <color> [<icccolor>] is used if provided; otherwise, the document is in error (see Error processing).

which implies to me that the spec says the document is in error in this case.  (I'm looking at REC-SVG11-20110816, which I have an offline copy of; I'm on a slow network right now and the URL you gave doesn't load).

So r=dbaron, I suppose, since the behavior seems better even though the spec doesn't (AFAICT) say that either old or new behavior is correct.

Seems like it's worth raising a spec or testsuite issue unless I'm missing something in the spec, though.  (Does this change us to match other browsers?)
Comment 5 Robert Longson 2012-04-23 00:58:58 PDT
(In reply to David Baron [:dbaron] from comment #4)
> 
> which implies to me that the spec says the document is in error in this
> case.  (I'm looking at REC-SVG11-20110816, which I have an offline copy of;
> I'm on a slow network right now and the URL you gave doesn't load).

Right.

> 
> So r=dbaron, I suppose, since the behavior seems better even though the spec
> doesn't (AFAICT) say that either old or new behavior is correct.
> 
> Seems like it's worth raising a spec or testsuite issue unless I'm missing
> something in the spec, though.  (Does this change us to match other
> browsers?)

There is a testsuite test for it - the URL in this bug points to it.

We would match Opera and IE9 with this fix.
Comment 7 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-04-25 20:41:42 PDT
https://hg.mozilla.org/mozilla-central/rev/956287d79825

Note You need to log in before you can comment on or make changes to this bug.