GNOME Bugzilla – Bug 151932
Doesn't give URL suggestion based on substring
Last modified: 2008-08-14 22:53:17 UTC
Steps to reproduce: 1. Visit http://www.linux-mandrake.com/l10n/nl.php3 2. Open a new Epiphany window, Ctrl+L 3. Type 'l10n' in the location field Actual result: There are no suggestions in the dropdown completion list Expected result: The previously visited URL should be shown as a suggestion
Created attachment 31311 [details] [review] proposed fix
I also noticed we don't use the URL of bookmarks for autocompletion; IMHO we should.
Not quite sure about this one. How other browsers behave in this respect?
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Hmm, i really don't think this'll work well. Other browsers don't do this. Bascially this would mean that if you type "m" it would match all URLs with an "m" anywhere in it. You are far more likely to want those _starting_ with m. chpe, what's you opinion?
spark: your concern could be addressed by placing matches starting with the substring on top of the completion list, and only activate it for substrings of length >= 3. Other browsers don't do this, well Epiphany isn't really the kind of browser to base decicions on that argument. :)
targeting for 1.8
from IRC: (19:50:19) ska-fan: rank the "search results" and show the best matches first :) (19:50:59) chpe: the patch only implements the matching, not the sorting as in comment 6... also, any response to comment 2 ? (19:51:10) chpe: s/2/3 (19:52:00) ska-fan: Dunno about other browsers. I think ephy should search everywhere where there are reasonable chances to find the url the user wants. This includes bookmarks. (19:53:17) chpe: other autocompletions in gnome/gtk apps only complete from the start (typeaheadfind in treeviews, for example)... (19:54:03) ska-fan: is that about consistency? (19:54:12) ska-fan: I think that'd be taken too far here. (19:54:32) reinouts: chpe: firefox doesn't turn up the history entry "dnk.geodan.nl" if I just type "geodan" (19:55:10) reinouts: chpe: we have other needs than gtk autocomplete currently offers, see also the 'delete history item' issue (19:55:18) chpe: consistency, yes (19:55:38) chpe: reinouts: yeah (19:55:54) chpe: it's implementable at least,not like the delete thing (20:00:35) chpe: sorting the matches certainly addresses the issue in comment 5... I'm not opposed to it
*** Bug 311293 has been marked as a duplicate of this bug. ***
I'd think matches starting on word boundary should maybe get higher priority than matches in the middle of a word. So searching for 'list' might produce results something like: list apart epiphany-list unlisted
Now that Firefox 3 has this feature (as well as other address-bar auto-complete features), is it time to re-visit this bug?
Fixed, part of #517960.