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

NEW
Unassigned

Status

--
enhancement
16 years ago
7 years ago

People

(Reporter: stf, Unassigned)

Tracking

Details

(Whiteboard: [good first bug])

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Updated

16 years ago
Severity: normal → enhancement
Target Milestone: --- → Camino1.1

Comment 1

15 years ago
.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ping. Thoughts?

Comment 3

14 years ago
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

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

Comment 5

13 years ago
Sorry, I mean bug 247837.

Comment 6

13 years ago
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.

Updated

13 years ago
Summary: Memorize Keyword-URLs in Location field Autocomplete menu → Memorize Keyword Searches in Location field Autocomplete menu

Comment 8

12 years ago
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

Comment 9

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

Comment 10

12 years ago
Created attachment 237552 [details]
Sneak peek

Looky, looky...

Comment 11

12 years ago
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.

Comment 12

12 years ago
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

12 years ago
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

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

Comment 15

12 years ago
(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

12 years ago
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

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

Comment 18

12 years ago
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

12 years ago
Implementing what froodian suggests would be a simple workaround.

Comment 20

12 years ago
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

12 years ago
(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.

Updated

12 years ago
Duplicate of this bug: 375269
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.