Closed Bug 258977 Opened 20 years ago Closed 19 years ago

bookmark search results does not reveal hierarchy that bookmark was found in

Categories

(Camino Graveyard :: Bookmarks, defect)

Product:
Camino Graveyard
Component:
Bookmarks
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED INVALID
Milestone:
Future

People

(Reporter: jwinshell, Assigned: mikepinkerton)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.4.2 (KHTML, like Gecko) Safari/125.9
Build Identifier: 2004091108 (v0.8+)

Bookmark search results are presented flatly in a separate pane at the bottom of the bookmarks 
window.  This UI design does not reveal the hierarchy that the bookmark was found in.   The hierarchy 
in which a bookmark was found is frequently as important as the bookmark search result itself.  
Frequently I will search for a bookmark I remember just to find the hierarchy.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
I agree that this is a more elegent way of shoing the results. Note that we
already have a reveal button.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
@Jasper: I can't find that "reveal" button, but having that information in eg.
the Properties dialog would be ok for me (an extra column would be much better,
though).
Forgot to note that I'm using the Suite (Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7.5) Gecko/20041217 MultiZilla/1.7.0.1c Mnenhy/0.7) on a PC...
Note that this bug is raised against Camino, which has an entirely different
bookmark manager from the Suite.

This is still an issue following smfr's rewrite of the bookmark manager. We now
display the search results in the main panel (which is a big improvement) but
without the hierarchy. Showing the matching bookmarks with the hierarchy is
potentially confusing - it could look like we've matched items that don't match.
(e.g. where a bookmark matches but the folder its in doesn't).

Proposals for dealing with this:
Show only parent folders of matches, hide all other folders.
Show folders that don't match but have matching children in grey or some other
colour.

Or just add a reveal button and stick to a flat search.
(In reply to comment #4)
> Note that this bug is raised against Camino, which has an entirely different
> bookmark manager from the Suite.

Sorry, I wasn't aware of the differences between Camino and the Suite,
and also have no access to a Mac. Still, this looked like the most
likely bug to comment on, short of creating a potential duplicate.

> This is still an issue following smfr's rewrite of the bookmark
> manager. We now display the search results in the main panel

Please have an option to display them in a new tab.

> (which is a big improvement) but
> without the hierarchy. Showing the matching bookmarks with the
> hierarchy is potentially confusing - it could look like we've
> matched items that don't match. (e.g. where a bookmark matches
> but the folder its in doesn't).

Off the top of my head I don't see how this could happen, but
if there are only these two cases, I'd say that they should
be colour-coded, or each marked with one of two icons (eg, a
folder icon where the folder matches, and a page icon, where
the trailing part matches), in a new column like those other
columns which are already there.

> Proposals for dealing with this:
> Show only parent folders of matches, hide all other folders.
> Show folders that don't match but have matching children in grey or some other
> colour.
> 
> Or just add a reveal button and stick to a flat search.

Any of the two latter proposals, and the one using icons, are
fine from where I stand, only not showing them (first proposal)
doesn't seem to be the right thing to do.

But since you program, you decide!
What should we do with this now that we have quicksearch?
To me, the "reveal" CM idea also proposed in other "where is this bookmark
living in the BM" bugs--and addding it to the "action" button, sort-of Bruce's
idea above--seems like a good one, both clear and simple.

If parent folders where shown, you either a) get a lot of folders shown to show
the parent hierarchy of a deeply-nested bookmark, or b) get a parent folder but
still don't know where it rests in the overall hierarchy--unless there's a third
implementation option for parent folders I can't think of.  In both cases, plus
Bruce's other option, grey out those with no matching children, you still have
lots of "garbage" to sort through if the search returns more than just a few
results, making finding the bookmark you wanted more difficult.

Another option would be to mirror the Finder's behavior (at least in 10.2 and
10.3) and have a split pane at the bottom of the flat results list; this pane
could display the hierarchy of a selected bookmark and double-clicking on the
parent (of higher) folder would then open that folder.

I still prefer the "reveal" option.
Since a bookmark search does not allow editing of a bookmark (search, select
bookmark --> all editing buttons are disabled, and only re-enable if selected
through navigation), this bug is a painpoint for me.
(In reply to comment #8)
> Since a bookmark search does not allow editing of a bookmark (search, select
> bookmark --> all editing buttons are disabled, and only re-enable if selected
> through navigation), this bug is a painpoint for me.

Which editing buttons? I can Get Info on a bookmark in search results, and edit
it that way.
Perhaps comment 8 is referring to History (in which case it's bug 299799)?
Otherwise, I get the same results as Simon in comment 9.
Does not apply to the current bookmarks UI.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Hello,

while this bug is tagged for Camino only, the same problem exists in
Seamonkey, Mozilla Suite and Firefox at least. Your resolution as
"invalid" is highly invalid to me!
a_geek@web.de: this is a Camino bug, as was already mentioned to you a year ago in comment 4.  

If you have a problem with the UI of the Suite/SeaMonkey or Firefox, please open a bug against that product.

Making pointless comments in a Camino bug is counterproductive and bad form.
Status: RESOLVED → VERIFIED
Sorry for overreacting to a number of problems with
Mozilla in general, like eg. highly privacy-invading
defaults in FF. :(

In the meantime I have been redirected to Bug #56418 for this
bookmark problem.


(In reply to comment #14)
> In the meantime I have been redirected to Bug #56418 for this
> bookmark problem.

This is a Mozilla bug, not a Camino bug. What you should really latch onto is bug 229513.
(In reply to comment #15)
> This is a Mozilla bug, not a Camino bug.

I think you meant "*That* is a Mozilla bug", since this definitely is a Camino bug.  a_geek@web.de is looking for a Mozilla bug though (see comments 3 and 12), so bug 56418 is the right one.
You need to log in before you can comment on or make changes to this bug.