Bug 7627 – SVG from the W3C SVG 1.1 test suite (cubic01.svg) renders as all black

• Component: SVG
• Status: RESOLVED FIXED

[Rob Buis]

The svg indicated by the URL renders as one black rect, while
it should show path(s).

[Rob Buis]

Created attachment 6902 [details]
Possible fix

[Rob Buis]

Created attachment 6917 [details]
New patch

Patch tested and okayed by mitzpettel

[Darin Adler]

Comment on attachment 6917 [details]
New patch

Needs change log. Needs layout test, or perhaps an existing test already checks this. If you omit the boolean, then true is the default, so I suggest omitting it instead of passing true.

[Rob Buis]

(In reply to comment #3)
> (From update of attachment 6917 [details] [edit])
> Needs change log. Needs layout test, or perhaps an existing test already checks
> this. If you omit the boolean, then true is the default, so I suggest omitting
> it instead of passing true.
> 

Hi Darin,

I can do most of the above, however I could not explain so far
why the change works. I'd really like to be able to do this before
seeing the change in, so I'll keep looking for the reason, but
if anyone else can explain why it works, please let me know..
Cheers,

Rob.

[Darin Adler]

Comment on attachment 6917 [details]
New patch

Seems relatively straightforward to investigate further. One idea is to figure out what is parsed differently in the CSS in the different modes. The DOM inspector might even help. Another idea is to reduce this test page further.

Marking this patch review- because we don't want to land it until we understand what's wrong, and because it needs change log, layout test, etc.

[Rob Buis]

*** Bug 8041 has been marked as a duplicate of this bug. ***

[Dave Hyatt]

This is the correct fix.  SVG is always parsed in strict mode because it's XML, so passing "true" instead of checking the document's mode is the right thing to do.

[Dave Hyatt]

Comment on attachment 6917 [details]
New patch

r=me

[Rob Buis]

After quite some time looking in the wrong places, I found
out in non-strict mode in CSSGrammar.y all class values are
lower cased, causing mismatching when we really are looking for
class values with upper case in them. So class=foo is not a problem,
but class=Foo is, as shown by several testcases.
Cheers,

Rob.

[Rob Buis]

Created attachment 7509 [details]
Even more complete patch

This time it should have everything, testcase, changelogs etc...
Cheers,

Rob.

[Eric Seidel (no email)]

Comment on attachment 7509 [details]
Even more complete patch

Looks great.