should unvisited bookmarks be searched in url bar? the current algorithm for bug #389491 will not find any unvisited bookmarks. should we fix it so that unvisited bookmarks appear in the results? note, the idea in bug #392399 help make the implementation easier / cleaner.

How did the bookmarks become unvisited? Is the user importing a profile from Firefox 2 and we don't have a visit count for any of the bookmarks yet? In that case I think it would make a lot of sense for them to be searched against.

i think that bookmarks could also be unvisited after a Clear Private Data, and you will not get bookmarks on autocomplete until you visit them at least once.

mconnor writes: I think they should probably be searched and weighted higher. alex: bookmarks can become unvisited after removing history manually or after history naturally expires.

Blocking on decision, but I tend to agree with mconnor and alex.

I definitely think that unvisited bookmarks should show up in auto-complete results. The location bar is going to say "Search Bookmarks and History" (bug #396816), so we don't want the behavior to be "Search Bookmarks* and History" :)

moving to m10

a few additional data points from a discussion with dan mills, you could have no visits if: 1) you synched bookmarks, but not history 2) you disabled history completely (currently that means set to 0 days)

I really think this bug should have a higher priority than P5. Autocomplete is supposed to search bookmarks and history, but with this bug it won't search all the bookmarks for a reason completely unknown to the user. See comment 5. In particular, when the user first reads the description "Search Bookmarks and History" and tries this out... it won't search his bookmarks at all, because imported bookmarks have visit count of 0. This is a major bug in heavily exposed feature.

(In reply to comment #9) > I really think this bug should have a higher priority than P5. Autocomplete is Don't worry! Note that it is still marked blocking‑firefox3+. What the P5 means is that it won't make beta1.

mconnor said on m.d.planning that P5 equates to "probably cut". That's why I am asking to reevaluate the priority.

Oh eep! I missed that post, I thought it was just untriaged. So nevermind me... Mike, FYI, sync makes this problem a little worse, because synced bookmarks won't show up in autocomplete until you go to them first. (same problem, you'll just see it a little more often).

Er, but I forgot to add--*history* sync (which we don't do yet) would make autocomplete for bookmarked sites work again in most cases.

Would really like to see a fix for this, but not a blocker for release.

Re-noming for blocker as this limits the otherwise awesome awesomebar!

So, what are we doing with Shift+Delete interaction here?

Since my fix for bug 240397 because it might confuse Shift-Delete users, the logical answer here would be to not support this request. I think it's crazy that the tiny fraction of users who use shift-delete are dictating design for everybody else.

>I think it's crazy >that the tiny fraction of users who use shift-delete are dictating design for >everybody else. I agree, but I think we can probably make everyone happy in this case. >So, what are we doing with Shift+Delete interaction here? I think shift+delete should completely remove from history (and bookmarks if the page is bookmarked), because the user's intent is "don't show this again."

this is going to be fixed along with bug #394038

(In reply to comment #18) > ... > I think shift+delete should completely remove from history (and bookmarks if > the page is bookmarked), because the user's intent is "don't show this again." Isn't this what Delete already does?

(In reply to comment #20) > this is going to be fixed along with bug #394038 Although that landed, this doesn't work with any of the trunk nightlies--even in new profiles--that I tested.

(In reply to comment #22) > (In reply to comment #20) > > this is going to be fixed along with bug #394038 > > Although that landed, this doesn't work with any of the trunk nightlies--even > in new profiles--that I tested. > See bug 394038 comments - it was backed out.

fixed in bug 394038

in-litmus+ https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=5150 Verified FIXED using: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b4pre) Gecko/2008020604 Minefield/3.0b4pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008020604 Minefield/3.0b4pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020604 Minefield/3.0b4pre