Closed Bug 1218249 Opened 4 years ago Closed 4 years ago

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

Categories

(Firefox :: Tabbed Browser, defect)

43 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 45
Tracking Status
firefox45 --- fixed

People

(Reporter: tigt, Assigned: Gijs)

Details

Attachments

(3 files)

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.
I tried grabbing a screencast to reproduce the issue, and now ⌘+Click doesn't activate the link at all.
Nevermind, got it working again under a non-e10s window.
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).
Status: UNCONFIRMED → NEW
Component: Untriaged → SVG
Ever confirmed: true
Product: Firefox → Core
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.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1227116
... and then I reread the description and realized maybe this is not the same issue (per comment 4). Sorry. :-\
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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?
Component: SVG → Tabbed Browser
Flags: needinfo?(longsonr)
Product: Core → Firefox
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.
Flags: needinfo?(longsonr)
Assignee: nobody → gijskruitbosch+bugs
Status: REOPENED → ASSIGNED
Bug 1218249 - check type of node before using xlink:href, r?felipe,longsonr
Attachment #8694713 - Flags: review?(felipc)
Attachment #8694713 - Flags: feedback?(longsonr)
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
Attachment #8694713 - Flags: review?(felipc) → review+
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
Attachment #8694713 - Flags: feedback?(longsonr)
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/
Attachment #8694713 - Flags: feedback+
https://hg.mozilla.org/mozilla-central/rev/28a8a1833628
https://hg.mozilla.org/mozilla-central/rev/bd4e3d717b32
Status: ASSIGNED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45
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
QA Whiteboard: [bugday-20160323]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.