User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 In the preferences for javascript I could allow that scripts may modify the status bar. I haven't done this, and that's also the default. The site http://firefox-erweiterungen.de uses an almost prehistoric trick to hide the target URLs of its links, example (truncated): <a href="http://firefox-erweiterungen.de/search/redirect.php?f=http%3A%2F%2Fpagead2.googlesyndication.example" class="adhead" target="_blank" onmouseout="window.status=''" onmouseover="window.status=''; return true;">Firefox 3.0 Download</a> The window.status='' onmouseover event should not work, it's not allowed in my actual (= the default) javascript settings. Also tested with the "Safe Mode" variant. Reproducible: Always Steps to Reproduce: 1. Make sure that Javascript is activated, maybe deactivate "noscript" if you have it (I don't have it yet). 2. Check that the "extended settings" for javascript do NOT allow scripts to manipulate the status bar (the last two settings in this form) 3. Go to firefox-erweiterungen.de and mouse over their "sponsored links". Actual Results: The target URL isn't shown, window.status='' is honoured. Expected Results: The target URL should be shown, any access on window.status by scripts, let alone scripts on a foreign web page, should be disabled as long as this isn't explicitly permitted in the "extended javascript settings". This might be a child of https://bugzilla.mozilla.org/show_bug.cgi?id=325274 but I strongly disagree with the classification as "minor" bug.

confirmed: with javascript enabled the link URL is suppressed in the status bar.

It's not _setting_ the status bar -- if it were you'd get a blank one rather than the word "Done" staying there. You can test this by trying to set the status to something else. Instead, it's the "return true" that tells Mozilla that the onmouseover handler has handled the event, so it never bubbles up to the routine that would set the default status. This sounds vaguely familiar to me, there may be another bug on this.

Can you reproduce the bug with a trunk build? This seems like a dup of bug 40838 which is fixed.

Can't reproduce in a trunk build, does seem to be the same as bug 40838.

Thanks for info, I hope the tested fix shows up in Firefox 2.0.0.6 @Florian: I'm completely new to Firefox and anything else based on Gecko, it's better if I stay away from trunk versions for this year ;-)