243431 - "return false;" in onClick for link handler doesn't cancel default action

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Sebastian Lisken]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421

Many websites feature image thumbnails that, clicked on, open separate windows
with full pictures. This is of course implemented with links (<a> elements) that
feature an "onClick" attribute which opens the window. The "href" attribute is
often set just to "#", which seems to be a modern web author's idea of
"nothing". Of course this isn't true, and it is annoying when the URL referred
to by such a link is actually loaded, adding an entry in the browser's history
and scrolling back to the top of the page. One could argue that authors should
link to a page containing the image and not to "#", but the first point of
course that the "onClick" handler should return false to prevent the hash-ed URL
from being loaded.

You all knew that, sure. But here's what blows me.

I have noticed several times when surfing with Mozilla that "# URLs" were
actually loaded, and blamed poor scripting. After being surprised to find an
"offender" at wired.com, I looked at the article's source (URL above), and to my
huge surprise, there was the "return false" statement in the onClick handler! Of
course I figured that the JavaScript before "return false" must have produced an
error, returning some non-false value before reaching the "return" statement.
But when I cleared some old errors and retried, the JavaScript console shows
nothing new, but the bug persists. Further investigation turns out it is in fact
hardish to reproduce. The bug mostly seems to show if the link is on a new tab,
i.e. opened with a click of the middle mouse button with settings stating that
such a link should open in a new tab. (This is my way of reading news sites, try
"http://www.wired.com/news/mac/0,2125,63423,00.html?tw=wn_tophead_3" for the
article I looked at).

I don't seem to be able to find this as a confirmed bug. Bugs #204195 and
#237969 exhibit the problem well, but the former says it's not showing under
Win2K (it is), and the latter says it mostly occurs when href is empty, rather
than "#". But the test case attached to the bug shows the error more often than
just for an empty href, and it's quite reliable. See Steps to Reproduce.

Please fix this. I think it's a major annoyance.


Reproducible: Always
Steps to Reproduce:
1. Open the above link
("http://bugzilla.mozilla.org/attachment.cgi?id=147625&action=view", a test case
for a previous bug). This one does not need to be in a new tab, but it can be.

2. Click on any example link, if nothing happens, click it several times quickly.

Actual Results:  
The browser loads something ("http://bugzilla.mozilla.org/failed.html" for the
first two, the current page for the third, the current URL plus "#" for the fourth).

Expected Results:  
No link should be loaded.

Tested with Mozilla 1.7 RC1 on Win2K Pro, and Firefox 0.6.

Comment 1

[Gérard Talbot]

I tried your steps to reproduce on the provided URL with Mozilla 1.8a2 build
2004060709 and Firefox 0.8+, rv: 1.8a2 build 20040604 and got the expected
results with both browsers. WORKSFORME. If javascript support was disabled, then
you would get all of your actual results since onclick event handler would be
ignored, would not be carried out.

Note that Middle-click, Ctrl+click and Ctrl+Enter on links will not always or
not completely cancel default actions. See attachment 149849 [details] included in bug 151142.
XP Pro SP1a here.

Comment 2

[Jesiah S]

WFM LInux 2004062105
When I went to the wired article I heard a beep when I clicked on the image. 
When I allowed popups from wired.com it worked.  When I removed the wired's
entry it contiued to work.

Comment 3

[Tuukka Tolvanen (sp3000)]

attachment 147625 [details] 1, 2, 3, 4 worksforme linux seamonkey current trunk, 1.7
release, firefox current trunk & aviary. No # url loaded in case 4 there.

Comment 4

[Gérard Talbot]

Resolving as WORKSFORME

Comment 5

[Chris Vance]

WFM

Expected result is met (nothing happens, no page is loaded) when following
testcase http://bugzilla.mozilla.org/attachment.cgi?id=147625&action=view

This is for: Mozilla 1.8a2 (build 20040629)
and Firefox 0.9.1 release (build 20040626)