300868 - target attribute not supported for SVG:a element

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jeff Schiller]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050707 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050707 Firefox/1.0+

According to the SVG spec, the <a> element should support a target attribute
that directs the browser where/how to load the linked-to document.  For instance:

<svg>
<a xlink:href="newdoc.html" target="_top">...button graphics here ...</a>
</svg>

However, Mozilla ignores this attribute and loads the newdoc.html into wherever
the SVG doc was.  This is particularly bad for SVG embedded within <object> or
<embed> tags...

Reproducible: Always

Actual Results:  
Linked-to doc was loaded into the object frame of the parent doc.

Expected Results:  
Linked-to doc should be loaded into the top frame of the browser.

Will attach test-case files...

Comment 1

[Jeff Schiller]

Attachment: Run this file with targetbug2.html and targetbug.svg in the same directory

Run this file with targetbug2.html and targetbug.svg in the same directory to
demonstrate the bug.

Comment 2

[Jeff Schiller]

Attachment: SVG file demonstrating the problem when embedded in targetbug.html

Comment 3

[Jeff Schiller]

Attachment: Test Case zip file

Sorry about the first two attachments.	This is the first time I'm attaching
anything.

This is a zip of all three files used to demonstrate the bug.  Run index.htm
once unzipped to see it.

Comment 4

[James Tomlinson]

I can confirm this too. The <a> element is however mentioned in the
implementation notes for mozilla's svg (here:
http://www.mozilla.org/projects/svg/status.html ) and also on the wiki (here:
http://wiki.mozilla.org/SVG:Linking ). I also cannot get the suggest javascript
work around to work either, but thats another story.

Comment 5

[djn]

I can reproduce this problem too. Our application embeds SVG within an HTML page using <object>. The embedded SVG contains links such as:

<a xlink:title='View details of this milestone' xlink:href='/Ketura/Projects/ProjectF.xml?ProjectPlanId=1000' target='_parent'>
...SVG graphics...
</a>

The idea is that the user clicks the link graphic, and is taken to a different HTML page, just as if they had clicked a normal HTML link in the page. At present, however, the embedded SVG object is replaced with the target HTML page. This is useless.

Note also that it is not possible to achieve the desired result using xlink:show -- the only options with that seem to be the behaviour described above or opening a new, separate, window. Neither is suitable for our application.

This problem is particularly inconvenient, because it is inconsistent with the behaviour of the Adobe SVG viewer, which works as desired.

Comment 6

[djn]

As James Tomlinson mentioned, the work-around described at http://wiki.mozilla.org/SVG:Linking does not work 

with Firefox 1.5. However, the following does:

<?xml version="1.1" ?>
<svg...>
      <g onclick="window.top.location.href='page2.html'" cursor='pointer'>
      <!-- link graphical elements here -->
      </g>
</svg>

Unfortunately, although that works for Firefox 1.5, it doesn't seem to work with the Adobe SVG Viewer 6 beta. A 

little experimentation produced the following:

<a xlink:title='View details of this milestone' xlink:href="javascript:window.top.location.href='page2.html'" 

xlink:show='replace' target='_top'>
      <!-- link graphical elements here -->
</a>

That's _really_ ugly, but works both with the Adobe SVG Viewer 3 and 6 beta under IE, and also Firefox 1.5 with 

the built-in SVG support.

I'd like to request that if anyone has any other workarounds, they post them here for the benefit of the 

community.

As an aside, I had a problem with the SVG not rendering when embedded using <object> and viewed with IE+Adobe 

SVG Viewer 3. I had previously been using <embed>, but Firefox 1.5 doesn't support this (why not?). I worked 

around this by using <iframe>, as discussed at http://www.webmapper.net/svg/serve/'

--
Daniel Neades
www.araxis.com

Comment 7

[Jeff Schiller]

More and more people will become amazed at how many problems there are with realistically deploying HTML + SVG today between ASV, Fx 1.5 and Opera 8.  

Go see http://www.codedread.com/ for an actual example of this (the menu on the left).  Fx doesn't like embed, nor does Opera, but ASV doesn't like object - so I use some JS to switch the DOM objects (an alternative is to use IE's - you have to use JS to switch the types, or use IE's conditional brackets: 

<!--[if !IE]> -->
 <object
 ...
 >
 Your browser ...
 </object>
<!-- <![endif]-->
<!--[if IE]>
 <embed
 ...
 />
<![endif]-->

Next, there's no scripting SVG in Opera 8, so I need to use framebusting JavaScripts for Opera.  It's all there in the page, but frankly it's one giant mess...it's almost enough to make one give up on integrating SVG and HTML...

Comment 8

[Robert Longson [:longsonr]]

*** Bug 323601 has been marked as a duplicate of this bug. ***

Comment 9

[Dragos Pruteanu]

Interesting, but even if I use <object data=...> and I have 
a xlink in the svg document, the target document does show only inside a iframe ( where the first svg was ). So I mean embed or object makes no difference for a correct work of xlink.

The trick with 
xlink:href="javascript:window.top.location.href='page2.html'" 
does work.
Still, this problem with xlink should be corrected.

About the embed and object I use 
<object data=...>
  <embed src=.../>
</object>
Which workded for me.

Comment 10

[Jonathan Watt [:jwatt]]

Attachment: svg with link (to be embedded)

Comment 11

[Jonathan Watt [:jwatt]]

Attachment: html link target

Comment 12

[Jonathan Watt [:jwatt]]

Attachment: svg with link (to be embedded)

Comment 13

[Jonathan Watt [:jwatt]]

Attachment: testcase

Comment 14

[Jonathan Watt [:jwatt]]

Attachment: initial test

This works, but I still need to figure out if the other two occurances of TriggerLink need the same treatment and how to best check that we are dealing with <svg:a> here.

Comment 15

[Jonathan Watt [:jwatt]]

Attachment: patch

This is close. We really want to check that we're dealing with an SVG <a> element here, but I'm not sure how best to do that. Suggestions?

The other two locations where TriggerLink are used are for xlink:actuate="onLoad" and for scrolling to make sure pseudo classes work (broken for SVG anyway, and not something I think we should fix on branch).

Comment 16

[Jonathan Watt [:jwatt]]

Attachment: patch with namespace check

Comment 17

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

This XBL madness has to stop. Couldn't we just break out the code from nsGenericHTMLElement::HandleDOMEventForAnchors into some support function and call that from both html and svg?

Comment 18

[Jonathan Watt [:jwatt]]

Absolutely. But do we want to land that on branch? This is something for branch to help the poor sods who want to embed SVG for use as navigation buttons, or anything else that requires their SVG links to load in _top rather than in the embed. Kind of a show stopper for interoperibitity for a lot of people. Once this is tested on trunk and checked in on branch I'll be nuking the XBL binding crap by implementing nsSVGAElement properly for trunk. That stuff is just a little too scary for branch thought since it requires moving the XLink stuff up to nsGenericElement etc.

Comment 19

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

I'm fine with landing this on branch-only. Though unfortunatly I think we'd want to bake it on the trunk before landing it there.

Comment 20

[Jonathan Watt [:jwatt]]

Well I'm almost finished my patch for nsSVGAElement that would nuke it on trunk, so it would only need to bake there until we agree it's cooked.

Comment 21

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

Comment on attachment 209791 [details] [diff] [review]
patch with namespace check

Cool, thanks for doing that work!

>Index: mozilla/layout/svg/base/src/resources/content/svgBindings.xml

>-      <xlink:xlink xbl:inherits="xlink:href xlink:show" xlink:type="simple">
>+      <xlink:xlink xbl:inherits="xlink:href xlink:show target" xlink:type="simple">

Since this is our own attribute we should name it as such. How about

xbl:inherits="... xlink:_moz_target=target"


>Index: mozilla/content/xml/content/src/nsXMLElement.cpp
> #include "nsLayoutAtoms.h"
>+#ifdef MOZ_SVG
>+#include "nsSVGAtoms.h"
>+#endif

Just use nsLayoutAtoms instead they're all the same these days. Or even better, use nsGkAtoms.

>+          nsAutoString target;
>+#ifdef MOZ_SVG
>+          nsIContent* parent = GetParent();
>+          if (parent->GetNameSpaceID() == kNameSpaceID_SVG &&
>+              parent->Tag() == nsSVGAtoms::a) {
>+            GetAttr(kNameSpaceID_None, nsSVGAtoms::target, target);
>+          }
>+#endif

And then always support the _moz_target attribute, no need to check for parent svg:a. You don't even need the #ifdef IMHO. In fact, the more I think about it the less I think we need to back this part of the patch out once we get a real svg:a implementation.

r=me with that

Comment 22

[Jonathan Watt [:jwatt]]

Attachment: patch with sicking's changes

I love it. :-) Here's the patch.

Comment 23

[Johnny Stenback (:jst)]

Comment on attachment 209909 [details] [diff] [review]
patch with sicking's changes

sr=jst

Comment 24

[Jonathan Watt [:jwatt]]

Checked in on trunk. I'll request approval for 1.8.1 and 1.8.0.2 once it's baked for a while.

Comment 25

[[e-mail]]

I'm pretty sure this checkin made the Camino tinderboxes burn!
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Camino

Comment 26

[Jonathan Watt [:jwatt]]

Nope, it was just tinderbox weirdness.

Comment 27

[Jonathan Watt [:jwatt]]

Checked in on 1.8 branch.

Comment 28

[Robert Longson [:longsonr]]

*** Bug 315389 has been marked as a duplicate of this bug. ***

Comment 29

[Jan Ploski]

Firefox 2.0 still ignores the target attribute. Should this bug be reopened?

Comment 30

[Jan Ploski]

(In reply to comment #29)
> Firefox 2.0 still ignores the target attribute. Should this bug be reopened?

I take my comment back, the attribute target is recognized correctly in FireFox 2.0. Sorry for the confusion!

Comment 31

[Marius Andreiana]

Hi,

target="_top" works in 2.0, but xlink:target="_top" doesn't work. Shouldn't it work too?

Thanks

Comment 32

[Jonathan Watt [:jwatt]]

No, XLink doesn't have a target attribute.