Closed Bug 1218249 Opened 4 years ago Closed 4 years ago
⌘+Clicking inline SVG <image> inside <a> leads to wrong URL
385 bytes, text/html
177.33 KB, video/mp4
40 bytes, text/x-review-board-request
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
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.
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)
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
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/
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.