Being able to define keywords (? = google search with param) allows to have quick access to several utilities sites like google: "? mozart" or "? satie" Unfortunately, the keyword-URLs are no listed in the Autocomplete menu. Typing "?" in the Location field does not show anything. Store also keyword-URLs in the Autocomplete menu. Build 0107.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've missed this for quite some time, I think it's right to autocomplete on anything you've ever typed then loaded from the location bar.
I think this is a dup of bug 188188 (since keywords are technically bookmarks).
Sorry, I mean bug 247837.
I should cut down on the tabs! bug 162450 /me goes for a walk
This bug means, if a user searches for "keyword searchterm" and types in "keyword s" in the location bar, it will autocomplete with "keyword searchterm" since the user has searched for it previously. It is thus, not a dupe of any of those bugs and is valid, afaict.
Summary: Memorize Keyword-URLs in Location field Autocomplete menu → Memorize Keyword Searches in Location field Autocomplete menu
We get the autocomplete results from the history, so if we wanted to this, we'd have to add both the keyword URI and the "resolved" URI to the history (so you don't lose search queries, for example). Assuming this is okay (and works okay, obviously some testing is important) the code to be changed is found here: http://landfill.mozilla.org/mxr-test/mozilla/source/camino/src/browser/BrowserWindowController.mm#1907
Assignee: mikepinkerton → nobody
QA Contact: bugzilla → location.bar
Whiteboard: [good first bug]
Target Milestone: Camino1.1 → Camino1.2
Anyone interested in trying to fix this? I'd love to see it fixed. :)
Created attachment 237554 [details] [diff] [review] Proposed patch Here's a proposed patch. Except for the new method, most of the change is actually just changing a variable name to clarify it. Let's test this for a few days first, to make sure it doesn't regress anything.
This puts a whole bunch of title-less entries in history, which looks really weird; I don't think that's really the behavior we want. Ideally they wouldn't be in history, but in a side list that's merged in for autocomplete. In order to prevent them for building up forever, they'd probably need to be associated with their corresponding resolved version, and removed when the corresponding history entry goes away. Is there any kind of hook in history that would allow that?
I actually since a few weeks, have this working nicely in my trunk build. The keyword searches are stored in history, but marked as hidden, so they only show up in autocomplete and not in history searches. The only potential issue, is that the sorting algorithm in autocomplete doesn't take keyword searches into account. So if I write "wikipe" in the location bar, the result list might look like this: http://wikipedia.org - Welcome to Wikipedia.org wikipedia blue http://wikipediafoo.com - Wikipediafoo for all tastes! I.e., the keyword search looks a bit "off" in the middle of the regular URIs. If that is acceptable for now, we can check-in the patch, and file a new bug for the sorting. It will be easier to fix once the first patch for bug 340611 is in. I think keyword searches should be given a very high priority, and thus appear at the top of the autocomplete list when they match.
Does your in-progress patch handle the deletion issues I mentioned in comment 12?
(In reply to comment #14) > Does your in-progress patch handle the deletion issues I mentioned in comment > 12? Well, it does not work like you describe it - but since they have the same visited date as the resolved URI, they will all expire at the same time, yes.
But if they are hidden, they are impossible to delete manually, right? It's not necessarily a show-stopper, but it is a loss of functionality. The ability to selectively remove items that show up in autocomplete is something I use from time when I do something like accidently typo a host or typo a keyword and end up at some random host, and don't want that item there confusing me next time.
/me references bug 181716, since it's relevant to the conversation at this point.
Yeah, I don't know how to make history items associated with each other like that. We could file a bug about it, and keep it in mind while deCOMtaminating history, would that be alright? It might become easier with the time.
Implementing what froodian suggests would be a simple workaround.
That's certainly worth considering. But even if there's no good way to do it from the history back-end side, we could probably get the same effect by creating a reverse mapping that's updated every time a keyword is resolved and checked whenever a user manually deletes a history entry.
(In reply to comment #20) > That's certainly worth considering. > > But even if there's no good way to do it from the history back-end side, we > could probably get the same effect by creating a reverse mapping that's updated > every time a keyword is resolved and checked whenever a user manually deletes a > history entry. Yes, and it would have to be flushed to disk, but that's quite easy with plists and NSDictionary, like we do with the SiteIconCache. Preferably, there'd be some way to "tag" mork items, but it's Mork, so who knows... I would prefer if this went into another bug though, to keep things a bit simpler to fix/review.
Mass un-setting milestone per 1.6 roadmap. Filter on RemoveRedonkulousBuglist to remove bugspam. Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Summary: Memorize Keyword Searches in Location field Autocomplete menu → Memorize bookmark shortcut (keyword) searches in Location field Autocomplete menu
You need to log in before you can comment on or make changes to this bug.