Closed Bug 300868 Opened 19 years ago Closed 19 years ago

target attribute not supported for SVG:a element


(Core :: SVG, defect)

Not set





(Reporter: codedread, Assigned: jwatt)



(Keywords: fixed1.8.1)


(5 files, 6 obsolete files)

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:

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

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...
Run this file with targetbug2.html and targetbug.svg in the same directory to
demonstrate the bug.
Attachment #189385 - Attachment is obsolete: true
Attachment #189384 - Attachment is obsolete: true
Attached file Test Case zip file (obsolete) —
Sorry about the first two attachments.	This is the first time I'm attaching

This is a zip of all three files used to demonstrate the bug.  Run index.htm
once unzipped to see it.
I can confirm this too. The <a> element is however mentioned in the
implementation notes for mozilla's svg (here: ) and also on the wiki (here: ). I also cannot get the suggest javascript
work around to work either, but thats another story.
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...

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.
As James Tomlinson mentioned, the work-around described at does not work 

with Firefox 1.5. However, the following does:

<?xml version="1.1" ?>
      <g onclick="'page2.html'" cursor='pointer'>
      <!-- link graphical elements here -->

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="'page2.html'" 

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

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 


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'

Daniel Neades
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 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]> -->
 Your browser ...
<!-- <![endif]-->
<!--[if IE]>

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's almost enough to make one give up on integrating SVG and HTML...
Ever confirmed: true
*** Bug 323601 has been marked as a duplicate of this bug. ***
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 
does work.
Still, this problem with xlink should be corrected.

About the embed and object I use 
<object data=...>
  <embed src=.../>
Which workded for me.
Attached image svg with link (to be embedded) (obsolete) —
Attached file html link target
Attachment #209773 - Attachment mime type: text/plain → text/html
Attached file testcase
Attachment #189386 - Attachment is obsolete: true
Attachment #209772 - Attachment is obsolete: true
Attached patch initial test (obsolete) — Splinter Review
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.
Attached patch patch (obsolete) — Splinter Review
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).
Assignee: general → jwatt
Attachment #209784 - Attachment is obsolete: true
Attachment #209789 - Flags: superreview?(jst)
Attachment #209789 - Flags: review?(bugmail)
Attachment #209789 - Flags: superreview?(jst)
Attachment #209789 - Flags: review?(bugmail)
Attachment #209789 - Attachment is obsolete: true
Attachment #209791 - Flags: superreview?(jst)
Attachment #209791 - Flags: review?(bugmail)
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?
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.
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.
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 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"

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);
>+          }

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
Attachment #209791 - Flags: review?(bugmail) → review+
Attachment #209791 - Flags: superreview?(jst)
I love it. :-) Here's the patch.
Attachment #209909 - Flags: superreview?(jst)
Comment on attachment 209909 [details] [diff] [review]
patch with sicking's changes

Attachment #209909 - Flags: superreview?(jst) → superreview+
Checked in on trunk. I'll request approval for 1.8.1 and once it's baked for a while.
Closed: 19 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → FIXED
I'm pretty sure this checkin made the Camino tinderboxes burn!
Nope, it was just tinderbox weirdness.
Attachment #209909 - Flags: branch-1.8.1+
Checked in on 1.8 branch.
Keywords: fixed1.8.1
*** Bug 315389 has been marked as a duplicate of this bug. ***
Firefox 2.0 still ignores the target attribute. Should this bug be reopened?
(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!


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

No, XLink doesn't have a target attribute.
You need to log in before you can comment on or make changes to this bug.