Last Comment Bug 300868 - target attribute not supported for SVG:a element
: target attribute not supported for SVG:a element
Status: RESOLVED FIXED
: fixed1.8.1
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal with 6 votes (vote)
: ---
Assigned To: Jonathan Watt [:jwatt] (catching up after vacation)
: Hixie (not reading bugmail)
Mentors:
: 315389 323601 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-14 21:24 PDT by Jeff Schiller
Modified: 2006-10-25 04:11 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Run this file with targetbug2.html and targetbug.svg in the same directory (284 bytes, text/html)
2005-07-14 21:26 PDT, Jeff Schiller
no flags Details
SVG file demonstrating the problem when embedded in targetbug.html (463 bytes, image/svg+xml)
2005-07-14 21:27 PDT, Jeff Schiller
no flags Details
Test Case zip file (1.05 KB, application/zip)
2005-07-14 21:30 PDT, Jeff Schiller
no flags Details
svg with link (to be embedded) (449 bytes, image/svg+xml)
2006-01-26 16:45 PST, Jonathan Watt [:jwatt] (catching up after vacation)
no flags Details
html link target (384 bytes, text/html)
2006-01-26 16:47 PST, Jonathan Watt [:jwatt] (catching up after vacation)
no flags Details
svg with link (to be embedded) (487 bytes, image/svg+xml)
2006-01-26 16:59 PST, Jonathan Watt [:jwatt] (catching up after vacation)
no flags Details
testcase (241 bytes, text/html)
2006-01-26 17:00 PST, Jonathan Watt [:jwatt] (catching up after vacation)
no flags Details
initial test (3.02 KB, patch)
2006-01-26 17:46 PST, Jonathan Watt [:jwatt] (catching up after vacation)
no flags Details | Diff | Splinter Review
patch (3.76 KB, patch)
2006-01-26 18:52 PST, Jonathan Watt [:jwatt] (catching up after vacation)
no flags Details | Diff | Splinter Review
patch with namespace check (3.76 KB, patch)
2006-01-26 19:09 PST, Jonathan Watt [:jwatt] (catching up after vacation)
jonas: review+
Details | Diff | Splinter Review
patch with sicking's changes (4.61 KB, patch)
2006-01-27 15:23 PST, Jonathan Watt [:jwatt] (catching up after vacation)
jst: superreview+
jst: approval‑branch‑1.8.1+
Details | Diff | Splinter Review

Description Jeff Schiller 2005-07-14 21:24:19 PDT
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 2005-07-14 21:26:03 PDT
Created attachment 189384 [details]
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 2005-07-14 21:27:19 PDT
Created attachment 189385 [details]
SVG file demonstrating the problem when embedded in targetbug.html
Comment 3 Jeff Schiller 2005-07-14 21:30:17 PDT
Created attachment 189386 [details]
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 2005-07-19 02:25:44 PDT
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 2005-11-30 09:10:18 PST
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 2005-11-30 11:08:53 PST
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 2005-11-30 11:18:36 PST
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 2006-01-19 08:11:39 PST
*** Bug 323601 has been marked as a duplicate of this bug. ***
Comment 9 Dragos Pruteanu 2006-01-24 02:24:10 PST
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] (catching up after vacation) 2006-01-26 16:45:31 PST
Created attachment 209772 [details]
svg with link (to be embedded)
Comment 11 Jonathan Watt [:jwatt] (catching up after vacation) 2006-01-26 16:47:18 PST
Created attachment 209773 [details]
html link target
Comment 12 Jonathan Watt [:jwatt] (catching up after vacation) 2006-01-26 16:59:12 PST
Created attachment 209777 [details]
svg with link (to be embedded)
Comment 13 Jonathan Watt [:jwatt] (catching up after vacation) 2006-01-26 17:00:18 PST
Created attachment 209778 [details]
testcase
Comment 14 Jonathan Watt [:jwatt] (catching up after vacation) 2006-01-26 17:46:39 PST
Created attachment 209784 [details] [diff] [review]
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] (catching up after vacation) 2006-01-26 18:52:00 PST
Created attachment 209789 [details] [diff] [review]
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] (catching up after vacation) 2006-01-26 19:09:35 PST
Created attachment 209791 [details] [diff] [review]
patch with namespace check
Comment 17 Jonas Sicking (:sicking) PTO Until July 5th 2006-01-27 01:54:18 PST
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] (catching up after vacation) 2006-01-27 04:25:40 PST
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) PTO Until July 5th 2006-01-27 10:17:59 PST
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] (catching up after vacation) 2006-01-27 10:22:15 PST
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) PTO Until July 5th 2006-01-27 11:21:58 PST
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] (catching up after vacation) 2006-01-27 15:23:40 PST
Created attachment 209909 [details] [diff] [review]
patch with sicking's changes

I love it. :-) Here's the patch.
Comment 23 Johnny Stenback (:jst, jst@mozilla.com) 2006-01-27 16:01:39 PST
Comment on attachment 209909 [details] [diff] [review]
patch with sicking's changes

sr=jst
Comment 24 Jonathan Watt [:jwatt] (catching up after vacation) 2006-01-28 05:16:40 PST
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 krmathis@gmail.com 2006-01-28 07:17:14 PST
I'm pretty sure this checkin made the Camino tinderboxes burn!
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Camino
Comment 26 Jonathan Watt [:jwatt] (catching up after vacation) 2006-01-28 09:55:10 PST
Nope, it was just tinderbox weirdness.
Comment 27 Jonathan Watt [:jwatt] (catching up after vacation) 2006-02-01 16:38:17 PST
Checked in on 1.8 branch.
Comment 28 Robert Longson 2006-02-02 08:22:21 PST
*** Bug 315389 has been marked as a duplicate of this bug. ***
Comment 29 Jan Ploski 2006-10-25 02:29:50 PDT
Firefox 2.0 still ignores the target attribute. Should this bug be reopened?
Comment 30 Jan Ploski 2006-10-25 02:32:20 PDT
(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 2006-10-25 03:30:19 PDT
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] (catching up after vacation) 2006-10-25 04:11:37 PDT
No, XLink doesn't have a target attribute.

Note You need to log in before you can comment on or make changes to this bug.