[webkit-reviews] review requested: [Bug 12499] External <use> xlink:href references do not work : [Attachment 83784] Draft patch, asking for a preliminary review

[bugzilla-daemon at webkit.org]

Cosmin Truta <ctruta at chromium.org> has asked  for review:
Bug 12499: External <use> xlink:href references do not work
https://bugs.webkit.org/show_bug.cgi?id=12499

Attachment 83784: Draft patch, asking for a preliminary review
https://bugs.webkit.org/attachment.cgi?id=83784&action=review

------- Additional Comments from Cosmin Truta <ctruta at chromium.org>
This is an incomplete patch. I'm asking for a preliminary review only.

I split HTMLFrameOwnerElement in three, with the parent Owner, and the children
HTMLFrameOwnerElement (same name and behavior as the old one) and
SVGResourceOwnerElement.

Then I tried to adapt Rob's patch to this design. I modified SVGUseElement
accordingly. But two essential things are still missing: loading the resource,
and using it. See the "TODO(ctruta)" placeholders, in
SVGUseElement::parseMappedAttribute, and in SVGUseElement::referencedDocument.
The bulk of the work will be in parseMappedAttribute; finishing
referencedDocument should be trivial.

Care must be taken when "file.svg#FOO" and "file.svg#BAR" appear together in
the tree (but not necessarily in the same document). Niko pointed out the
following:

How would the "frame-like" concept integrate into the existing <use> shadow
tree? Whenever a <use> element is created, it will clone it's target into it's
own shadow tree (a child of the <use> itself), and deep-clone that target tree
into the <use> shadow tree. That would remove the need for 'subresource'
loading. It's just as if the content has been textually included in the
original document.
So, if we have <use "file.svg#FOO">, then later, we encounter <use
"file.svg#BAR">, we construct the whole tree for "file.svg", then clone the
shadow subtree for "foo.svg#FOO", then do the same for "foo.svg#BAR".

In summary, here are the steps:
1) Import first external reference, include into shadow tree. Don't build
shadow tree renderers yet, only the DOM.
2) Walk the DOM, resolve any external uses, etc. Don't do any renderer creation
until the whole resolving is a) done or b) abort if it cycles.

In addition, we'll need to find a certain class/object that handles cycles.
Cycles are to be identified by URIs that match all the way to the #fragment
component (excluding the #fragment component).
I'll worry about cycles later, though. I'd be happy to see the basics done.