239429 - display URL in status bar while using bookmark & history sidebars

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, enhancement)

Description

[Miha Pecnik]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040210 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040210 Firefox/0.8

When I open up my bookmark side bar (ctrl+b) and I go through my bookmarks the
URL of the bookmarks isn't displayed in the status bar like it is if/when I知
using the bookmark menu. Would be great if there was some kind of consistency there.

Reproducible: Always
Steps to Reproduce:
1. Open up firefox
2. Open up the bookmarks sidebar
3. Hover over any bookmark

Actual Results:  
The url of the bookmarks isn't displayed in the status bar.

Expected Results:  
Display the URL in the status bar like it does when using the bookmark menu.

Comment 1

[Jesse Ruderman]

Bug 64892 is the same bug for Seamonkey.

Comment 2

[Mike Connor [:mconnor]]

tweak summary since this is an enhancement request.  Adding polish keyword since
we do this inconsistently for bookmarks.

Comment 3

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

would be nice. not going to hold. patches welcome

Comment 4

[José Jeria]

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

Comment 5

[Ryan Polk (Quark)]

Attachment: patch v1

bookmarksPanel changes basically copy bookmarksManager, and change click to
double-click.

History already had an onselect event so I just added the statusbar change
there.

The status bar remains the same until a page is loaded or link hovered, but I
don't know how/where to change that or if it's worth it.

Comment 6

[Mike Connor [:mconnor]]

Comment on attachment 153724 [details] [diff] [review]
patch v1

if it doesn't restore the previous value, this is better off not going in. 
Busted UI is worse than no UI at all.

I don't even know what the best solution for these sidebars is (neither did
hyatt, iirc, which is why this only works for the Bookmarks menu item at
present

Comment 7

[Ryan Polk (Quark)]

Attachment: includes onunload event

After testing some more, I poorly worded that and didn't include everything. 
Anything that changes status bar text takes precendence over this(including the
messages while a page is loading).

In this new version I include an onunload event to reset the status bar to
"Done" once the sidebar is closed -> the same behavior as unhovering a link.
This gets rid of the behavior I was trying to describe above, where a URL from
your bookmarks/history could get stranded until you performed any action which
would update the status bar.

Also selecting a history folder resets it to Done, unless anyone has a better
recommendation for what a history folder should say in the status bar.

Comment 8

[Ryan Polk (Quark)]

Comment on attachment 153779 [details] [diff] [review]
includes onunload event

Forgot comment: now the only way that this acts differently from, for instance,
hovering a link is that a hover URL placed in the status text takes precedence
over everything else until it's unhovered.

My patch only changes the status bar until it's changed again -> it doesn't
freeze it.

Comment 9

[Mike Connor [:mconnor]]

this is where the whole "right thing to do" becomes tricky.

Changing the statusbar to "Done" isn't in itself sufficient, since there would
be a previous status that isn't "Done" in a number of cases (i.e. if the content
area is loading a page).  Before writing more patches, we need to spec how this
should interact with the status bar in all situations.

Comment 10

[Norbert]

When fixing the here described problem, please _also_ remove the tooltips (I
think that's how you call these yellow backgrounded text popups) that are only
shown if the mouse is over a bookmark button in the bookmarks toolbar.

If the URL is shown in the status bar they are not needed anymore. Further on
they are not shown for bookmark folders and bookmarks within folders and nowhere
in the bookmarks menu. So they are an inconsistency.

So with fixing the here described bug, you should also remove these not needed
inconsistent yellow tooltips!

Comment 11

[Norbert]

(In reply to comment #10)


I hope this bug also addresses the bookmarks toolbar, not only the sidebar!?

I have set comment #10 here because my bug #251737 is set as duplicate of this bug.

Here a copy of bug #251737:


"If you move the mouse pointer within the bookmarks menu, the URL of the bookmark
where the mouse pointer is currently over, is displayed in the status bar.

But this does not work for the bookmarks toolbar.



Reproducible: Always
Steps to Reproduce:

Actual Results:  
If the mouse pointer is over a bookmark-button, the URL should be displayed in
the status bar."



Please respond !!!

Comment 12

[Mike Connor [:mconnor]]

Comment on attachment 153779 [details] [diff] [review]
includes onunload event

comments given over IRC

basically we need to figure out how this _should_ be handled (i.e. what does
IE/Opera do, what do the Apple/GNOME HIGs say about this subject)

onmouseover seems right, but it doesn't deal with the selection issue.

as for removing the tooltips etc, I'm not sure that they're not a better
solution in some cases, since they can provide more details about a bookmark
than the statusbar.

All this should probably wait until post-1.0 as time's pretty short to be
speccing UI stuff.

Comment 13

[Norbert]

(In reply to comment #12)

> as for removing the tooltips etc, I'm not sure that they're not a better
> solution in some cases, since they can provide more details about a bookmark
> than the statusbar.

If you think tooltips would be better, than they should be used everywhere where
bookmarks are ...

- in the bookmarks menu
- in the bookmarks toolbar
- in the bookmarks sidebar
- in the bookmarks manager

... in order to keep consistency. Currently they are only shown for bookmarks
that are directly in the bookmarks toolbar (and not in sub-folders.)

Maybe if tooltips are used, then the status bar is not needed for displaying
bookmark-URLs anymore, because the user does not need to have the URL displayed
2 times.
But one disadvantage of the tooltips method is that some time is needed for
waiting until they open, while the status bar is updated directly when
"browsing" through the bookmarks menu.

Whatever solution you prefer, please make sure to implement it uniform.

Comment 14

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Comment 15

[Steffen Wilberg]

Bug 213163 just implemented this for the bookmarks *toolbar*.

Comment 16

[(mostly gone) XtC4UaLL [:xtc4uall]]

would this nice-to-have be still in FF3 timeframe?

Comment 17

[Michael Schonfeld]

Deal, I'm gonna implement this the same way like Bug 213163, using the setOverLink function.  This way I "don't have to worry" about restoring the status-bar to its original state (i.e. "Done").  Any objections?

Comment 18

[Michael Schonfeld]

Attachment: v2

Comment 19

[Michael Schonfeld]

Attachment: v2.2

Received a shout-out from Ace (mano) to add the same implementation for the History sidebar.

Comment 20

[Michael Schonfeld]

Attachment: v2.3

Fixed wrong header. Rephrased comments.

Comment 21

[Michael Schonfeld]

Attachment: v2.4

Rephrased comments (again). 

I forgot the mention that this patch also implements the same functionality for the history sidebar.

Comment 22

[Asaf Romano (gone)]

Comment on attachment 303051 [details] [diff] [review]
v2.4

r=mano.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 303051 [details] [diff] [review]
v2.4

a=beltzner for 1.9

Comment 24

[Asaf Romano (gone)]

mozilla/browser/components/places/content/bookmarksPanel.xul 1.9
mozilla/browser/components/places/content/history-panel.xul 1.13
mozilla/browser/components/places/content/sidebarUtils.js 1.2

Comment 25

[Steffen Wilberg]

When hovering over bookmarks or folders in the bookmarks sidebar, nothing happens in the sidebar. Instead, tons of this error are logged in the error console:

Error: tree.view.nodeForTreeIndex is not a function
Source File: chrome://browser/content/bookmarks/sidebarUtils.js
Line: 56

Comment 26

[Michael Schonfeld]

Steffen: Using the latest nightly build generates different results for me.
I am *not* getting any errors, but I am experiencing some very weird behavior!

More specifically:
1. Both sidebars do not load from the View->Sidebars menu. Only through keyboard shortcuts.
2. After hitting CMD+B to open the bookmarks sidebar, I have to click on a folder for the URLs to start showing up in the status bar.

I believe that this should be filed as another bug all together.

Comment 27

[Michael Schonfeld]

Correction to number two (2) - After opening a sidebar, you much click inside its window somewhere to activate the status bar text.

Comment 28

[Steffen Wilberg]

> Steffen: Using the latest nightly build generates different results for me.
> I am *not* getting any errors, but I am experiencing some very weird behavior!
But you do have the javascript.options.showInConsole pref set to true, don't you?

> 1. Both sidebars do not load from the View->Sidebars menu. Only through
> keyboard shortcuts.
Works for me.

> Correction to number two (2) - After opening a sidebar, you much click inside
> its window somewhere to activate the status bar text.
Indeed, that works for me as well. And if I click around somehow, it gets broken again.

Comment 29

[Michael Schonfeld]

Attachment: follow up for checkin

Sorry! My bad.. I forgot to include the file where I did the QueryInterface to my diff!

Comment 30

[Asaf Romano (gone)]

mozilla/browser/components/places/content/tree.xml 1.95

Comment 31

[Nickolay_Ponomarev]

Typo: "clearURLFromStausBar".

Comment 32

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #31)
> Typo: "clearURLFromStausBar".

Fixed that.
mozilla/browser/components/places/content/bookmarksPanel.xul 	1.10 	mozilla/browser/components/places/content/history-panel.xul 	1.14 	mozilla/browser/components/places/content/sidebarUtils.js 	1.3 

Comment 33

[Michael Schonfeld]

Thanks Gavin!

Comment 34

[Steffen Wilberg]

Works fine now.

Comment 36

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv