Bug 12187 - WebKit does not respect case attribute name case for SVG elements in HTML docs
Summary: WebKit does not respect case attribute name case for SVG elements in HTML docs
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://dojotoolkit.org/~alex/trunk/te...
Keywords: HasReduction
: 15276 15898 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-01-09 18:36 PST by Alex Russell
Modified: 2007-11-08 12:25 PST (History)
6 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Russell 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.
Comment 1 Nikolas Zimmermann 2007-01-22 15:55:26 PST
Hi Alex,

could you make a simple testcase? It would help a lot.

Thanks in advance,
Niko
Comment 2 Yoah Bar-David 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">
Comment 3 David Kilzer (:ddkilzer) 2007-05-28 14:56:50 PDT
Alex, should this bug block Bug 13846?

Comment 4 Yoah Bar-David 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. 
Comment 5 Alex Russell 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).
Comment 6 Eric Seidel (no email) 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.
Comment 7 Eric Seidel (no email) 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"]
Comment 8 Eric Seidel (no email) 2007-05-31 15:02:53 PDT
Created attachment 14812 [details]
better reduction
Comment 9 Eric Seidel (no email) 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.
Comment 10 Eric Seidel (no email) 2007-06-01 00:41:15 PDT
Created attachment 14816 [details]
test case showing xhtml behavior
Comment 11 Eric Seidel (no email) 2007-06-01 00:41:44 PDT
Created attachment 14817 [details]
test case showing html behavior
Comment 12 Eric Seidel (no email) 2007-06-01 01:12:01 PDT
Created attachment 14821 [details]
the fix (and test cases)
Comment 13 Dave Hyatt 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. :)
Comment 14 Dave Hyatt 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.
Comment 15 Eric Seidel (no email) 2007-06-01 01:24:19 PDT
Landed r21934 (on the feature-branch) it could be moved to TOT if so desired.
Comment 16 Eric Seidel (no email) 2007-09-26 11:44:16 PDT
*** Bug 15276 has been marked as a duplicate of this bug. ***
Comment 17 Oliver Hunt 2007-10-01 23:01:01 PDT
Hmmm, this seems to have been broken by rebasing the feature branch
Comment 18 Eric Seidel (no email) 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.
Comment 19 Alexey Proskuryakov 2007-11-08 12:21:24 PST
*** Bug 15898 has been marked as a duplicate of this bug. ***
Comment 20 Eric Seidel (no email) 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.