Closed Bug 239429 Opened 20 years ago Closed 16 years ago

display URL in status bar while using bookmark & history sidebars

Categories

(Firefox :: Bookmarks & History, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3 beta4

People

(Reporter: mihapecnik, Assigned: dev)

References

Details

(Keywords: polish)

Attachments

(3 files, 4 obsolete files)

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.
Bug 64892 is the same bug for Seamonkey.
Status: UNCONFIRMED → NEW
Ever confirmed: true
tweak summary since this is an enhancement request.  Adding polish keyword since
we do this inconsistently for bookmarks.
Keywords: polish
Summary: url isn't displayed in status bar while using bookmark sidebar → display URL in status bar while using bookmark sidebar
Flags: blocking1.0?
would be nice. not going to hold. patches welcome
Flags: blocking1.0? → blocking1.0-
*** Bug 251737 has been marked as a duplicate of this bug. ***
Attached patch patch v1 (obsolete) — Splinter Review
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.
Attachment #153724 - Flags: review?(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
Attachment #153724 - Flags: review?(mconnor) → review-
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.
Attachment #153724 - Attachment is obsolete: true
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.
Attachment #153779 - Flags: review?(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.
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!
(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 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.
Attachment #153779 - Flags: review?(mconnor) → review-
(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.
Assignee: p_ch → vladimir
Assignee: vladimir → vladimir+bm
Assignee: vladimir+bm → nobody
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
OS: Windows XP → All
Version: unspecified → Trunk
Bug 213163 just implemented this for the bookmarks *toolbar*.
would this nice-to-have be still in FF3 timeframe?
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?
Attached patch v2 (obsolete) — Splinter Review
Attachment #302554 - Flags: review?(mano)
Attached patch v2.2 (obsolete) — Splinter Review
Received a shout-out from Ace (mano) to add the same implementation for the History sidebar.
Attachment #302554 - Attachment is obsolete: true
Attachment #302676 - Flags: ui-review?(beltzner)
Attachment #302676 - Flags: review?(mano)
Attachment #302554 - Flags: review?(mano)
Assignee: nobody → dev
Flags: blocking-aviary1.0-
Assignee: dev → nobody
Component: Bookmarks → Places
QA Contact: bookmarks → places
Attached patch v2.3 (obsolete) — Splinter Review
Fixed wrong header. Rephrased comments.
Attachment #302676 - Attachment is obsolete: true
Attachment #303046 - Flags: ui-review?(beltzner)
Attachment #303046 - Flags: review?(mano)
Attachment #302676 - Flags: ui-review?(beltzner)
Attachment #302676 - Flags: review?(mano)
Attached patch v2.4Splinter Review
Rephrased comments (again). 

I forgot the mention that this patch also implements the same functionality for the history sidebar.
Attachment #303046 - Attachment is obsolete: true
Attachment #303051 - Flags: ui-review?(beltzner)
Attachment #303051 - Flags: review?(mano)
Attachment #303046 - Flags: ui-review?(beltzner)
Attachment #303046 - Flags: review?(mano)
Comment on attachment 303051 [details] [diff] [review]
v2.4

r=mano.
Attachment #303051 - Flags: review?(mano) → review+
Assignee: nobody → dev
Attachment #303051 - Flags: ui-review?(beltzner) → ui-review+
Attachment #303051 - Flags: approval1.9?
Comment on attachment 303051 [details] [diff] [review]
v2.4

a=beltzner for 1.9
Attachment #303051 - Flags: approval1.9? → approval1.9+
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
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Summary: display URL in status bar while using bookmark sidebar → display URL in status bar while using bookmark & history sidebars
Target Milestone: --- → Firefox 3 beta4
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Correction to number two (2) - After opening a sidebar, you much click inside its window somewhere to activate the status bar text.
> 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.
Sorry! My bad.. I forgot to include the file where I did the QueryInterface to my diff!
Attachment #304755 - Flags: review+
mozilla/browser/components/places/content/tree.xml 1.95
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Typo: "clearURLFromStausBar".
(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 
Thanks Gavin!
Works fine now.
Status: RESOLVED → VERIFIED
Hardware: PC → All
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.