18 years ago
11 years ago


(Reporter: rxbypg001, Unassigned)


(Depends on 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


I'm suggesting a UI enhancement. One problem I've run into while browsing with
Mozilla is that there many times when I believe I've clicked a link and will
wait for up to fifteen seconds before I realize that the hyperlink was never
clicked properly. This is especially problematic when I click a link that I
think will take a while to load so I'll switch to another window.

Some other browsers have some sort of either visual or auditory feedback when a
link has been successfully clicked to tell the user that the browser is in the
process of loading a new page. IE has a "tick" sound when a link has been
clicked. Konqueror used to have a simple animation of a wireframe which starts
as a point and zooms up to surround the text of the hyperlink in a split second.
In Mozilla, it requires looking up at the throbber to tell whether the browser
has received the input, a graphic whose change is not immediately obvious.

Depending on how a particular page is coded or the user's preferences, the text
color change in the hyperlink may not be reliable. Either a sound or visual
feedback (or a choice between the two ideally) would be a nice feature.
Dear God please not an annoying sound like IE. (click...Boop)

I really think the throbber/status bar/progress meter are enough, but if we
really want to add something I guess we could throw up the hourglass when you
click on the link like NS4x did. As it stands now, the page/cursor still
operates normally while the next page loads. If we had the hourglass/clock/wait
cursor, the user would have a better idea that something was happening. 

Confirming as bug and setting severity to enhancement
Severity: minor → enhancement
Ever confirmed: true
sorry, i don't agree.

as said, it's already quite enough to have the throbber / status bar / _and_ the
progress meter telling you that the link has been acknowledged. I mean, how hard
can it be to move your eyes from the link to the throbber / status bar / or the
progress meter ?!
... it's not like you're playing Unreal Tournament ;)
Let me argue the case more clearly then. I would posit that using the throbber
and status bar are sufficient, but not ideal. I like more feedback for the same
reason I like using menus in the Mac OS better than those in any other OS I've
tried. That reason is that there is instant feedback on the menu item selected
(a brief flashing/highlighting of the menu item) at the time it has been
selected and placed exactly where the user's eyes and concentration are focused
at that time. 

Maybe some usability testing would be good here. In my experience, I've sat and
helped people through the computer problems and I cannot begin to count the
number of times I've watched them think they've clicked something and just sat
there and waited... and waited.... and waited, until I point out that they
actually haven't done anything at all. Browsers are the most common places I've
see this happen, but it happens on any part of the UI that the user doesn't have
expectation of something changing where they're looking at that moment. Maybe we
should design smarter users, but that's a pretty tall order.

In addition, the throbber and progress bar only tell you that the browser is
busy, not whether or not what you want to select has been selected. The throbber
and progress bar seem to stay in contant "busy" mode for any number of pages
that either load very slowly due to poor coding, large graphics, strange
scripting, or mistransmission. Especially in those cases, relying on those to
give user feedback is inadequate.

Misclicks are a major source of user slowdowns and confusion. Personally, I find
myself doing the same thing on more than a few occasions, and I've got better
hand/eye coordination than practically anybody I know or have ever met,
especially on those sites with really small and tightly spaced links. Please
reconsider implementing some kind of feedback like that, at least as an option.
Ideally, I'd prefer the quick animation that Konqueror used to have, but which
seems to have disappeared in recent versions. It was quick, subtle, and
non-intrusive yet improved usability vastly.

Thank you for hearing me out.
If you are REALLY going to implement clicking sounds as in IE, PLEASE make it

I hate them.
One option.  edit chrome/userContent.css in your profile.

Add something like:

a:active { color: black !important; background-color: white !important;
text-decoration: blink !important }

This will make active (have been clicked on) links black on white and blinking
(At least once blink is fixed).  You can tailor the style to taste, of course. 
If you can come up with a good style, please let me know and I will add it as
one of the default examples in userContent.css.
OS: Windows 2000 → All
I think we can all agree that sounds are a Bad Thing. However, I understand what
the reporter is saying. Open up NS4x or another browser and click on a link.
Every browser does things a little different, but you can see how people could
get confused about what was happening. For us, the page remains the same and the
chrome pieces all start moving. Other browsers show part of the content
changing, and even a blank screen almost instantaneously. The idea of violating
someone's CSS/HTML markup with our own little link animations seems wrong, but
if we were to do something to the cursor (As it is now, if you are over inert
objects - the page - the cursor is arrow+hourglass, anything else - links
textboxes - the cursors are normal) or if we added our own animation (the border
we throw up around links when clicked could blink or crawl) we'd probably get
better marks in the UI response department.
> The idea of violating someone's CSS/HTML markup with our own little link
> animations seems wrong

The reader's CSS is more important than the author's. The W3C says so. :-)

Anyway, I filed the relevant dependencies. Changing the cursor is bug 78361. 
Doing the click sound, *if* the relevant system pref is set, is bug 98674 for 
Windows and bug 98676 for Mac OS. Having optional zoom rects -- from the 
rectangle enclosing a link to the rectangle of the content area where the link 
opens, and from the content area back to the link when you click the Back 
button, is something I'm still thinking about. (For more about zoom rects, see 
Depends on: 78361, 98674, 98676
Summary: more feedback on clicked links → More feedback on clicked links
humm, over the last few weeks I have changed my mind...

having a sound confirmation when you click a link is a very good idea.
especially since it will greatly aid in accessibility support.

so, looking in terms of accessibility, this should be given greater thought.

i've just realised... this bug is quite simular to having smooth scrolling. :)
... there's no point to it, except /helping/ the user. and perhaps making the
browser look good.
uid is being phased out.
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → paw
Dupe of bug 83056?
Product: Core → Mozilla Application Suite
Assignee: bross2 → guifeatures
QA Contact: pawyskoczka
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.