1218249 - ⌘+Clicking inline SVG <image> inside <a> leads to wrong URL

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Taylor Hunt]

Attachment: firefox-link-href-bug.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151023004026

Steps to reproduce:

⌘+Click on the image from placehold.it


Actual results:

The newly opened tab is located at the image's source URL, not the anchor's destination


Expected results:

The tab should always open at the link's specified URL, not the image's source URL.

Clicking on the black square works as it should.

This happens in both e10s and non-e10s windows.

Comment 1

[Robert Longson [:longsonr]]

I always end up at mozilla as expected on my Mac nightly and on Firefox 41.

Comment 2

[Taylor Hunt]

I tried grabbing a screencast to reproduce the issue, and now ⌘+Click doesn't activate the link at all.

Comment 3

[Taylor Hunt]

Attachment: Screencast of the bug in action

Nevermind, got it working again under a non-e10s window.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Yeah, Ctrl+Click does nothing with e10s enabled but shows the behavior from the screencast with e10s disabled. Doesn't look like this ever worked (I reproduced it as far back as ESR10).

Comment 5

[:Gijs (he/him)]

Thanks for the report! I fixed part of this in bug 1217586, but unfortunately I messed up and so it's not completely fixed (on Nightly) yet - I'm doing the rest of the work in bug 1227116, so I'm duping this there.

Comment 6

[:Gijs (he/him)]

... and then I reread the description and realized maybe this is not the same issue (per comment 4). Sorry. :-\

Comment 7

[:Gijs (he/him)]

From bug 1227116: I expect the fix would involve changing the loop I'm modifying [there] to be more picky about which elements' xlink:href attributes it interprets as a link to somewhere.

Specifically, the code here:

https://dxr.mozilla.org/mozilla-central/rev/d3d286102ba7f8801e9dfe12d534f49554ba50c0/browser/base/content/content.js#515-526

should check the node name for the node it uses.

Robert, I looked briefly at the MDN docs for xlink:href, but it's not super clear from there which elements should be followable as links in this way. Is it just <a> elements? Or are there others?

Comment 8

[Robert Longson [:longsonr]]

In SVG <a> with xlink:href in SVG is the equivalent of <a> with src in html. <a> is the only followable link element.

Other SVG elements may have xlink:href e.g. an image where xlink:href is again equivalent to src on an html img element but xlink:href attributes on other elements should not act like links.

Comment 9

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1218249 - check type of node before using xlink:href, r?felipe,longsonr

Bug 1218249 - check type of node before using xlink:href, r?felipe,longsonr

Comment 10

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8694713 [details]
MozReview Request: Bug 1218249 - check type of node before using xlink:href, r?felipe,longsonr

https://reviewboard.mozilla.org/r/26837/#review24383

Comment 11

[Robert Longson [:longsonr]]

Comment on attachment 8694713 [details]
MozReview Request: Bug 1218249 - check type of node before using xlink:href, r?felipe,longsonr

This is fine for html and SVG. 

I think mathml allows links on any element though. E.g. <mrow xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="#align-eq1">1.6</mrow> There are some testcases in bug 427990

Comment 12

[:Gijs (he/him)]

Comment on attachment 8694713 [details]
MozReview Request: Bug 1218249 - check type of node before using xlink:href, r?felipe,longsonr

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/26837/diff/1-2/

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/28a8a1833628

Comment 14

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/bd4e3d717b32

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/28a8a1833628
https://hg.mozilla.org/mozilla-central/rev/bd4e3d717b32

Comment 16

[Mohammad Maruf Islam]

I have reproduced this bug with Firefox Nightly 44.0a1 (Build ID: 20151025030428) on 
windows 8.1, 64-bit with the instructions from comment 0.

Verified as fixed with Firefox Release 45.0.1 (Build ID:20160315153207)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0