608 bytes, text/html
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.
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?
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.
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 ;)
*** Bug 229055 has been marked as a duplicate of this bug. ***
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.
> 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.
*** Bug 269576 has been marked as a duplicate of this bug. ***
*** Bug 303766 has been marked as a duplicate of this bug. ***
This should be for all events, not just onClick. See bug 303766.
*** Bug 278242 has been marked as a duplicate of this bug. ***
(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.
*** Bug 338459 has been marked as a duplicate of this bug. ***
Created attachment 222527 [details] Sample HTML file using onmousedown and onmouseup to rewrite a URL href
Except that a page can add click event listeners after the status panel is shown.
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.
: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?