165024 - use status bar, not tooltips, to show URLs for personal toolbar and site navigation bar

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect)

Description

[Jamie Zawinski]

When you mouse over a button in the personal toolbar, you get a tooltip
containing both the title of the bookmark and the URL.  The tooltip should
contain only the title of the bookmark; the URL should be presented in the
status area, just as if you were mousing over HTML that said 
<A HREF=... TITLE=...>

When you mouse over a button in the site navigation bar, you get a tooltip that
shows *either* the title, *or* the URL.  Again, the title (if there is one)
should be in the tooltip, and the URL should be in the status area.

  <LINK REL="prev" HREF="07.html" TITLE="July">

should behave the same as

  <A HREF="07.html" TITLE="July">prev</A>

(sorry if this is a dup, but bugzilla has lost its mind today and all searches
are failing, so I couldn't check)

(I guess this is really two identical bugs that differ in component, but since I
don't know which component *either* of them belongs to, I'll just report it once
and let you folks sort it out...)

Comment 1

[Jesse Ruderman]

See also:
bug 64892 show url in status bar for bookmarks in sidebar
bug 23460 show url in status bar for bookmarks in menu
bug 88541 show url in status bar for back and forward buttons

Comment 2

[Peter Lairo]

Showing the url in the statusbar *in addition to* the tooltip is a good idea.
However, since most regular users will only look at the (much more noticeable)
tooltip, I think it would be a mistake to remove the url from the tooltip. Also,
there's no really good reason to do so; it would *decrease* the amount of useful
and _easily_ locatable information presented to the user.

Suggest either WONTFIX or rephrase bug to read:
"Also use status area to show URLs for personal toolbar and site navigation bar"

Comment 3

[Jamie Zawinski]

So are you proposing that, when you mouse over
<A HREF=... TITLE=...>, that the tooltip should
display the URL and the title?  Because that's not
how it works now, nor how it has ever worked in the
past.

What you're doing now is completely inconsistent.

In your world, what do you think the status area is *for*?

In the past, it has always been for displaying URLs.

Comment 4

[Peter Lairo]

RE Comment #3:
I am only requesting that both the Tiltle and URL be displayed when mousing over
bookmarks in the *Personal Toolbar*. That *is* how it works now! I find this
highly convenient, especially since the Personal TB is so far away from the
statusbar.

Also, you seem to have not carefully read my prior post ("*in addition to*"!),
or you wouldn't have asked what you did in the last two lines of your post.

Comment 5

[Jamie Zawinski]

> I am only requesting that both the Tiltle and URL be
> displayed when mousing over bookmarks in the
> *Personal Toolbar*. That *is* how it works now!

I know that.  How it works now is inconsistent with the
rest of the browser's behavior, and conceptually wrong.
There is no logical difference between the personal 
toolbar, the document nav bar, and an HREF in a page
that just happens to be near the top of the screen.
They all work the same way, and so they should have
identical behavior with respect to clicks and tooltips.

Comment 6

[Jay Davis]

Maybe I'm missing something here, but shouldn't this bug also include showing
the url of all bookmarks within folders of the Personal Toolbar folder on the
status bar too?  If the user is hovering over a bookmark anywhere on the
Personal Toolbar or it's subfolders, it should show up on the status bar.  If
tooltips are also used, that's fine, but the former should be a priority.

Comment 7

[Cees T.]

See bug 105485.

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420