12187 – WebKit does not respect case attribute name case for SVG elements in HTML docs

RESOLVED FIXED 12187

WebKit does not respect case attribute name case for SVG elements in HTML docs

https://bugs.webkit.org/show_bug.cgi?id=12187

Summary WebKit does not respect case attribute name case for SVG elements in HTML docs

Alex Russell

Reported 2007-01-09 18:36:28 PST

while linear gradients appear to work correctly from markup, creating a DOM structure that correctly renders an SVG linear gradient on FF2 and Opera 9 fails to do so on webkit nightlies. See the referenced URL for an example.

Attachments
Sample file where instead of a gradient you see a solid fill (1.57 KB, text/html) 2007-05-27 02:37 PDT, Yoah Bar-David	no flags	Details
better reduction (471 bytes, text/html) 2007-05-31 15:02 PDT, Eric Seidel (no email)	no flags	Details
test case showing xhtml behavior (4.51 KB, application/xhtml+xml) 2007-06-01 00:41 PDT, Eric Seidel (no email)	no flags	Details
test case showing html behavior (4.51 KB, text/html) 2007-06-01 00:41 PDT, Eric Seidel (no email)	no flags	Details
the fix (and test cases) (16.36 KB, patch) 2007-06-01 01:12 PDT, Eric Seidel (no email)	hyatt: review+	Details Formatted Diff Diff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Nikolas Zimmermann

Comment 1 2007-01-22 15:55:26 PST

Hi Alex, could you make a simple testcase? It would help a lot. Thanks in advance, Niko

Yoah Bar-David

Comment 2 2007-05-27 02:37:53 PDT

Created attachment 14747 [details] Sample file where instead of a gradient you see a solid fill Note that if this file is saved as test.html, the rectangle is filled in solid red (where in Firefox it has a linear gradient fill). If you change the file name to text.xml, and change the headers to be as follows, the linear gradient is displayed well. <?xml version="1.0"?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

David Kilzer (:ddkilzer)

Comment 3 2007-05-28 14:56:50 PDT

Alex, should this bug block Bug 13846?

Yoah Bar-David

Comment 4 2007-05-28 22:00:04 PDT

Note that the bug was also found in another application (not using dojo), and the sample file I attached earlier is not related to dojo.

Alex Russell

Comment 5 2007-05-30 14:11:08 PDT

Hey David, I wasn't aware of #13846. This is something of a problem for dojox.gfx, but not necessarialy dojotoolkit.org itself. Also, does Yoah's reduction pass muster? It seems to exercise the same issue the same way as dojo.gfx (save with less code in the way).

Eric Seidel (no email)

Comment 6 2007-05-31 14:10:52 PDT

This has nothing to do with gradients. This has to do with WebKit treating HTML docs different from an XML/XHTML document and different still from an SVG document. As previously mentioned, if this document is served as XHTML the gradient works just fine.

Eric Seidel (no email)

Comment 7 2007-05-31 14:44:21 PDT

Actually I was wrong. This has something to do with gradientUnits being set incorrectly. Note the difference between the two dump render tree dumps: diff xhtml-results html-results: --- test1-expected.txt 2007-05-31 14:39:47.000000000 -0700 +++ test2-expected.txt 2007-05-31 14:39:48.000000000 -0700 @@ -1,13 +1,13 @@ -KRenderingPaintServer {id="lgrad" [type=LINEAR-GRADIENT] [stops=[(0.00,#FF0000), (1.00,#FFFF00)]] [bounding box mode=0] [start=(0,0)] [end=(300,0)]} +KRenderingPaintServer {id="lgrad" [type=LINEAR-GRADIENT] [stops=[(0.00,#FF0000), (1.00,#FFFF00)]] [start=(0,0)] [end=(300,0)]} layer at (0,0) size 800x600 RenderView at (0,0) size 800x600 -layer at (0,0) size 800x316 - RenderBlock {html} at (0,0) size 800x316 - RenderBody {body} at (8,8) size 784x300 - RenderBlock {div} at (0,0) size 600x300 +layer at (0,0) size 800x600 + RenderBlock {HTML} at (0,0) size 800x600 + RenderBody {BODY} at (8,8) size 784x584 + RenderBlock {DIV} at (0,0) size 600x300 RenderSVGContainer {svg} at (18,18) size 300x200 RenderSVGHiddenContainer {defs} at (0,0) size 0x0 RenderSVGHiddenContainer {linearGradient} at (0,0) size 0x0 RenderSVGGradientStop {stop} at (0,0) size 0x0 RenderSVGGradientStop {stop} at (0,0) size 0x0 - RenderPath {rect} at (18,18) size 300x200 [fill={[type=LINEAR-GRADIENT] [stops=[(0.00,#FF0000), (1.00,#FFFF00)]] [bounding box mode=0] [start=(0,0)] [end=(300,0)]}] [data="M10.00,10.00L310.00,10.00L310.00,210.00L10.00,210.00"] + RenderPath {rect} at (18,18) size 300x200 [fill={[type=LINEAR-GRADIENT] [stops=[(0.00,#FF0000), (1.00,#FFFF00)]] [start=(0,0)] [end=(300,0)]}] [data="M10.00,10.00L310.00,10.00L310.00,210.00L10.00,210.00"]

Eric Seidel (no email)

Comment 8 2007-05-31 15:02:53 PDT

Created attachment 14812 [details] better reduction

Eric Seidel (no email)

Comment 9 2007-05-31 15:48:27 PDT

Ha! Found the problem. It's Element.cpp:434: String localName = inHTMLDocument(this) ? name.lower() : name; That breaks attributes for SVG elements when they're in an HTML doc. I'm not sure why that check exists as such. It probably should be based on the element and not on which doc its in.

Eric Seidel (no email)

Comment 10 2007-06-01 00:41:15 PDT

Created attachment 14816 [details] test case showing xhtml behavior

Eric Seidel (no email)

Comment 11 2007-06-01 00:41:44 PDT

Created attachment 14817 [details] test case showing html behavior

Eric Seidel (no email)

Comment 12 2007-06-01 01:12:01 PDT

Created attachment 14821 [details] the fix (and test cases)

Dave Hyatt

Comment 13 2007-06-01 01:19:14 PDT

Comment on attachment 14821 [details] the fix (and test cases) I think tag names suffer from the same bug, e.g., feComposite. Should probably rename the method shouldIgnoreAttributeCase to something more generic like "isCaseInsensitiveHTML". Bonus points if you fix tag names too in a followup bug. :)

Dave Hyatt

Comment 14 2007-06-01 01:20:59 PDT

Comment on attachment 14821 [details] the fix (and test cases) Never mind. Eric convinced me this is not going to happen.

Eric Seidel (no email)

Comment 15 2007-06-01 01:24:19 PDT

Landed r21934 (on the feature-branch) it could be moved to TOT if so desired.

Eric Seidel (no email)

Comment 16 2007-09-26 11:44:16 PDT

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

Oliver Hunt

Comment 17 2007-10-01 23:01:01 PDT

Hmmm, this seems to have been broken by rebasing the feature branch

Eric Seidel (no email)

Comment 18 2007-10-02 15:18:59 PDT

The updated results are actually better than before. Well, better for xhtml, worse for HTML. But I'm not sure that anyone cares that HTML elements have a namespaceURI containing the xhtml namespace.

Alexey Proskuryakov

Comment 19 2007-11-08 12:21:24 PST

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

Eric Seidel (no email)

Comment 20 2007-11-08 12:25:28 PST

Just to clarify, this did *not* ever get moved to (then) TOT from feature-branch, so it did *not* ship as part of Safari 3, however it should still be fixed the current TOT.

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