Closed Bug 82938 Opened 23 years ago Closed 15 years ago

"Search Bookmarks" accessible through manage bookmarks only

Categories

(Firefox :: Bookmarks & History, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: andre, Unassigned)

References

Details

b: 2001052520
os: w2k

Since some days "Search bookmarks..." has gone from the "Search" menu in the
browser.
Why do I have to open Manage Bookmarks now? I used this feature "Search
bookmarks" plenty times before?
Why should mozilla become more and more uncomfortable?
-> UID
Assignee: ben → mpt
Component: Bookmarks → User Interface Design
QA Contact: claudius → zach
Removing this menu item was done by Ben. It's a first step towards getting rid 
of the `Search' menu completely.

> Why do I have to open Manage Bookmarks now?

For the same reason that you have to open a browser window in order to search 
the Web, and for the same reason that you have to open the address book in 
order to search your addresses. If you find the bookmarks window too slow to 
open, then file or fix the bugs about making it faster.

>                                             I used this feature "Search
> bookmarks" plenty times before?

How am I supposed to know?

>                                 Why should mozilla become more and more
> uncomfortable?

Because most of its users will be the sort of people who have no idea that 
Bugzilla exists, those who will find menu items for searching unrelated data 
sources to be more confusing than useful. Therefore it necessarily becomes 
slightly less comfortable to people like you and me, who don't mind having one-
click access to hundreds of features.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
> Removing this menu item was done by Ben. It's a first step towards getting rid
> of the `Search' menu completely.

I've been to #Mozillazine when this has been discussed (yet I think Ben was not
involved there). And as I understood it that item should go under "Bookmarks"
*not* "Manage Bookmarks"

> > Why do I have to open Manage Bookmarks now?
> For the same reason that you have to open a browser window in order to search 
> the Web, and for the same reason that you have to open the address book in 
> order to search your addresses. If you find the bookmarks window too slow to 
> open, then file or fix the bugs about making it faster.

I'm sorry, but I think that this is nonsense. Remember, I have a *browser*
window open and thus I could be very likely that I want to browse the web and
the like thus it could be very likely that I don't remember exactly the page I
want to go and I don't want to fight through the bookmarks manually.

Bookmarks make no sense if regarded separated from the browser, they are to
components belonging to each other and the menus should reflect this.

> Because most of its users will be the sort of people who have no idea that 
> Bugzilla exists, those who will find menu items for searching unrelated data 
> sources to be more confusing than useful.

As fas as I understood we are talking about "Search Bookmarks" not "Search
Bugzilla", I don't get what bugzilla has to do with this. And what about
unrelated data? Searching bookmarks is just about a *completely* normal feature,
a must have, if the browser supports bookmarks, nothing intransparent...

> Therefore it necessarily becomes 
> slightly less comfortable to people like you and me, who don't mind having
> one- click access to hundreds of features.

Come one, even the least experienced user can guess what this means and how it
is used and even the least experienced user will continue to collect bookmarks
and won't sort them in first instance and thus he will be lost trying to find a
bookmark again.

2.) This feature should be added to the bookmark side bar too, just beween
"Add..." and "Manage"...
it has been added to the sidebar, that's ok for me
verified
Status: RESOLVED → VERIFIED
*** Bug 137794 has been marked as a duplicate of this bug. ***
*** Bug 121770 has been marked as a duplicate of this bug. ***
Searching bookmarks is slow.
1. Ctrl+B to open Bookmarks.
2. Ctrl+F to open find/search dialog.
3. Type a search phrase and hit enter.
4. Select the bookmark you want from the search results window.
5. Read the bookmarked page.
6. Close the search results window.
7. Close the bookmarks window.

I also requested a "Search Bookmarks" menu item in the browser in bug 67414 
comment 4, but I'm not sure that's the best way to fix this problem.  
Having "Search Bookmarks" in the browser would only eliminate steps 1 and 7. 
That's what the "Search" button in the search sidebar does, and André thinks 
it's enough.

If you know the first few letters in the name of the bookmark, it's not nearly 
as bad.  The bookmarks menu can cycle between items matching the first letter, 
and the bookmarks window lets you type and match longer strings.

See also:
bug 101642 Location bar autocomplete should include / prefer bookmark entries
bug 117967 accept and autocomplete names of bookmarks in url bar.
bug 162542 quick search of bookmarks
bug 95748  Find Bookmarks should select first result instead of opening search-
results window
> Removing this menu item was done by Ben.

I'd like to point out that this was not me, whoever it was.

> It's a first step towards getting rid of the `Search' menu completely.

The Search menu is now gone, it's a submenu of Tools, and it contains
Search the Web
Search Messages...
Search Addresses...

As said in bug 137794, the latter 2 make not much sense in the browser, but
searching bookmarks does.

> > Why do I have to open Manage Bookmarks now?

> For the same reason that you have to open a browser window in order to search
> the Web, and for the same reason that you have to open the address book in
> order to search your addresses.

No, I don't have to. In Mailnews, I have an entry Tools|Search|Search
Addresses..., and that's how it should be.

Bookmarks are strongly related to browsing (why do we have a Bookmarks menu?),
so I will want to search for them often when in the browser window. Adding a
menu item there makes completely sense.

The "Bookmarks Window" as you call it is in fact a "Bookmarks Manager". The menu
item is called "Manage Bookmarks...". That's what it's for - editing/rearranging
bookmarks. Searching is a completely different function, it's used for
*accessing* bookmarks, just like the Bookmarks menu.

Accessing bookmarks is an part of the browsing process, and searching for
bookmarks can be part of the process of accessing bookmarks. Thus, Search
Bookmarks very much belongs to the Navigator window.

> If you find the bookmarks window too slow to 
> open, then file or fix the bugs about making it faster.

haha. It's not the technical responsiveness of the app which is the problem, it
is the fact that it adds 2 steps to the whole process (as Jesse outlined).

A solution involing the sidebar doesn't help me, because it is an optional
feature and I think that the sidebar (as-is) is a waste of screen-space and I
have it thus disabled. Not unlike many users, I guess.

> If you know the first few letters in the name of the bookmark, it's not nearly 
> as bad.  The bookmarks menu can cycle between items matching the first letter, 
> and the bookmarks window lets you type and match longer strings.

That doesn't help at all, if you are searching for substrings in bookmarks in
subfolders.


REOPENing. Current situation is silly, as are the reasons mentioned for closing.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
.
Assignee: mpt → ben
Status: REOPENED → NEW
Component: User Interface Design → Bookmarks
QA Contact: zach → claudius
Product: Browser → Seamonkey
Assignee: bugs → nobody
QA Contact: claudius → bookmarks
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Fixed somewhat in Firefox by the awesomebar, but the awesomebar misses hits, in my experience. Some way to reliably search the bookmarks, without many clicks, would be good.
Status: UNCONFIRMED → NEW
Component: Bookmarks → Bookmarks & History
Product: SeaMonkey → Firefox
QA Contact: bookmarks → bookmarks
When does it miss hits?
Especially on 3.5 this bug is fixed as now you can specify to search _only_ bookmarks in the awesomebar...
natch, would be nice to also say how.
http://lifehacker.com/5063481/firefox-31-adds-keyword-filters-to-the-awesomebar
"You can restrict the search to your history by typing ^, or bookmarks with *, or tagged pages with +. To make what you’ve typed match only in the URL type @, and for title/tags only use #."
Note that a space must follow the special character, e.g. type "* mozilla" in urlbar to see all bookmarks with "mozilla" in title, URL or tags.

I cannot reproduce the "missing hits", so I'm closing this. Will file a new bug, if I encounter it again. I'll also file a bug on making the awesomebar feature discoverable.
Status: NEW → RESOLVED
Closed: 23 years ago15 years ago
Resolution: --- → FIXED
Filed bug 498297 about discoverability.
You need to log in before you can comment on or make changes to this bug.