User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160425114621 Steps to reproduce: Visit a page that uses Revcontent's click tracking, e.g.: http://www.medicaldaily.com/creative-thinking-psychopath-test-arts-384117 Find the "Powered by Revcontent" section (in the above link it should be on the right, titled Latest News; this may be blocked by ad blockers). Hover over a link and note that the target displayed appears legitimate (a link to the same site). Right-click on it and Copy Link Location. Actual results: The copied link location is spoofed to trends.revcontent.com. That is the actual link in the HTML at load time; code that runs on a :hover event spoofs it to the link displayed by the brower, but this is undone when the link loses focus or is clicked. Expected results: The link copied should be that which is displayed by the browser.

Maybe duplication of Bug 229050

Good point, I did look at that bug, but thought that Copy Link Location should be trustworthy.

Can you help us find a suitable duplicate for this bug? I'm thinking either Bug 257307 or Bug 229050 from comment 1. What do you think?

I looked at both of those before filing, but neither captures the Copy Link Location problem. As a power user I've been aware of the onclick issue in those bugs for many years, and when it's come up I've used Copy Link Location to circumvent it. I filed this bug because Copy Link Location is also getting fooled, and it shouldn't be, there should be *some* way of getting the URL without going through source code or writing it down by hand.

If I'm understanding your last comment correctly, you're saying that Copy Link Location used to work in the past and now it does not. If so, could you please try and find a regression range using the Mozregression tool? Information on the tool is available at http://mozilla.github.io/mozregression/.

I'm just reporting how it behaves now. This behaviour violates the Law of Least Astonishment. It could always have been like this (though I haven't noticed it in the past), but it is still a bug. Does that make sense?

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0 The issue is reproducible on the latest Firefox release (46.0.1, Build ID 20160502172042) and on the latest Nightly (49.0a1, Build ID 20160512030253). The issue is not a regression as I could trace it back Firefox 3.6.

This ad script is not using the :hover CSS style. It has the typical pair of mouseover and mouseout events which swap the href in and out (using values stored in custom data- attributes on the link). The bit that's frustrating your Context Menu items (copy link) is that there is also a mousedown event handler putting the tracking link back in the href. This behavior sucks, but it's in the realm of what bug 257307 covers.

Thanks for investigating and explaining. I agree that bug covers it; didn't see it before. An add-on like this one could help in this instance (if it worked), but perhaps there can be no general solution: https://addons.mozilla.org/en-US/firefox/addon/copy-url-on-mouse-over/