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

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.

> 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

*** 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.

.

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

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.

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.

Filed bug 498297 about discoverability.