display URL in status bar while using bookmark & history sidebars

VERIFIED FIXED in Firefox 3 beta4

Status

()

Firefox
Bookmarks & History
--
enhancement
VERIFIED FIXED
13 years ago
8 years ago

People

(Reporter: Miha Pecnik, Assigned: Michael Schonfeld)

Tracking

({polish})

Trunk
Firefox 3 beta4
polish
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 4 obsolete attachments)

(Reporter)

Description

13 years ago
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

13 years ago
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

Updated

13 years ago
Flags: blocking1.0?
would be nice. not going to hold. patches welcome
Flags: blocking1.0? → blocking1.0-

Comment 4

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

Comment 5

13 years ago
Created attachment 153724 [details] [diff] [review]
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.

Updated

13 years ago
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-

Comment 7

13 years ago
Created attachment 153779 [details] [diff] [review]
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.

Updated

13 years ago
Attachment #153724 - Attachment is obsolete: true

Comment 8

13 years ago
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.

Comment 10

13 years ago
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

13 years ago
(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-

Comment 13

13 years ago
(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.

Updated

13 years ago
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

Updated

10 years ago
OS: Windows XP → All
Version: unspecified → Trunk

Comment 15

9 years ago
Bug 213163 just implemented this for the bookmarks *toolbar*.
would this nice-to-have be still in FF3 timeframe?
(Assignee)

Comment 17

9 years ago
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?
(Assignee)

Comment 18

9 years ago
Created attachment 302554 [details] [diff] [review]
v2
Attachment #302554 - Flags: review?(mano)
(Assignee)

Comment 19

9 years ago
Created attachment 302676 [details] [diff] [review]
v2.2

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
(Assignee)

Comment 20

9 years ago
Created attachment 303046 [details] [diff] [review]
v2.3

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)
(Assignee)

Comment 21

9 years ago
Created attachment 303051 [details] [diff] [review]
v2.4

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

Updated

9 years ago
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
Last Resolved: 9 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

Comment 25

9 years ago
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 → ---
(Assignee)

Comment 26

9 years ago
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.
(Assignee)

Comment 27

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

Comment 28

9 years ago
> 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.
(Assignee)

Comment 29

9 years ago
Created attachment 304755 [details] [diff] [review]
follow up for checkin

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
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED

Comment 31

9 years ago
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 
(Assignee)

Comment 33

9 years ago
Thanks Gavin!

Comment 34

9 years ago
Works fine now.
Status: RESOLVED → VERIFIED
Hardware: PC → All
Duplicate of this bug: 65980
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.