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

RESOLVED WONTFIX

Status

()

Core
General
RESOLVED WONTFIX
14 years ago
5 months ago

People

(Reporter: BenB, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

14 years ago
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

14 years ago
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?
(Reporter)

Comment 3

14 years ago
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

14 years ago
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 ;)
(Reporter)

Comment 5

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

Comment 6

14 years ago
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.
(Reporter)

Comment 7

14 years ago
> 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

13 years ago
*** Bug 269576 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite

Comment 9

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

Comment 10

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

Comment 11

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

Updated

12 years ago
Summary: Don't show URL on mouseover, if there is onclick → Don't show URL in status bar on mouseover, if there is onclick

Updated

12 years ago
Blocks: 325274

Comment 12

12 years ago
(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.

Summary: Don't show URL in status bar on mouseover, if there is onclick → Don't show URL in status bar on mouseover if there is onclick, onMouseDown or other event
*** Bug 338459 has been marked as a duplicate of this bug. ***

Comment 14

11 years ago
Created attachment 222527 [details]
Sample HTML file using onmousedown and onmouseup to rewrite a URL href

Comment 15

11 years ago
(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

11 years ago
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.
Assignee: jag → nobody
Component: XP Apps → General
Product: Mozilla Application Suite → Core
QA Contact: pawyskoczka → general
Duplicate of this bug: 405324

Updated

6 years ago
Duplicate of this bug: 509682

Updated

6 years ago
Blocks: 705153
Duplicate of this bug: 725385
Duplicate of this bug: 748519

Comment 21

5 years ago
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

5 years ago
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

5 years ago
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.
(Reporter)

Comment 24

5 years ago
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.
Except that a page can add click event listeners after the status panel is shown.
Duplicate of this bug: 584910

Updated

2 years ago
See Also: → bug 1155834

Comment 27

8 months ago
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.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
Duplicate of this bug: 1337357

Comment 29

5 months ago
: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

5 months ago
(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> ?)
You need to log in before you can comment on or make changes to this bug.