Bug 12187

Summary: WebKit does not respect case attribute name case for SVG elements in HTML docs
Product: WebKit Reporter: Alex Russell <alex>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: eric, eugene.lazutkin, oliver, sjoerdmulder, yoah, zimmermann
Priority: P2 Keywords: HasReduction
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
URL: http://dojotoolkit.org/~alex/trunk/tests/gfx/test_linearGradient.html
Attachments:
Description Flags
Sample file where instead of a gradient you see a solid fill
none
better reduction
none
test case showing xhtml behavior
none
test case showing html behavior
none
the fix (and test cases) hyatt: review+

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+
DetailsFormatted DiffDiff
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.