| Summary: | WebKit does not respect case attribute name case for SVG elements in HTML docs | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alex Russell <alex> | ||||||||||||
| Component: | SVG | Assignee: | 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
Alex Russell
2007-01-09 18:36:28 PST
Hi Alex, could you make a simple testcase? It would help a lot. Thanks in advance, Niko 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"> 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. 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). 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. 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"]
Created attachment 14812 [details]
better reduction
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.
Created attachment 14816 [details]
test case showing xhtml behavior
Created attachment 14817 [details]
test case showing html behavior
Created attachment 14821 [details]
the fix (and test cases)
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 on attachment 14821 [details]
the fix (and test cases)
Never mind. Eric convinced me this is not going to happen.
Landed r21934 (on the feature-branch) it could be moved to TOT if so desired. *** Bug 15276 has been marked as a duplicate of this bug. *** Hmmm, this seems to have been broken by rebasing the feature branch 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. *** Bug 15898 has been marked as a duplicate of this bug. *** 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. |