target attribute not supported for SVG:a element

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Jeff Schiller, Assigned: jwatt)

Tracking

({fixed1.8.1})

Trunk
fixed1.8.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 6 obsolete attachments)

(Reporter)

Description

12 years ago
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...
(Reporter)

Comment 1

12 years ago
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.
(Reporter)

Comment 2

12 years ago
Created attachment 189385 [details]
SVG file demonstrating the problem when embedded in targetbug.html
(Reporter)

Updated

12 years ago
Attachment #189385 - Attachment is obsolete: true
(Reporter)

Updated

12 years ago
Attachment #189384 - Attachment is obsolete: true
(Reporter)

Comment 3

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
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
(Reporter)

Comment 7

12 years ago
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

Comment 8

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

Comment 9

11 years ago
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.
(Assignee)

Comment 10

11 years ago
Created attachment 209772 [details]
svg with link (to be embedded)
(Assignee)

Comment 11

11 years ago
Created attachment 209773 [details]
html link target
(Assignee)

Updated

11 years ago
Attachment #209773 - Attachment mime type: text/plain → text/html
(Assignee)

Comment 12

11 years ago
Created attachment 209777 [details]
svg with link (to be embedded)
(Assignee)

Comment 13

11 years ago
Created attachment 209778 [details]
testcase
(Assignee)

Updated

11 years ago
Attachment #189386 - Attachment is obsolete: true
(Assignee)

Updated

11 years ago
Attachment #209772 - Attachment is obsolete: true
(Assignee)

Comment 14

11 years ago
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.
(Assignee)

Comment 15

11 years ago
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).
Assignee: general → jwatt
Attachment #209784 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #209789 - Flags: superreview?(jst)
Attachment #209789 - Flags: review?(bugmail)
(Assignee)

Updated

11 years ago
Attachment #209789 - Flags: superreview?(jst)
Attachment #209789 - Flags: review?(bugmail)
(Assignee)

Comment 16

11 years ago
Created attachment 209791 [details] [diff] [review]
patch with namespace check
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?
(Assignee)

Comment 18

11 years ago
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.
(Assignee)

Comment 20

11 years ago
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+
(Assignee)

Updated

11 years ago
Attachment #209791 - Flags: superreview?(jst)
(Assignee)

Comment 22

11 years ago
Created attachment 209909 [details] [diff] [review]
patch with sicking's changes

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+
(Assignee)

Comment 24

11 years ago
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
Last Resolved: 11 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → FIXED

Comment 25

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

Comment 26

11 years ago
Nope, it was just tinderbox weirdness.

Updated

11 years ago
Attachment #209909 - Flags: branch-1.8.1+
(Assignee)

Comment 27

11 years ago
Checked in on 1.8 branch.
Keywords: fixed1.8.1

Comment 28

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

Comment 29

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

Comment 30

11 years ago
(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

11 years ago
Hi,

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

Thanks
(Assignee)

Comment 32

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