Summary: | Remove support for Attr nodes for ~600k memory savings on membuster | ||
---|---|---|---|
Product: | WebKit | Reporter: | Maciej Stachowiak <mjs> |
Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | alice.barraclough, ap, cdumez, sam |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Mac | ||
OS: | OS X 10.5 |
Description
Maciej Stachowiak
2008-11-14 19:56:58 PST
Removing Attr node support may break XPath pretty badly (I haven't looked into XPath implementation again to be sure, but I think that many practical cases depend on Attr nodes being supported). (In reply to comment #1) > Removing Attr node support may break XPath pretty badly (I haven't looked into > XPath implementation again to be sure, but I think that many practical cases > depend on Attr nodes being supported). Can you expand on this? Does this break functionality in Firefox? I just remember that XPath was pretty big on creating Attr nodes from attributes, which is why I had to optimize that code path. If anything breaks, tests will tell. I'm not sure how what Firefox has to do with this - it's just an implementation detail of XPath, it can certainly be special-cased to use custom attribute values instead of Attr nodes internally. (In reply to comment #0) > Other browsers do not support Attr nodes In both Opera and Firefox 3, I'm getting the same Attr node when calling getAttributeNode() twice in a row, so it seems that they are referenced in DOM. What is the difference from WebKit in their Attr node support? As discussed on IRC, this bug is not valid, because other browsers do support Attr nodes. It may be possible to make use of the fact that these nodes are rarely used though. Mass moving XML DOM bugs to the "DOM" Component. |