User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170206030211 Steps to reproduce: I am able to reproduce this bug in : FF Nightly on Windows OS FF Beta on Windows OS FF Linux 4.4.0-57 Generic Steps to reproduce : 1. Open click.html 2. Then try to visit google.com OR http://hackies.in/click.html Visually the browser says you(user) will be visiting google.com but it actually goes to datarift.blogspot.in An attacker may craft the link and may perform phishing attack and etc. Actual results: Just do a mouseover on the link and see left bottom the URL says the browser will be visiting google.com but actually goes to datarift.blogspot.in In case if the repro doesn't works please perform the testcase 1 more time. Expected results: It should redirect to the actual URL. Attaching the test case and the click.html file for reference

This is kind of a dupe of bug 279192, kind of a dupe of bug 1237233 and kind of a dupe of bug 229050. I'm not convinced it makes sense to keep this open separately. TL;DR: the testcase uses an onclick handler to move an element 'over' the link itself which then onmouseover sets location.href . This is a convoluted way of just calling location.href from inside the click handler which races (bug 279192), maybe should never activate the link if it happens before the click finishes (e.g. if you use onmousedown instead of onclick on the link to move the other element) (bug 1237233) and maybe is just the kind of thing we can never really fix as long as we allow manipulating location.href to arbitrary values without user interaction (and, I guess, even if we do restrict to user interaction, this bug might persist) - see bug 229050 comment 27. I don't feel strongly about which bug to pick as a dupe, but I would suggest opening up and duping to one of the aforementioned bugs.

I can't repro on a Mac nightly, guess I'm losing the race? (devtools shows it starts loading datarift then loads google.) Anyway, this is exactly what bug 229050 wanted to fix: if we allow user script to run of any kind you can't trust what the link hover text says. The "Link" might not even be a link! Maybe it's button styled to look like a link and the URL 'hovertext' is faked by the page. Bottom line -- users can't trust anything below the "line of death", and anything we put in there is for convenience on well-behaved pages but can't be relied on. https://textslashplain.com/2017/01/14/the-line-of-death/ Even if the page is not malicious you can't trust the hover text because the destination server might redirect you, or an intervening proxy sends you somewhere else.