[Webkit-unassigned] [Bug 12499] External <use> xlink:href references do not work

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=12499


Cosmin Truta <ctruta at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ctruta at chromium.org




--- Comment #33 from Cosmin Truta <ctruta at chromium.org>  2011-02-14 14:11:17 PST ---
I looked at Rob Buis' patch, and I discussed it with Nate Chapin. The patch no longer applies to today's trunk, because of the move of WebCore into Source/, as well as other structural changes that happened since Rob's last submission in July 2010. But more importantly, there seem to be semantic issues.

In the WebKit bug 15443 "SVGImage does not support sub-resource loading" a couple of problems are outlined, one of which is the fact that subresources have a bunch of limitations when compared to the main resources. They cannot further load other subresources, etc. I believe that Niko's suggestion in comment #31 to introduce the CachedDocument class is (partially) related to the issue of having <use>'d resources act as main resources.

We (i.e. Nate and I) believe that Rob's patch that modifies classes from WebCore/loader/cache/ (CachedResource, CachedResourceClient, CachedResourceLoader, etc.) can only deal with subresources, just like anything else that is accessing these classes. (Anything that goes through this cache is a subresource -- CachedResourceRequest is the loader client for subresources.) We might therefore get a strange behavior, because we're loading something that should be a main resource, as a subresource; but subresources are not designed to carry themselves other subresources.

Instead, a solution that resembles handling of frames in HTML would be the better way to go. Load <use>'d elements as real frames, not as subresources.
Loading HTML frames is handled by the means of the class HTMLFrameOwnerElement. We could have a similar class, say, SVGAssetOwnerElement, that could perhaps share a common ancestor with HTMLFrameOwnerElement, (let's call it Owner), and then split the semantics: the HTML-specific semantics would go to HTMLFrameOwnerElement, while the SVG-specific semantics would go to SVGAssetOwnerElement. (And "SVG asset" could be <svg>, <g>, <symbol>, or anything else that could be <use>'d.)

  class Owner
  class HTMLFrameOwnerElement : public Owner, public HTMLElement
  class SVGAssetOwnerElement : public Owner, public SVGElement
  class SVGTextAssetOwnerElement : public SVGAssetElement  // used by <tref>

Perhaps, to avoid confusion that might arise because these classes do not correspond directly to actual elements, alternative names like HTMLFrameOwner (instead of HTMLFrameOwnerElement) and SVGAssetOwner (instead of SVGAssetOwnerElement) might be better.

Security-wise, just as with the current HTMLFrameOwnerElement, we must be careful about the newly-introduced SVGAssetOwnerElement. As far as I know, SVG has no SandboxFlags, although, I think it should. At least in the beginning, SVGAssetOwnerElement's SandboxFlags should be set to SandboxNone (and tested for that).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.