Closed Bug 51910 Opened 24 years ago Closed 24 years ago

Urlbar autocomplete to provide better results

Categories

(SeaMonkey :: Location Bar, defect, P3)

Product:
SeaMonkey
Component:
Location Bar
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 40305
Milestone:
mozilla0.9.1

People

(Reporter: BenB, Assigned: alecf)

References

Details

Attachments

(2 files)

patch that enables turning off autocomplete in the textbox
562 bytes, patch
Details | Diff | Splinter Review
patch for navigator.xul that turns off autocomplete in textbox for the urlbar
55 bytes, patch
Details | Diff | Splinter Review
Reproduce: 1. Type "http://home.netscape.com/sidebar" into the URLbar and hit enter to load. 2. Clear the URLbar 3. Type "http://home.netscape.com" into the URLbar and hit enter to load. Actual result: "http://home.netscape.com" is completed to "http://home.netscape.com/sidebar", and the latter loads. Expected result: On enter, accept what I typed. Relevance: You can't expect me to check, if autocomplete happened to do some fancy recognition (and autocomplete does fancy recognition) before I hit enter. I am so fast with hitting enter that I only realize that something went wrong, when the URL loaded halfly. This completely breaks the oldest patterns of computing: Type in data and hit enter to process it. This is dogfood, or at the very least nsbeta3. Additional Comments: The behaviour is OK (for me) for Mailnews, but not for the browser, where you can cut a right part of an URL and still (usually) get a valid URL. Bug 40643 is related.
Keywords: dogfood, nsbeta3
should not to be to hard to fix that!
Status: NEW → ASSIGNED
Target Milestone: --- → M18
QA Contact: sairuh → claudius
Summary: Autocomplete on enter → Autocomplete on enter (eg, in urlbar)
Remark: 4.x does the same but as it doesn't have a 300 ms second delay like Mozilla, it's almost imposible to hit the problem.
I tried this on 4.x WinNT, and saw that completion only went up to, but did not include, the next possible slash. As a result, on 4.x, it would not have completed into the path portion ("/sidebar" in the above example) until after you typed the slash. On Windows Nav 6 *does* complete beyond the slash :-(. I'm confused by the comment above that says this is the same as in 4.x (except for the delay of "300ms"), so I'm curious if this is platform specific? Is the real bug that the completion goes beyond a slash? The fact that autocomplete is "helpful" requires care when entering URLs. This is a fact of the feature, and can't be considered a reason to not use the product. Putting on dogfood-minus. If this is the same as 4.x, then you would have the same objection in 4.x thet "entering data and return doesn't do what you'd expect". In fact, with less delay in 4.x, it is harder to get what you want by hitting return right away. As I said, this is a "feature" with all its ups and downs. IMO, the performing of autocomplete *beyond* the slash is probably a bug in the implementation that should be fixed, but probably wouldn't be dogfood. If you're willing to morph this bug into "autocomplete in URL goes to end of path, including slash" then that would at least make it close to the P3 level (polish) for beta3.
Whiteboard: [dogfood-]
> This is a fact of the feature Then remove the feature. I must be able to enter URLs as before (and as I enter text in almost every other field), without being interfered by an over-eager autocomplete which guessed wrong. I can see that you don't think, this is dogfood. Anyway, it is very annoying. As for 4xp: Autocomplete doesn't seem to work at all on 4.x Unix. Re "up to slash": I disagree. If I hit enter, do just what I said, please. Imagine having a machine on the local net called "www", or "search", or whatever some other, external webserver happens to use, too.
Radha is almost ready to checkin a pref that let you disable autocomplete. Therefore if you thing it's more anoying than helpfull, just turn it off.
ducarroz, no, not at all. I need autocomplete for Mailnews. But if I have the choice between this bug and no autocomplete in the browser at all, I'd chosse the latter all day. I said this, because jar suggested, this bug were inherently connected to the feature, but I doubt it.
the new pref will be only for the browser URL bar, mailnews has its own pref already
ah, good, then this is no dogfood at all for me. I still think, it has to be fixed for N6, because I think, this is very irritating. It took me some time to figure out why exactly things fail.
I'm also working on this. I'm also working on giving the urlbar some other features, like bug 37867. Don't know if I should make a new widget that inherits the current autocomplete.xml and adds my new features of specialcase them in the current widget.
The autocomplete Widget is generic as most as posible, it doesn't have any specific notion of email address or URL. As long you keept this in mind, you can extend the current widget, else deve it and do a you one. Typically adding an attribute to force to autocomplete on return/enter would be ok.
I don't see any recommended action for beta3, nsbeta3-.
Whiteboard: [dogfood-] → [dogfood-][nsbeta3-]
selmer: there is a recommended action: I the user just types (no tab or up/down etc.) and then hits ENTER, load the URL as-is, do no autocompletion. Requesting reevaluation. Relevance: (In addition to the inital description.) I was very confused about this. Normal users are very likely to run into this bug. And it is easy to fix (said ducarroz). So, please just fix it the way I proposed (it is less harmful and easier to implement than jar's suggestion), for nsbeta3.
Whiteboard: [dogfood-][nsbeta3-] → [dogfood-]
Yup, I was going to file this myself. Auto-complete -- like e-mail marketing -- should be something you have to opt in to on any given occasion (using the Down arrow key to start going through the auto-complete menu). It should not be something you have to opt out of (by waiting, then pressing Backspace). Otherwise it will inevitably interfere with what you are trying to type. This is one example of the problem I often had using 4.x. 1. Clear your history, so that http://mozilla.org/ is not in it. 2. Enter the address `http://mozillazine.org/' in the location field, and visit it. 2. Start to enter the address `http://mozilla.org/', but type `http://mozillaz' by mistake (muscle memory from visiting mozillaZine). 3. Press Backspace to delete the `z', and type `.org/'. 4. Look at the location field. Instead of reading `http://mozilla.org/', it reads `http://mozillaz.org/'. Because a millisecond before you pressed Backspace to delete the `z', it auto-completed to `http://mozillazine.org/', with the `ine.org/' selected. So the Backspace deleted the `ine.org/' instead of the `z'. 5. Press Backspace six times, to delete up to and including the `z'. 6. Type `.org/'. 7. Repeat steps (4) through (6) a few times, until you realize what is going on. 8. Get really really angry. Auto-complete should *not* `require care when entering URLs'. It should be a help, not a hindrance. You shouldn't have to hover your finger over the Return key, waiting to make sure that Mozilla is not going to deviously auto-complete what you have typed a millisecond before you hit Return. So: offer an auto-complete menu by all means (for navigation with the Up and Down keys), but don't ever touch the contents of the text field itself.
That was a very interesting comment about autocomplete, and how the backwards-delete key (re: delete backwards one charater, a.k.a., left-backarrow-delete) doesn't *quite* do what you want. (i.e., it doesn't delete the character that you just typed :-( ) Not being a UI expert, I would argue that while an autocomplete zone is highlighted, the backwards-delete should actually get rid of the highlighted (autocomplete region) *as-well-as* the last character that you typed. That would be the only way that the autocomplete could act rather transparently. Sadly, the performance of a "backwards delete" when a section of a line is highlighted is *usually* delete only the highlighted section (which strangely enough is the same as the solo "delete" key!). I would argue that these two distinct delete keys should have different semantics, as the have quite different semantics when there is just a cursor (re: delete character to the left of cursor, vs delete character to the right of the cursor). Having them act differently would give me a *chance* to give you the tranparent completion that you were asking for :-). Hence the "hack" solution would be for the backwards-delete to have "special semantics" when autocomplete was active. The consistent solution would be for a backwards delete to *always* delete the highlighted region, and the character to the left of the region. In contrast, the solo-delete key would continue to only delete the highlighted region. I guess it is up to the UI wizards to explain why such sementics on the keystrokes would be evil... but it sure seems like it would cure the problem just cited. Jim p.s., None of this IMO should make it into Nav 6 at this late date... but this is an interesting issue.... and there will be future mozilla and Nav release ;-). p.p.s., This bug is IMO really about the fact that Nav 6 autocompletes too far (re: past the slash), but I wanted to chime in given the comment above.
> Hence the "hack" solution would be for the backwards-delete to have "special > semantics" when autocomplete was active. The consistent solution would be for > a backwards delete to *always* delete the highlighted region, and the character > to the left of the region. In contrast, the solo-delete key would continue to > only delete the highlighted region. Nup. In no application I have ever used do the Backspace and Delete keys perform different actions on a selection. And to delete something *other* than the selection (i.e. the selection plus one character), when I press Backspace, would be misleading in the extreme. Navigator 4.x (and IE 4, IIRC) made the mistake of thinking that you can offer auto-complete by placing selected text in the text field, without causing errors. You can't. IE 5 has fixed this mistake, by using only an auto-complete menu, on both Windows <http://microsoft.com/windows/ie/images/screenshot/intellSCR.gif> and Mac OS <http://microsoft.com/Mac/products/IE/5/images/IE5features/ address4.jpg>. Mozilla, however, has perpetuated 4.x's mistake. The proper way to fix this would be even easier than the suggested `"hack" solution'. Just get rid of the code which auto-completes by putting selected text in the text field, leaving behind the code that auto-completes by offering a menu of options. That shouldn't be too hard, surely.
hmm... but in no other application have I ever seen hitting a single key cause both: a) The character to appear b) An optional selection (the autocomplete) to appear This was IMO a bit of a hack, as it established a configuration where an additional keystroke would then replace the highlighted region (I always thought it was cute... but a hack). Sadly, as pointed out, it created a situation where hitting the backward-delete would not "undo" the action of typing (oops). Your answer is to get rid of the first hack (create a menu)... I was just wondering if geting in deeper would be better.
Getting in deeper how? I can't think of a better solution than the one IE uses. (Believe me, I've tried.) Even having an auto-complete menu interferes with Mac users' expectations slightly (the Up/Down keys no longer go to the beginning/end of the field); but that is definitely a lesser evil than altering the text the user has typed.
I agree with Matthew. I think we should just skip doing anything in the actual textbox and just provide the dropdown. Think there are far more cases where autocomplete does the wrong thing then it actually saves that extra downarrow press it takes to get to the samething as is autocompleted today. I have a fix that will remove autocompleteing in the url-textbox and just provide the dropdown
Then take the bug, attach the patch, get review etc., considering that a fix by Netscape is unsure. (I'm not sure, if I like your proposal, but) It would be better than the current state.
Using today's commercial build (2000-09-21-11 on WinNT4), autocomplete is not working at all for me. Not sure if it's related, but the history drop down from the URL bar is not collecting my history either. As it stands, this is really serious.
Sol, are you using modern theme? if yes try classic, it propably bug 52457
JF - thank you - you are correct. I was using "Modern" and hitting bug 52457.
attached two patches diffs (for autocomplete.xml resp. navigator.xul) that turns off autocomplete in the textbox and only shows the dropdown. the patches are for autocomplete.xml v1.19 resp. navigator.xul v1.243. Sorry for not supplying better patchfiles but I don't have a complete build environment...
Keywords: patch
Not sure what this patch does. But preference to enable/disable autocompletion in urlbar is already done. Prefs--> Smart browing panel already has UI for it and it works.
The original problem here is to not force the autocompletion when the user press enter. How come do we arrive to a solution that totally remove autocompletion in the URL bar!!! Please file another bug if you want to continue on the second matter. BTW, the autocomplete widget has already the capability to just display a drop down list without altering the user input. Message Compose does that when you don't have an exact match. The Search engine just have to return a defaultItemIndex set to -1. You don't need to patch the autocomplete widget!
My patch solves three problems. 1. It enables doing autocomplete by just showing the drowdown. I guess this could be done by patching the searchengine, but it seems a bit wrong to me that the searchengine should decide how the serachresault should be shown. Also you would have to patch every searchengine. 2. It enables autocomplete when the cursor is not at the end of the end of the entered string if autocomplete is turned off in the textbox. Disabling the autocomplete entierly is not what most people have asked for (that I have heard at least) but rather to do it in just the dropdown. I'd be glad to hook this up with a pref if somebody shows me how to connect the pref with some js-code that sets a attribute in the navigator crome.
Jonas, the autocomplete search engin is in charge of building the result list, this include the dropdown elements as well as the autocompletion text that is append to the user input. It's not the role of the widget to decide yes or not if we can alter the input. You don't need to patch every search engine but only the urlbar history one. Also, if the user is not editing at the end of the textfield, we don't want any kind of autocompletion. But again, this discussion has nothing to do with this bug, please file a new one. This bug is about not forcing the autocompletion on enter.
IMHO the role of the searchengine is to do the searching and the role of the widget is to allow the user to select from the resault of that serach. As it currently is it is the widget that builds the dropdown and the widget that modifyes the textbox. This bug is about the widget changing the value of the textbox before the user presses enter and thus sending him to wrong url. My patch fixes this and thus this bug. It also rebuilds the dropdown when the user modifyes the url when the cursor is not at the end of the text. This is a good thing since it will not affect the cursorposition or the text in the textbox, only the dropdown. Please try it out.
Not holding beta3 for this, nom for rtm.
Keywords: rtm
Priority: P3 → P2
Whiteboard: [dogfood-] → [dogfood-][nsbeta3-]
rtm+ to fix the hitting enter problem. Turning off autocomplete with a pref and other such stuff is not plus (and belongs in a different bug.)
Whiteboard: [dogfood-][nsbeta3-] → [dogfood-][nsbeta3-][rtm+]
After analyzing the problem deeply and read carefully all the comments about it, here is what we should do: a) the real problem is not that we autocomplete on return, in fact the autocomplete is fire before while typing first characters. But because we should stop the completion to the first slash in the result like does 4.x and IE5.5b2 Mac (and like said jar@netscape.com). here is how it should work: 1) Clear your Location bar History (Edit/Preferences/Navigator/History) 2) visit "www.netscape.com/sidebar" 3) type "www.net" you get ([] represent the selected text): url= www.net[scape.com/] menu=[www.netscape.com/] www.netscape.com/sidebar 4) At this point, if you press return, you will go to the page www.netscape.com 5) don't press return but press the Right Arrow key 6) press "s" you get: url=www.netscape.com/s[sidebar] menu=none Therefore, it's not a Autocomplete Widget problem but rather a Location History search issue which should return the right result. b) another problem found is about the way delete works. Actually, every time you press the delete key, autocompletion is fired and the user input will be altered. What we should do (and what does IE5.5b2 Mac), it's to only propose an updated dropdown list but not changing the user input like we would do normally when you enter characters. This should be the case for Url autocompletion as well for email address autocompletion. This should be fixed in the widget itself.
here is the fix for the delete problem (it also fix some JS Strict warnings): Index: resources/content/autocomplete.xml =================================================================== RCS file: /cvsroot/mozilla/xpfe/components/autocomplete/resources/content/autocomplete.xml ,v retrieving revision 1.19 diff -u -r1.19 autocomplete.xml --- autocomplete.xml 2000/09/15 06:37:33 1.19 +++ autocomplete.xml 2000/09/27 00:40:47 @@ -77,6 +77,10 @@ ]]> </property> + <property name="lastKeyPressed"> <![CDATA[ 0; ]]> </property> + <property name="noDirectMatch"> <![CDATA[ 0; ]]> </property> + <property name="menuOpen"> <![CDATA[ 0; ]]> </property> + <property name="autoCompleteListener"> <![CDATA[ ({ @@ -99,6 +103,10 @@ if (result.defaultItemIndex > result.items.Count()) result.defaultItemIndex = 0; + /* Do not alter the user input when deleting characters */ + if (me.lastKeyPressed == 8 /*vk_back*/ || me.lastKeyPressed == 46 /*vk_delete*/) + result.defaultItemIndex = -1; + var inputElement = document.getAnonymousNodes(me)[0].firstChild; //Time to build the new edit field value @@ -329,6 +337,7 @@ return; me.privatefunc.closePopupMenu(me); + me.lastKeyPressed = 0; if (me.disableAutocomplete == "true") return; @@ -353,6 +362,7 @@ if (popup && me.menuOpen != "true") popup = null; + me.lastKeyPressed = event.keyCode; switch (event.keyCode) { case 9: /*vk_tab*/
ducarroz, b) I agree. This is bad. It also happens for backspace, not only delete. a) Your proposal does not produce the expected result as stated in the initial description. Although I'm not sure that this is right, I think, I can live with it, *because* there is UI to disable it and because it is not overly agressive anymore. It would still be nice to be able to have the "suggestions" dropdown without the autocompletion in the textfield itself.
I think the best thing to do is to only have the dropdown and never touch the content of the textbox. Ducarroz suggestion is defenately better then the current one, but there would still leave many problems: 1. Backspace would still not fuction properly. There is no logical bahaviour here because if the user has noticed that the autocomplete has fired and sees the selected text he/she would expect ONLY the deleted text to dissapear when pressing backspace (as every other application does). If he/she hasn't noticed the autocompleted text then he/she would expect the backspace to delete the just entered letter. 2. Sometimes the autocomplete would still guess wrong. Say I want to visit "www.somesite.com/hello" after having visited "www.somesite.com/helloworld". Then the autocomplete would still send me to the wrong adress. Ok I guess this is a rare case... 3. Generally messing with what I type is a BadThing unless it guesses exacly right 4. The suggestion that is now entered into the textbox is always easyly availible, just press "down enter" instead of just enter. Although I agree that Ducarroz suggestion has me almost convinced...
replace "deleted" with "selected" in point 1. sorry
And remember, you can always come back to your original typing by pressing the Up arrow key.
Maybe we could add a tooltip telling users that as soon as they start typing? ;)
I opened bug 54396 about the backspace/delete problem. Please use now this bug only for the point a). Reassign to radha as now it's only a History search engin matter.
Assignee: ducarroz → radha
Status: ASSIGNED → NEW
Resummarising
Summary: Autocomplete on enter (eg, in urlbar) → Urlbar autocomplete to provide better results
nav triage team: Don needs a beer and can not understand what the fix means. Could you explain the behavior after you check in this patch? [RTM NEED INFO]
Whiteboard: [dogfood-][nsbeta3-][rtm+] → [dogfood-][nsbeta3-][RTM NEED INFO]
It's getting to late to fix this for N6 RTM. Especially since we don't have consensus. Minus.
Whiteboard: [dogfood-][nsbeta3-][RTM NEED INFO] → [dogfood-][nsbeta3-][rtm-]
ducarroz, do we have code for completing until the next slash only? I think, we all agree that this would be better than the current state.
No, I don't have code.
Then please check in my patch. It turns off all autocompleating in the textbox and only the dropdown is shown. That is much more userfriendly then the current behaviour.
sorry but your patch is not the solution either! The real fix should go into the urlbar history and not into the autocomplete widget.
It might not be the best solution, but it's better for RTM then the current behaviour.
*** Bug 61415 has been marked as a duplicate of this bug. ***
I'd really like to try these patches out. I don't see which files to apply the first one to. and advice? (using 2000112208 on linux)
Patch attached to bug 60678 also fixes this bug ie., if you have http://www.mozilla.org/feedback.html in your urlbar History and you type http://www.mo, you will get 2 results http://www.mo[zilla.org] (inside brackets automatically autocompleted and provided as first result) http://www.mozilla.org/feedback.html
nav triage team: Ok, we should at least look into this, especially if, as Radha says, there's a ptach that can fix this. Marking nsbeta1, p3, mozilla0.9.1, reassigning to alecf
Assignee: radha → alecf
Keywords: nsbeta1
Priority: P2 → P3
Target Milestone: M18 → mozilla0.9.1
IMO, autocomplete directly in the urlbar (not the dropdown for the urlbar) just sucks and should be off by default. But I guess, I'm in the minority. How about an option to disable the completion only, but not the dropdown? The UI pref disables the dropdown, too, which is not very useful for me. Should I file a bug about that?
Keywords: mozilla0.9
Ben I am not sure what you're asking here? I am generally not happy about making the prefs even more complex than they already are...
I am asking to - replace the existing pref UI to disable both autocomplete and the dropdown with a pref to en-/disable the autocomplete (directly within the textfield) only - resolve this bug by disabling autocomplete in the urlbar by default
I think what ben is saying is that mozilla needs the equivilent to IE's "use inline autocomplete" pref. If I understand him correctly, I'm with Ben: I don't at all like the fact that autocomplete changes what I type. I guess it boils down to 3 seperate autocomplete behaviours: "when I type in the url bar:" - do nothing - autocomplete inline (current mozilla default behaviour) - just show the dropdown with possible matches (IE's default behaviour)
I don't know MSIE, but I think, you got me right. It seems like I'm proposing to copy MSIE's behaviour. While some people might not like the dropdown, I cannot find a good reason and don't think, this is worth a pref. So, the first case you mention would be only reachable via a (possible) hidden pref.
s/worth a pref/pref ui/
Status: NEW → ASSIGNED
Keywords: dogfood, nsbeta3, rtm
Whiteboard: [dogfood-][nsbeta3-][rtm-]
Target Milestone: mozilla0.9.1 → mozilla0.8
moving the milestone later.
Target Milestone: mozilla0.8 → mozilla0.9.1
Component: XP Apps → History: URLBar
OK, after reading all these comments, there seems to be lots of reasons for not altering the user's text, and using just the dropdown. I cannot see a single reason for using both the dropdown and altering the users text. It seems that because this is the current behaviour some people are unwilling to remove it. I also have 2 other points in favor of not changing the text the user has typed: 1) IE doesn't does it this way. If we cannot have a better implementation that IE, then we should act in the same way to avoid confusion when switching between browsers. 2) The browser can never perfectly predict where you want to go, so you will want to check any results that have been put into the url bar. A good way of doing this is to use the arrows from the dropdown menu. Assuming the user has two pages in their history: http://www.netscape.com (no end slash) http://www.netscape.com/sidebar User types www.nets => User gets DNS error User types www.nets [down] => User goes to www.netscape.com User types www.netscape.com/ => User goes to www.netscape.com. In the current implementation, this would auto-complete to www.netscape.com/sidebar, since that is the only item that matches in the history. User types www.netscape.com/s => User gets 404 error. User types www.netscape.com/s [down] => User goes to www.netscape.com/sidebar This is also the view that mpt and Ben B support.
*** This bug has been marked as a duplicate of 40305 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
verifying
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: