Closed Bug 527225 Opened 10 years ago Closed Last year

bookmarks sidebar search just shows the hits, but not the tree-structure.

Categories

(Firefox :: Bookmarks & History, enhancement)

x86
Unspecified
enhancement
Not set

Tracking

()

RESOLVED INACTIVE

People

(Reporter: michel, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

Moin Moin.
Upon searching the bookmarks within the sidebar, just the hits are being shown, but not the tree-structure.
_Tschuess,
__Michael.

Reproducible: Always

Steps to Reproduce:
1.Click on View Sidebar, Bookmarks.
2.Enter something within the search-box.
3.
Actual Results:  
Just the hits are being shown. 

Expected Results:  
The treestructure should be shown, in order to allow evealuating the hits' meanings.
This, in turn, means, that, whilst, e.g., searching for "google" would yield a lot of hits without any(!!!) context regarding their meanings.
Not a security bug.
Group: core-security
Maybe this is the same bug as 171575. I can reproduce it.

I think the bookmarks search of Opera 10 has a great usability, Firefox should have the same behaviour. It's very frustrating when you search for a bookmark location and there is no way to find the path to it.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
Also true for mac, of course.  I use folders a lot and have been frustrated working with the bookmark manager and search.  (see also bug #406157, not a duplicate, but a related problem that one can't search for a folder by name.)
I confirm on Firefox 4b7. 
Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Version: unspecified → Trunk
Behaviour confirmed on Firefox 4.0b13pre (Minefield): Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre

+1 for showing bookmark tree hierarchy for search results. Perhaps some understated UI device could be used to call attention to the actual returned bookmarks themselves, so that they would contrast to the nested folder structure showing the results' "path".
There are at least 4 outstanding bug or enhancement requests on this topic covering 150+ votes to solve a simple problem which should have been solved a long LONG time ago.

The very simple problem is that when you search for and find one or more bookmarks in ANY part of firefox (v10.0.2 Windows in my case) there is absolutely ZERO way of telling **WHERE** that bookmark came from in your extensive, thousands upon thousands of bookmarks.

You "find" it but you can't really figure out where it CAME from.
There is no way to determine what folder inside of a folder inside of whatever folder that bookmark is located.  You can't go to that folder.

The information is useful and needed because sometimes you are retrieving a bookmark and know it is from a larger batch of bookmarks dealing with the same topic or issue.  You know enough to find one of the bookmarks (via search) but you are dead-in-the-water cause there is no way to find the rest of them or go to the folder holding it.

(Yes, I suppose you could export your entire bookmark list in HTML format, load it up and then search that way, but that isn't really a solution is it?)

There is simple solution/request.

For any bookmark which is retrieved from:
1) the 'anything bar' (or whatever we call the URL searching process);
2) the bookmarks sidebar search, or
3) the "Library Organizer" bookmark search...

All bookmarks from these retrieval/search mechanisms should be able to be right-clicked->properties and show the Folder location (in the bookmarks tree) of the bookmark, *OR* (in the case of the Libaray which has columns) the location should appear, if selected, as one of the column values such as Tags, Last Accessed, etc.

Again...the simple act of finding out where a bookmark came from is impossible using normal means.  These bugs have been here for years and all other browsers I'm aware of do this normally.  What is the problem?

Bookmarks can already be right-clicked and choose properties.  Can't we just add an extra field to show the bookmark location??  Library organize already has columns for all the other bookmark attributes, can't one be added to show location?

(PS: the use of the word "Location" on bookmark attributes to denote "URL" is just extra confusing if/when the actual bookmark TREE location is included.  I don't know what you call the new attribute if "Location" is already used for "URL", but I digress.)

FYI: I found the following bug tickets addressing the same basic issue (I'm sure there are more.  I only waded through about 150 before giving up.)  Could someone consolidate them (and the votes!) as well?

BUG: 469421
BUG: 56418  (From year 2000!!!)
BUG: 469416
Honestly, I would have attempted to tackle this bug if I could figure out the Firefox source tree. I looked a while back at the source and couldn't find the code that generates the Bookmark sidebar. Maybe I didn't spend enough time reading all the Firefox development and contribution docs, however I did make an effort to find this at one point.
This could be a good idea but I see a problem here. When you search for youtube for example and you have lots of bookmarks and folders that contain lots of youtube links it will load all your bookmark history with all the sub-folders which will take a moment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think the problem of this report is solved by add-on "Go Parent Folder 2.9.1.1-signed" <https://addons.mozilla.org/de/seamonkey/addon/go-parent-folder/> <https://addons.mozilla.org/de/seamonkey/compatibility/reporter/goParentFolder%40alice>; no need for an additional fix in Browser?
OS: Windows XP → Unspecified
From SeaMonkey point of view: solved with add-on
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.