Users should be able to selectively remove results from the awesomebar without entirely deleting them from the system. Alex and Beltzner suggested a lightweight method of doing this by tagging the URL with a special tag recognized by the Places autocomplete code.

If this will happen how should we handle it if no bookmark exists which uses this tag? So its getting deleted like any other tag? Or has it to be a special type which will not be removed?

So, something like "hidden" that'd have to be localized too, right? This wouldn't be that hard to exclude from autocomplete results, but hiding it in the tag container might be a bit harder...

(In reply to comment #1) > If this will happen how should we handle it if no bookmark exists which uses > this tag? So its getting deleted like any other tag? Or has it to be a special > type which will not be removed? > I think that if a tag is unused it does not exist, therefore the tag container would no longer show up in the Tags folder in the library. Once tags are integrated into the query system, we could have a saved search that shows all bookmarks tagged with the special tag, and it's description could explain usage of the special tag. (In reply to comment #2) > wouldn't be that hard to exclude from autocomplete results, but hiding it in > the tag container might be a bit harder... > Not sure what you mean here. This is strictly about hiding bookmarks from autocomplete results, nowhere else.

Would this only block the pages tagged as private? How about other pages from the same domain? What happens if the user searches for the tag? How about exposing the existing hidden attribute to the bookmarks UI? Certain pages already don't show up because they're hidden like places: URIs.

>Would this only block the pages tagged as private? How about other pages from >the same domain? What happens if the user searches for the tag? The idea was to allow users to create bookmarks that wouldn't show up in the results, under the assumption that they were either deleting their browsing history, or in the future they would be in some type of private browsing mode where history would no longer be recorded. Searching for "private" shouldn't display any of the pages that have been tagged private.

Hidden places don't show up in the location bar (frecency is 0), and the only hidden "bookmarks" right now are some of the places: uris. So non-places: bookmarks that are hidden could be made to still show up in the bookmarks view?

(FYI, when I say hidden, I mean the moz_places column "hidden") SELECT url, h.title FROM moz_bookmarks JOIN moz_places h ON h.id = fk WHERE hidden = 1 This should be more straightforward than localizing a special string used as a tag (there could be comma separated tags for a bookmark). The library view for bookmarks could have a checkmark "don't show this bookmark in the location bar".

i think the easiest solution is adding a column to moz_places, that will usually contain 1, 0 for invisible entries... and this column is directly multiplied with frecency.

but also tag solution is possible, but i don't see why a specialized query for showing sites with that tag... will be visible in Tags as usual, insted the tag autocomplete should suggest the "special" tag. (In reply to comment #3) > (In reply to comment #2) > > wouldn't be that hard to exclude from autocomplete results, but hiding it in > > the tag container might be a bit harder... > > > > Not sure what you mean here. This is strictly about hiding bookmarks from > autocomplete results, nowhere else. I think he means that creating a tag will expose it in the Library under Tags and in tag smart queries like Recent Tags

Adding the 'invisible' column would work just as well as overloading the 'hidden' column without needing to worry about the other uses of 'hidden'. No need to "multiply" by invisible because we can just short-circuit the frecency computation. What's the intent of this bug though? Making a single bookmark invisible, e.g., http://www.mozilla.com/, doesn't help prevent http://www.mozilla.com/prettyStuffHere from showing up in the location bar. So potentially we shouldn't really be tracking invisible by bookmark and instead by hostname. UI-wise, the user can choose to make a bookmark's site invisible and any bookmark that shares the same site is made invisible. (The "make this site invisible" checkbox is checked for all site-related bookmarks.) Then calculating frecency would need to hit moz_invisible (fk of rev_host ? just to reuse existing columns) and short-circuit to 0.

mconnor wanted the user to be able to specify a list of tags that would indicate that pages should not be shown in the location bar. The text field for specifying this list will likely be in the privacy prefpane. >What's the intent of this bug though? The idea is for users to be able to create bookmarks to sensitive information, and without having Firefox show this information back to them in the location bar. >http://www.mozilla.com/, doesn't help prevent >http://www.mozilla.com/prettyStuffHere from showing up in the location bar. The idea is for this feature to work in conjunction with private browsing mode, so that history entries do not exist in the first place. I don't really like the idea of a domain blacklist since I feel like that might result in users micromanaging the list of sites they don't want Firefox to display after the fact, which could potentially be a lot of work, instead of either deleting segments of history, or entering private browsing mode, both of which are relatively easy.

(In reply to comment #11) > The idea is for this feature to work in conjunction with private browsing mode, > so that history entries do not exist in the first place. In conjunction? After exiting private browsing mode those results should not exist in history at all and so they would be out of the awesomebar too, so feels like private browsing mode would be enough: a user enables it, navigate to sites that he does not want to appear in the awesomebar/history, and disable it after (clearing all related data). So i don't see what is this adding to private browsing mode that should not work "out of the box" using it. Also notice we only support tagging for bookmarks and hiding a bookmark is not exactly "useful"

Instead i think it would be quite useful being able to not show results based on domain or on contained words. So i can tell the awesomebar to not show urls coming from "www.baddomain.org" or that contains "badWord". Someone is working on an extension that should allow removing all visits based on a blacklist of words so that they do not appear in the bar next time. Also someone would like to low/high priorities of certain domains against others... so ideally we should have a sort of bonus added to frecency so that a negative bonus will give less awesomebar priority to a certain domain, a positive bonus would give bigger priority, a 0 bonus would produce a 0 frecency (don't show). For example IIRC in the newsgroup it has been posted the example of looking for a bug and having the gmail bugmail before the bugzilla entry. So actually tags would be at least 2 like "hiddenDomains" and "lowPriorityDomains" and should act on domains rather than single uris, so bookmarking www.test.com and tagging hidden would also hide www.test.com/anothersection/anotherpage.htm. Plus a locationbar options when searching for a single word longer than X chars that could sound like 'Hide all pages containing "word"'

wip for back-end. mardak do you have time for a first review pass? the csv searching code is kinda hacky, probably a better way to do that.

>Instead i think it would be quite useful being able to not show results based >on domain or on contained words. >So i can tell the awesomebar to not show urls coming from "www.baddomain.org" >or that contains "badWord". Overall I like how this would enable users to leverage the history in their awesomebar, while not being embarrassed. However, a few concerns: -hard to manage -you won't necessarily catch everything in your blocklist -to invade the user's privacy you can just go take a look at their blocklist I kind of like the idea of giving the user the option of using a parental filter to block entries from showing in the awesomebar, since this would cut down on the hard to manage and privacy concerns. It still wouldn't necessarily catch everything though. In the meantime private browsing mode + not showing bookmarks with a particular tag + not showing any history items will certainly help people.

It seems wasteful to filter out a small number of bookmarks from all pages for the current search on every query. Alternatively we could set the frecency to 0 of bookmarks with tags that match the preference whenever the preference changes. But that runs into problems 1) needing to keep setting the frecency to 0 when visiting the page 2) restoring the frecency when private tags are removed. I suppose we could push things to sql, but doing work in sqlite vs in autocomplete probably doesn't save much runtime.? (But tweaking the sql queries could get complicated: 1) moz_places/temp 2) base, adaptive, keyword? queries.) ... WHERE h.frecency <> 0 AND NOT (select 1 from places join bookmarks join bookmarks t where t.title in (user,specified,tags) limit 1) ...

(In reply to comment #15) > Overall I like how this would enable users to leverage the history in their > awesomebar, while not being embarrassed. However, a few concerns: > > -hard to manage right click on an item in the awesomebar dropdown or on a bookmarks or on a history items and choose "don't show addresses from this domain in the locationbar" > -to invade the user's privacy you can just go take a look at their blocklist So actually i could simply take a look at their private tag folder, but while the tag folder will show EXACT uris blocked, the blocklist would only report domains, so that is showing less infos really. I guess at that point the first thing a curious user will do will be to take a look at tagged uris, much worst than looking to a list of domains. > It still wouldn't necessarily catch everything though. sorry i don't understand what you're trying to say here :\ catching a single uri is really less useful than catching on an expression. > In the meantime private browsing mode + not showing bookmarks with a particular > tag + not showing any history items will certainly help people. So to use this feature i would have to disable history search in the awesomebar? that's not awesome. From what i see the idea is "use private browsing, if you still need to bookmark something private you should do that while in PB and tag the item so it will not appear". That works, but i have to remember always to enable PB, if i forget only one time, this become useless.

>From what i see the idea is "use private >browsing, if you still need to bookmark something private you should do that >while in PB and tag the item so it will not appear". That works, but i have to >remember always to enable PB, if i forget only one time, this become useless. Yeah that is the current idea. You are right that the feature becomes useless if you forget one time. We have a feature kind of like what you are proposing over in bug 460086, except that it is about deleting history (instead of annotating it not to be shown), and you delete items in the library as opposed to in the awesome bar. I initially wanted to expose that in the awesome bar, but mconnor noted that there are lot of cases where people are deleting individual entries and not interested in clearing a whole domain. I guess we could do a right click menu, but that is kind of an unusual action for this type of rich list view.

I permanently using typing in awesome bar for navigation. Often I not want to clear or hide anything, I want to have my history - I simply not want to see pages looks similar to some of my requests. I want to have possibility to filter some domain names from awesomebar search suggestions. It web interface pages. I'd like to can to set some like "mycms.mydomain.com/*", and got suggestion "mycms.mydomain.com", but not "mycms.mydomain.com/lkjfxbhvlkdsfhblkdsfuhb". It not a question of privacy.

Igor, your request is different from the feature this bug is about, and sounds a lot more like what Marco is describing. Marco, can you file a separate bug for domain block-list feature. After this discussion, the use-case for this bug is looking narrower than ever. Not only that, as Marco pointed out, there will likely be a mismatch between the user's expectation and the limited privacy that this feature would provide, possibly increasing the exposures of sensitive data (due to people thinking a whole site has been blocked).

Yes, this overly narrow, and doesn't address almost any of the use-cases sufficiently. After talking w/ UX about this, marking WONTFIX and blocking-. If you'd like this feature, please add use-cases here and we can take a look again for 3.2.

I actually like this idea very much. I suggest not overdoing this by talking about domain blocking and private browsing, instead I agree with the relatively simple route that Marco suggested. (In reply to comment #8) > i think the easiest solution is adding a column to moz_places, that will > usually contain 1, 0 for invisible entries... and this column is directly > multiplied with frecency. The idea here is to stop certain specific bookmarks or certain specific folder of bookmarks as well as any history of visits to those bookmarks from showing up on the awesome bar and not to block an entire domain. For example, if I make a few bookmarks as follows: www.google.com/mapmaker www.google.com/friendconnect www.google.com/analytics www.google.com/labs Now say I don't want www.google.com/friendconnect showing up on the awesome bar, I should be able to mark a check box at the "Edit Bookmark" dialog which would set the "privacy flag" value for that exact URL to be 0. Example: http://i16.photobucket.com/albums/b15/lordnair/bugzilla_private_bookmark_ex.png This suggestion of adding a 1=show/normal 0=private/hidden "privacy flag" column to moz_places and choosing to display it based the result of a multiplication of the flag value and the frequency should prevent bookmarks and any history associated with that specific URL from turning up in the awesome bar as the user types. This "privacy flag" should also be applicable to evaluate whether an entry should appear on "Recent Tags" and "Recently Bookmarked". However, the user should still be able to navigate to the bookmark using the old fashioned way of manually locating the bookmark and clicking on it.

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