The default bug view has changed. See this FAQ.

If no fallback colour is specified we shouldn't draw anything when the URL fails to resolve

RESOLVED FIXED in mozilla15

Status

()

Core
SVG
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Robert Longson, Assigned: Robert Longson)

Tracking

Trunk
mozilla15
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

Comment hidden (empty)
(Assignee)

Comment 1

5 years ago
Per the 2nd edition SVG testsuite test in the URL.
(Assignee)

Comment 2

5 years ago
Created attachment 616182 [details] [diff] [review]
patch
Assignee: nobody → longsonr
Attachment #616182 - Flags: review?(dbaron)
(Assignee)

Comment 3

5 years ago
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 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?)
Attachment #616182 - Flags: review?(dbaron) → review+
(Assignee)

Comment 5

5 years ago
(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.
(Assignee)

Comment 6

5 years ago
pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/956287d79825
Flags: in-testsuite+
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/956287d79825
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.