64892 - Show URL in Statusbar when hovering over/clicking on sidebar Bookmarks

Status: RESOLVED WORKSFORME

(SeaMonkey :: Bookmarks & History, enhancement, P5)

Description

[Peter Lairo]

Show URL in Statusbar when hovering over Bookmarks in MySidebar (or anywhere
else) needed.

Comment 1

[Henrik Gemal]

*** This bug has been marked as a duplicate of 23460 ***

Comment 2

[Peter Lairo]

No, this is not a duplicate since the other bug ONLY talks about the URL showing
when using bookmarks from the MENU!!! This bug is about showing the URL using
bookmarks from the MYSIDEBAR!!!

I have too often been flamed about putting too many requests into one bug. Now
you're doing the same thing. Please make up your mind how you want bugs split or
combined. Please let me know if there are such criteria.

If you do decide that this is a duplicate, let me know how to add/introduce this
bug into the other bug!!!

Comment 3

[Fabian Guisset]

I think PLairo will not agree, but given the resolution of your other "bookmarks 
in sidebar" bug, this will obviously stay a dup. Gemal, for your info, PLairo 
was reporting against the sidebar, not the bookmarks menus, but then again it is 
probably the same code.

Comment 4

[Blake Ross]

No, not the same code at all.  Reopening.

But this shouldn't be when you hover over bookmark items, since they open on 
double click.  It should be when you click on an item.

Comment 5

[Claudius Gayle]

Confirming. Tweaking summary so i don't have the read the whole disussion each time to
figure what this bug is supposed to be for.

Comment 6

[David Hallowell]

Links in the sidebar should not appear in the statusbar because the statusbar
only covers the browser area. If hovering over links in the sidebar are going to
be shown in the statusbar then the statusbar should be extended to cover the
whole window (and get rid of the taskbar at the same time). Because that's
unlikely to happen I suggest WONTFIX

Comment 7

[Peter Lairo]

I strongly disagree for the following reasons:

1. People are used to looking at the statusbat for info on moushovers,
REGARDLESS if the info is in more towards the center or a few cm further left.

2. Extending the statusbar to the left (including below the sidebar) would
further shorten that valuable piece of realestate (ppl with several Tabs already
have limited viewing space for what the tabs are supposed to be displaying).

3. Never EVER get rid of the Taskbar!!! (assuming that is where one can load
Messenger, Browser and Addressbook)

Comment 8

[Simon Lucy]

There is an argument for the Sidebar having its own Status bar though there are
complications in that each Tab would then have to maintain the status which it
then refreshed the sidebar status with when it became active.  Sidebar panels
that didn't do that would leave the last Status hanging which would be very
messy and as panels can be added by third parties enforcing that kind of process
would be awkward.  #

The sidebar code could inspect the panel's properties and if there was no status
property blank the statusbar. (thinking as typing :-))

As for whether bookmarks should update any such status I'm less than convinced
if only because bookmarks aren't links in the same way that Search results or
Related links are.  Bookmarks have to be actually selected, mousing over them
isn't meant to do anything with them.

You could display the URL if you clicked on the Bookmark I suppose but it
shouldn't be in the browser's general status bar because, as has been said, that
relates to the content of the browser and making that ambiguous would distract
the user.

Comment 9

[Peter Lairo]

The sidebar is MUCH to narrow to display even short URL's.

Since the URL would change as one moved from bookmark to bookmark (assuming the
"hovering" option is used), any user would quickly realize that the URL being
displayed in the statusbar is that of the bookmark.

The only alternative is to have the tooltip always be 2 lines: one for the
Bookmark Name and one for the URL Location - I actually prefer this option,
since all the needed info would be in the same place and near where the user is
visually focussing.

BTW: Simon, are you monitoring all my posts just to contradict me at every turn?
Just kidding ;-)

Comment 10

[James Green]

OS->All. We want for Linux too! :-)

Comment 11

[Paul Chen]

nav triage team:

Would be nice to have, but we won't get to it, marking future

Comment 12

[Viswanath Ramachandran]

nav triage team: nsbeta1-. 

Comment 13

[Tim Powell]

*** Bug 78763 has been marked as a duplicate of this bug. ***

Comment 14

[R.K.Aa.]

*** Bug 82958 has been marked as a duplicate of this bug. ***

Comment 15

[Jeremy M. Dolan]

Dupe of bug 64307?

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Comment 17

[Paul Chen]

marking p5

Comment 18

[Peter Lairo]

*** Bug 115050 has been marked as a duplicate of this bug. ***

Comment 19

[Peter Trudelle]

mass reassign of pchen bookmark bugs to ben

Comment 20

[Jesse Ruderman]

*** Bug 140680 has been marked as a duplicate of this bug. ***

Comment 21

[Alfonso Martinez]

*** Bug 147161 has been marked as a duplicate of this bug. ***

Comment 22

[Jesse Ruderman]

See also bug 165024, show url in statusbar (instead of in a tooltip) when
hovering over personal toolbar bookmarks and site navigation bar buttons.

Comment 23

[Jesse Ruderman]

Bug 239429 is the same bug for Firefox.

Comment 24

[Robert Kaiser]

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 25

[Robert Kaiser]

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 26

[Robert Kaiser]

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 27

[Robert Kaiser]

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 28

[Robert Kaiser]

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 29

[Robert Kaiser]

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 31

[Philip Chee]

WORKSFORME. Probably fixed by the rewrite to use the Places backend.

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14a1
Build identifier: 20120814163219