target attribute not supported for SVG:a element

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: codedread, Assigned: jwatt)

Tracking

({fixed1.8.1})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 6 obsolete attachments)

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...
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
Posted file Test Case zip file (obsolete) —
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.
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.
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.
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
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...
Status: UNCONFIRMED → NEW
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 
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.
Posted image svg with link (to be embedded) (obsolete) —
Posted file html link target
Attachment #209773 - Attachment mime type: text/plain → text/html
Posted file testcase
Attachment #189386 - Attachment is obsolete: true
Attachment #209772 - Attachment is obsolete: true
Posted 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.
Posted 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
Status: NEW → ASSIGNED
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"
>+#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
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

sr=jst
Attachment #209909 - Flags: superreview?(jst) → superreview+
Checked in on trunk. I'll request approval for 1.8.1 and 1.8.0.2 once it's baked for a while.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → FIXED
I'm pretty sure this checkin made the Camino tinderboxes burn!
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Camino
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!

Hi,

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

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