188178 - Memorize bookmark shortcut (keyword) searches in Location field Autocomplete menu

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Location Bar & Autocomplete, enhancement)

Description

[Stephane Moureau]

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.

Comment 1

[Chris Casciano]

.

Comment 2

[Samuel Sidler (old account; do not CC)]

Ping. Thoughts?

Comment 3

[Ulrik Sverdrup]

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.

Comment 4

[Håkan Waara]

I think this is a dup of bug 188188 (since keywords are technically bookmarks).

Comment 5

[Håkan Waara]

Sorry, I mean bug 247837.

Comment 6

[Håkan Waara]

I should cut down on the tabs! bug 162450
/me goes for a walk

Comment 7

[Samuel Sidler (old account; do not CC)]

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.

Comment 8

[Håkan Waara]

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

Comment 9

[Håkan Waara]

Anyone interested in trying to fix this? I'd love to see it fixed. :)

Comment 10

[Håkan Waara]

Attachment: Sneak peek

Looky, looky...

Comment 11

[Håkan Waara]

Attachment: 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.

Comment 12

[Stuart Morgan]

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?

Comment 13

[Håkan Waara]

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.

Comment 14

[Stuart Morgan]

Does your in-progress patch handle the deletion issues I mentioned in comment 12?

Comment 15

[Håkan Waara]

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

Comment 16

[Stuart Morgan]

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.

Comment 17

[froodian (Ian Leue)]

/me references bug 181716, since it's relevant to the conversation at this point.

Comment 18

[Håkan Waara]

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.

Comment 19

[Håkan Waara]

Implementing what froodian suggests would be a simple workaround.

Comment 20

[Stuart Morgan]

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.

Comment 21

[Håkan Waara]

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

Comment 23

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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