83056 2012-04-03 12:19:01 -0700 Serializing SVG removes namespace from attributes 2013-08-29 10:22:30 -0700 1 1 1 Unclassified WebKit XML 528+ (Nightly build) Mac OS X 10.7 RESOLVED FIXED http://bl.ocks.org/2294676 P2 Normal --- 0 enjalot webkit-unassigned alex ap rwlbuis oldest_to_newest 594732 0 enjalot 2012-04-03 12:19:01 -0700 I've coded an example which uses DOM serialization to rasterize some SVG with Canvas: http://bl.ocks.org/2294676 In Webkit (but not Firefox) I have to run a regular expression on my serialized SVG to add back the xlink: to my xlink:href attributes. This may be caused by this bug: https://bugs.webkit.org/show_bug.cgi?id=22958 It may be related to an issue here: http://stackoverflow.com/questions/8979267/xmlserializer-strips-xlink-from-xlinkhtml-svg-image-tag but I'm not sure it's the same thing since I am not dynamically generating these DOM elements 595829 1 ap 2012-04-04 13:07:44 -0700 Duplicate of bug 79586? 595836 2 rwlbuis 2012-04-04 13:13:57 -0700 (In reply to comment #1) > Duplicate of bug 79586? Very likely. Fixing 79586 should fix this one as well. Cheers, Rob. 901593 3 alex 2013-06-18 17:13:16 -0700 This is the same as bug 22958. 902801 4 rwlbuis 2013-06-22 11:26:36 -0700 This seems fixed to me. I think the 79586 bugfix fixed this as well. 902812 5 205257 alex 2013-06-22 16:14:06 -0700 Created attachment 205257 Example of two ways to do the same thing The attached example does the same thing slightly differently. Both are correct from a DOM/JS perspective but the second requires the serializer to generate a prefix. The current serializer code fails to do this correctly. Thus, it really depends on how you define fixed. Is it fixed to leave a known issue? IMHO, this is really fixed when bug 22958 is fixed. 902817 6 rwlbuis 2013-06-22 19:18:16 -0700 Hi Alex, (In reply to comment #5) > Created an attachment (id=205257) [details] > Example of two ways to do the same thing > > The attached example does the same thing slightly differently. Both are correct from a DOM/JS perspective but the second requires the serializer to generate a prefix. The current serializer code fails to do this correctly. > > Thus, it really depends on how you define fixed. Is it fixed to leave a known issue? IMHO, this is really fixed when bug 22958 is fixed. I meant fixed in the sense that the blocks page works. Or rather, when taking it and removing the webkit specific replace hack it works. I am updating my patch for bug 16496, hopefully it can fix more than just that bug, since it seems like there is some overlap in the XMLSerializer bugs. 902861 7 alex 2013-06-23 20:46:45 -0700 Sure. That makes sense. I don't know what the policy is for closing bugs like this. Certainly the problem described for that particular page is fixed within the current code. 902943 8 rwlbuis 2013-06-24 07:08:28 -0700 (In reply to comment #7) > Sure. That makes sense. > > I don't know what the policy is for closing bugs like this. Certainly the problem described for that particular page is fixed within the current code. Well, the latest patch on bug 16496 fixes both of the problems in your testcase. So once that goes in, we can close this bug too, though we have to check whether we want to keep your testcase in the tests. 903071 9 alex 2013-06-24 14:35:33 -0700 (In reply to comment #8) > (In reply to comment #7) > > Sure. That makes sense. > > > > I don't know what the policy is for closing bugs like this. Certainly the problem described for that particular page is fixed within the current code. > > Well, the latest patch on bug 16496 fixes both of the problems in your testcase. So once that goes in, we can close this bug too, though we have to check whether we want to keep your testcase in the tests. I took a peek at this patch. It doesn't look like it handles the general problems with the serializer but certainly can address issues with the SVG and xlink namespace/prefix. The real fix requires an adjustment to the algorithm to keep track of generated prefixes and/or their declaration. That is, you need to general prefixes as necessary, not just for known namespaces, and the keep track of their scope. Neither of those happen currently in the MarkupAccumulator.cpp code. See bug 117764 for some more esoteric examples of where this breaks down. That said, I'm happy to close out specific bugs with smaller changes and wait for the general one to be addressed. 903078 10 rwlbuis 2013-06-24 14:51:54 -0700 Hi Alex, (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > Sure. That makes sense. > > > > > > I don't know what the policy is for closing bugs like this. Certainly the problem described for that particular page is fixed within the current code. > > > > Well, the latest patch on bug 16496 fixes both of the problems in your testcase. So once that goes in, we can close this bug too, though we have to check whether we want to keep your testcase in the tests. > > I took a peek at this patch. It doesn't look like it handles the general problems with the serializer but certainly can address issues with the SVG and xlink namespace/prefix. > > The real fix requires an adjustment to the algorithm to keep track of generated prefixes and/or their declaration. That is, you need to general prefixes as necessary, not just for known namespaces, and the keep track of their scope. Neither of those happen currently in the MarkupAccumulator.cpp code. Yeah, my thinking was follow the "hardcoded" handling of attribute prefixes (xlink, xml xmlns) in appendAttribute for now to be on the safe side. I am relying on review iterations to improve the code quality :) > See bug 117764 for some more esoteric examples of where this breaks down. Thanks. > That said, I'm happy to close out specific bugs with smaller changes and wait for the general one to be addressed. Yep, see above, I am trying to be pragmatic about it. It is hard enough to pass all/not brrak tests and/or make the serialized test output sane :) 904345 11 rwlbuis 2013-06-27 14:06:38 -0700 > I took a peek at this patch. It doesn't look like it handles the general problems with the serializer but certainly can address issues with the SVG and xlink namespace/prefix. > > > The real fix requires an adjustment to the algorithm to keep track of generated prefixes and/or their declaration. That is, you need to general prefixes as necessary, not just for known namespaces, and the keep track of their scope. Neither of those happen currently in the MarkupAccumulator.cpp code. I am starting fixing this in bug 19121. It would be nice if you could have a look :) 922527 12 rwlbuis 2013-08-29 10:22:30 -0700 Committed r154779: <http://trac.webkit.org/changeset/154779> 205257 2013-06-22 16:14:06 -0700 2013-06-22 16:14:06 -0700 Example of two ways to do the same thing 83056.xhtml application/xhtml+xml 1051 alex PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgo8aGVhZD48dGl0bGU+ QnVnIDgzMDU2PC90aXRsZT48L2hlYWQ+Cjxib2R5Pgo8c2NyaXB0IHR5cGU9InRleHQvamF2YXNj cmlwdCI+Ci8vIDgzMDU2IGV4YW1wbGUgZnJvbSBzdGFja292ZXJsZm93CnZhciB0ZW1wID0gZG9j dW1lbnQuY3JlYXRlRWxlbWVudE5TKCJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIsImltYWdl Iik7CnRlbXAuc2V0QXR0cmlidXRlTlMobnVsbCwieCIsIjAiKTsKdGVtcC5zZXRBdHRyaWJ1dGVO UyhudWxsLCJ5IiwiMCIpOwp0ZW1wLnNldEF0dHJpYnV0ZU5TKG51bGwsImhlaWdodCIsIjgwIik7 CnRlbXAuc2V0QXR0cmlidXRlTlMobnVsbCwid2lkdGgiLCI0MCIpOwp0ZW1wLnNldEF0dHJpYnV0 ZU5TKCJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiwieGxpbms6aHJlZiIsInJvb21sYXlv dXRzL2l0ZW1zLyBjYWN0dXMuc3ZnIik7CnZhciBzZXJpYWxpemVyID0gbmV3IFhNTFNlcmlhbGl6 ZXIoKTsKdmFyIHhtbFN0cmluZyA9IHNlcmlhbGl6ZXIuc2VyaWFsaXplVG9TdHJpbmcodGVtcCk7 CmNvbnNvbGUubG9nKHhtbFN0cmluZyk7CgovLyByZWxhdGVkIGV4YW1wbGUgdGhhdCBkb2Vzbid0 CnZhciB0ZW1wMiA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbnROUygiaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciLCJpbWFnZSIpOwp0ZW1wMi5zZXRBdHRyaWJ1dGVOUyhudWxsLCJ4IiwiMCIpOwp0 ZW1wMi5zZXRBdHRyaWJ1dGVOUyhudWxsLCJ5IiwiMCIpOwp0ZW1wMi5zZXRBdHRyaWJ1dGVOUyhu dWxsLCJoZWlnaHQiLCI4MCIpOwp0ZW1wMi5zZXRBdHRyaWJ1dGVOUyhudWxsLCJ3aWR0aCIsIjQw Iik7CnRlbXAyLnNldEF0dHJpYnV0ZU5TKCJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiwi aHJlZiIsInJvb21sYXlvdXRzL2l0ZW1zLyBjYWN0dXMuc3ZnIik7CnhtbFN0cmluZyA9IHNlcmlh bGl6ZXIuc2VyaWFsaXplVG9TdHJpbmcodGVtcDIpOwpjb25zb2xlLmxvZyh4bWxTdHJpbmcpOwo8 L3NjcmlwdD4KPC9ib2R5Pgo8L2h0bWw+Cg==