229050 - Don't show URL in status bar on mouseover if there is onclick, onMouseDown or other event

Status: RESOLVED WONTFIX

(Core :: General, defect)

Description

[Ben Bucksch (:BenB)]

For tags like
<a href="http://www.goodsite.com"
onclick="javascript:location.href='http://badsite.com'">
we show "http://www.goodsite.com" in the status bar. This is wrong and
misleading, the href will be ignored and the onclick script executed instead, so
don't pretend that we use the URL in the href. Otherwise, a site might trick me
to go to a website where I didn't want to go (slashdot-url-problem).

IMHO, it should show no URL at all and just some text indicating that there is a
script to be executed when the link will be clicked.

Related to bug 122445.

Comment 1

[Michael Lefevre]

and if Ben's suggestion is too radical a change from previous versions (and IE
etc), we could still show the URL, but give some indication that the link has a
website-defined onclick event.

Comment 2

[dolphinling]

I'd rather it showed both--and also just the onclick if there was no href. Do
you agree with this, reporter? If so, can you search for that bug and dupe this
to it?

Comment 3

[Ben Bucksch (:BenB)]

I personally would like the href not to be shown at all. In the case I worry
about (badsite/goodsite, spoofing), users not knowing the technical details will
be still be misleaded or confused even more, if we show the href URL together
with an "JS link" text or so.

I am not aware of a dup.

Comment 4

[dolphinling]

You're right, I don't see the bug I want anywhere... I filed that as bug 229055.

Also, if we confuse people by showing both texts, at least they'll know that
something unexpected is going to happen ;)

Comment 5

[Ben Bucksch (:BenB)]

*** Bug 229055 has been marked as a duplicate of this bug. ***

Comment 6

[Alfonso Martinez]

This won't be so easy. If the check is added to Mozilla and someone tries to
trick users then he can use other ways: instead of adding an onclick in the <a>
he can add the event to a parent element and change the click behaviour from
there, with an onclick event or using addEventListener, he could also put the
event on mouseDown, etc...
Or he can create spans that look like links with a mouseover that puts the nice
url in the status bar, but the onclick behaves like in the bug report.

I don't think that it would be good to give a false sense of security.

Comment 7

[Ben Bucksch (:BenB)]

> This won't be so easy.

True :(

> he can add the event to a parent element
> mouseDown

Right, I knew about that, thanks to Jesse Ruderman, but forgot it.
I guess it has to trigger on all these cases, then :(.

This is looking less like it's worth the effort :(.

> I don't think that it would be good to give a false sense of security.

Agreed. But this is what this bug is about: Currently, we *do* give that, but
telling users they'll go to site a, although they'll go to site b.

Comment 8

[gavin long]

*** Bug 269576 has been marked as a duplicate of this bug. ***

Comment 9

[Jesse Ruderman]

*** Bug 303766 has been marked as a duplicate of this bug. ***

Comment 10

[Dan Mellem]

This should be for all events, not just onClick. See bug 303766.

Comment 11

[Jesse Ruderman]

*** Bug 278242 has been marked as a duplicate of this bug. ***

Comment 12

[OstGote!]

(In reply to comment #10)
> This should be for all events, not just onClick. See bug 303766.

Yes, see for example Google search results with the onmousedown script.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

*** Bug 338459 has been marked as a duplicate of this bug. ***

Comment 14

[Jim]

Attachment: Sample HTML file using onmousedown and onmouseup to rewrite a URL href

Comment 15

[Jim]

(In reply to comment #7)
> ...But this is what this bug is about: Currently, we *do* give that, but
> telling users they'll go to site a, although they'll go to site b.

For example, for the link

<a href="http://yahoo.com" onclick="javascript:doStuff()">

the status bar could read:

"http://yahoo.com  (Clicking this link will also execute potentially insecure Javascript code)"

Comment 16

[Ken Takusagawa]

I would like to see the behavior such that if I hover over a link, and an address is shown in the status bar, then it is guaranteed that that is the address I will go to when I click it, that is, we ignore any onmousedown or onclick or other events if a click happens on a region that caused an address to be written in the status bar.  I guess I also want that the only way an address can appear in the status bar is from an HREF attribute on an HTML Anchor (A) element: I think this latter functionality already exists (dom.disable_window_status_change).

If the guarantee can't be met, for example, firefox needs to execute some Turing-complete javascript to figure out where the link is going or doing onmousedown or onclick, then the status bar is blank, or perhaps displays the address javascript:(etc).

To reiterate: it's not the case that I want to disable javascript on a click entirely, I simply want to disable the sneaky "it looks like a normal link but it actually isn't" behavior.

In related news, I discovered Google News does its sneaky redirect by modifying the href when onmousedown happens.  It has defeated my simple greasemonkey userscript (which does work on Google search results) that had simply stripped A elements of onmouse* attributes.

Please let me know if this is not the correct bug to request this feature.

Comment 21

[scientes]

IMHO it would better if we showed the url, but if the href attribute exists and starts with anything but #, then we disallow JavaScript handlers to attach to it.

Comment 22

[Dan Mellem]

In a way this bug is now a lot more difficult to address. In addition to the "onclick" within the link, it is now very common to attach event listeners via Javascript. You can now have a simple <a> tag in the HTML but have it modified by some third-party Javascript function. A patch would need to be aware of all patched events before knowing what to display in the status bar and/or to fix the link.

Comment 23

[scientes]

Indeed, understanding it is not as simple as just disallowing certain attributes on the <a> element I wrote as clear as I could: "disallow JavaScript handlers to attach to [specific a elements]". However, the great progress we made towards eventually solving Bug 147777 (:visited privacy leak) shows that with a concerted effort these types of problems are solvable.

Comment 24

[Ben Bucksch (:BenB)]

It's not actually hard. The browser doesn't look at the HTML source, but the DOM, and would need be able to get a list of event handlers attached to a node. Or higher nodes (which might be expensive), because events bubble up. So, before we would show the URL in the status bar, we first check for handlers, and if found, we display a text like "JavaScript link" or similar instead of the URL.

Comment 25

[Dão Gottwald [:dao]]

Except that a page can add click event listeners after the status panel is shown.

Comment 27

[:Gijs (he/him)]

In the presence of JS, this problem is impossible to solve. There could be a mouseup handler on the body that set window.location.href somewhere else without bothering with manipulating the link, in which case the status bar's suggested target would still be wrong. Detecting all possibilities here and all the ways in which JS could be changing things degenerates to the halting problem ("what are the effects of running this code going to be").

We don't have "cant fix" as a status, so picking "wontfix" instead.

Comment 29

[Paul]

:Gijs Can't we save the status bar contents, block navigation, run all relevant handlers in the DOM, re-enable navigation, and then execute the saved address/JS? Or are some sites written in such a way that this would break them?

Comment 30

[:Gijs (he/him)]

(In reply to Paul from comment #29)
> :Gijs Can't we save the status bar contents, block navigation, run all
> relevant handlers in the DOM, re-enable navigation, and then execute the
> saved address/JS?

Pretty sure that would be counter to the spec...

> Or are some sites written in such a way that this would
> break them?

... and indeed break sites. Google used to use similar techniques to this for search click tracking, for instance (I think on Firefox they might now use "<a ping>", but I haven't checked in a while). Other places will add actual useful path/query parameters on mousedown, without which your link goes to the wrong place. Plenty of other sites still use javascript:void or '#' as an href and use the click handler to actually navigate, etc. Disabling navigation from those entirely would be a minefield (and even that wouldn't always be helpful - what happens for <a href="#someanchor" onclick="setTimeout('location.href=`foo`', 0)">Click me</a> - and why would it be different from <a href="#someanchor" onclick="location.href = 'foo'">Click me</a> ?)