281741 - We should implement the GetSVGDocument interface for HTMLEmbedElement

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

This is a major problem for anyone who has scripts in an HTML document that
needs access to an SVG document embeded by reference.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure I would call it a 'major problem', just use .contentDocument rather
then .getSVGDocument()

But yes, it's another (arguably useless) part of the spec we don't implement.

Do they expect this interface to be implemented by <img> elements too? That
would make it slightly more usefull.

Comment 2

[Jonathan Watt [:jwatt]]

It's a major problem in terms of interoperability. In IE+ASV the
HTMLObjectElement interface isn't implemented, and we don't provide a direct
means of HTML -> SVG communication if the SVG document is embeded using the
'embed' element.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

.contentDocument works on <embed> too so we should.

So Adobe has implemented .getSVGDocument() on affected elements in IE and that
is what's causing problems?

I'm not arguing that we shouldn't implement this. I'm just arguing that it might
not be a very important feature.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

And what about XHTML2? There pretty much any element can link to an image, does
that mean that almost every xhtml2 element should implement this interface?

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to comment #3)
> .contentDocument works on <embed> too so we should.

It wasn't implemented last time I checked, and it doesn't look like the 'embed'
element provides any other way to access the embeded document. Am I missing
something here?

I haven't properly explained why authors are currently in a catch 22, so let me
try to clear things up now. In IE, ASV has completely removed the ability for
scripts in one document to access the other if the SVG document is embeded using
the 'object' tag. The reason for this is explained in the following quote from
adobe.com

-------------------------------------------------------------------------------
Adobe SVG Viewer 3.01 addresses one potential security risk by disabling SVG
scripts if you disable ActiveScripting in Internet Explorer. This security risk
only affects customers who browse the Web on Windows computers in Internet
Explorer with ActiveScripting disabled. By default, ActiveScripting is enabled,
so most users are not currently at risk. Because of the way that the HTML OBJECT
tag is implemented in Internet Explorer, Adobe SVG Viewer 3.01 cannot determine
the URL of a file embedded with the OBJECT tag. The URL is required to determine
the security zone, which is required to determine the state of the
ActiveScripting setting. Therefore, to fail safe against this potential security
flaw Adobe SVG Viewer 3.01 always disables scripting when it determines that the
SVG file is embedded using the OBJECT tag. When authoring in SVG, Adobe
recommends that you not use the OBJECT tag and instead use the EMBED tag when
embedding SVG in HTML pages.
-------------------------------------------------------------------------------

This block is going to be around for some time, so SVG content authors that want
their cross-document scripts to work in IE + ASV will not be using the 'object'
tag. The obvious alternative is to use the 'embed' tag, but given that I
couldn't find a way to script HTML -> SVG in Mozilla when 'embed' is used, I was
worried authors will have to choose between ASV and us.

(In reply to comment #4)
> And what about XHTML2? There pretty much any element can link to an image, does
> that mean that almost every xhtml2 element should implement this interface?

urk, really? Sounds like an issue that should be raised with the SVG WG. Care to
do it since you seem to know about xhtml2?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I can raise this with the WG. I have a complete list that i'll be sending them
shortly so i'll just add it to that list.

Hmm.. i could have sworn I saw .contentDocument in nsIDOMHTMLEmbedElement.idl,
but it appears I was wrong. Defenetly makes sense to implement it there then.
What a bummer that people are forced to use embed, especially given that it has
such a crappy interface (though that's our fault)

Comment 7

[Jonathan Watt [:jwatt]]

Attachment: patch

Comment 8

[Jonathan Watt [:jwatt]]

Attachment: patch without adding GetSVGDocument as a class to nsDOMClassInfo

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 176946 [details] [diff] [review]
patch without adding GetSVGDocument as a class to nsDOMClassInfo

sr=jst

Comment 10

[tor]

Shouldn't we handle <object> as well?

Comment 11

[Jonathan Watt [:jwatt]]

I can add another patch for it if you like, but I was trying to limit what we
apply this SVG WG hack to. There isn't any pressing need for it on <object> ATM.
In ASV if you want to script across the embeding boundary you need to use
<embed>. If you are only writing for Moz and you want to use <object> you can
use contentDocument.

Comment 12

[Anne (:annevk)]

> (In reply to comment #4)
>> And what about XHTML2? There pretty much any element can link to an image, does
>> that mean that almost every xhtml2 element should implement this interface?
> 
> urk, really? Sounds like an issue that should be raised with the SVG WG. Care to
> do it since you seem to know about xhtml2?

Why with the SVG WG? But yes, in XHTML 2 every element can link and every
element can embed something. However, this is possible in every XML based
language using XLink too. (I believe we do not have support for that XLink type
yet, but eventually, we will.)

It will also be possible using CSS3: |element{ content:url(foo) }| which is
supposed to be behave just like OBJECT. (It can be used to implement OBJECT.)

Comment 13

[Boris Zbarsky [:bzbarsky]]

> It will also be possible using CSS3: |element{ content:url(foo) }| which is
> supposed to be behave just like OBJECT. (It can be used to implement OBJECT.)

It behaves like OBJECT as far as rendering goes.  It does NOT necessarily have
OBJECT semantics (since CSS does not change semantics).  The exposed DOM
interfaces are part of the node's semantics.

Comment 14

[Jonathan Watt [:jwatt]]

Checked in - marking fixed. I opened bug 287465 to deal with <object>.

Comment 15

[bugzilla.mozilla.org]

hi,

I try to make an existing SVG app to work with Mozilla native SVG and came
across this issue. 

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050418 I
cannot seem to get the GetSVGDocument() to work.

the SVG is acessed via an EMBED in the HTML page:
<EMBED width="955" height="555"
       pluginspage="/intranet/floorplan/Adobe_SVG_Viewer_3.0_v1.msi"
       type="image/svg+xml" src="version2/lon.svg" id="svge"
       adblockframedobject2="true" adblockframename="adblock-frame-n1" style=""/>


I try to access the svgDocument like this
function /*:svgDocument:*/ getsvgDoc() {
	var svgObj = document.getElementById("svge");
	if (svgObj != undefined) {
		return svgObj.GetSVGDocument(); //line 351
	} else {
		return null;
	}
}

I get an error: 
Error: svgObj.GetSVGDocument is not a function
Source File: http://inetdev.bcg.com/intranet/floorplan/version2/svghandler.js
Line: 351

the var svgObj correctly points to the HTMLEmbedElement

is this supposed to work or did I misunderstand the bug?

thanks

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

From script the function is called .getSVGDocument(). I.e. use a lowercase 'g'.
And make sure you use a recent enough version of mozilla.

Comment 17

[bugzilla.mozilla.org]

stupid me, thanks, now it works!