Closed Bug 208871 Opened 18 years ago Closed 15 years ago
Does not surf to history list item I clicked
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030507 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b) Gecko/20030507 I typed "pers" in the URL bar. Mozilla produced the drop-down list of matching URL's from my history as I continued typing the URL. Through some typo or stray mouse click, I accidentally put my cursor at the beginning of the URL and continued typing there, such that it read "theonioperson...". The correct full URL, "http://personals.theonion.com/", was first on the drop-down list anyhow, so rather than Delete-key my typos, I clicked on that item. But Mozilla didn't go to that item; it tried to nslookup the garbage in the URL bar. Reproducible: Always Steps to Reproduce: 1. Type a partial URL that will produce at least one history-list match. 2. Put the cursor before the first character of the URL and type some jibberish. 3. Click on any match in the drop-down list. Actual Results: DNS lookup failed Expected Results: Mozilla should either update the drop-down list when new leading letters are typed in the URL bar or (my preference) keep the old matches and respond correctly when one of them is clicked.
Confirmed w/ 1.4rc3 on W2k
Confirmed on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050302
Status: UNCONFIRMED → NEW
Ever confirmed: true
Closing is the only reasonable thing to do in order to be consistent with the fact that we don't open the popup if you just start typing at the beginning of the URL bar. Internet search is still accessible by hitting DOWN. The reason for the quirky behavior is that onResultClick ignores any selected result if noMatches is false. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/components/autocomplete/resources/content/autocomplete.xml&rev=1.120&mark=774#774 I'm not sure if there's a good reason for that or not.
Hmm... So if I start typing "oog", notice no results and see the first g is missing, go to the beginning of what I typed and type a g, I would expect sites starting with "goog" to now show up in the results list. Currently it doesn't, and I suspect your patch doesn't do that either. What code do we need to make it seem at this point like we typed in "goog" in the first place?
Right. The biggest problem with invoking autocomplete when the cursor is not at the end is that "best-match-as-you-type" won't work. Other than that, I think it would probably work and would be more in line with what the user expects. We could turn that on if the user had best-match off or temporarily disable best-match while they're not typing at the end of the line.
OS: Windows NT → All
Hardware: PC → All
Even when autocomplete-best-match-as-you-type is on we should still be able to update the results list itself. We can leave the behaviour for ABMAYT as it currently stands, I think it actually works out: 1) If the user forgot or mistyped a few letters and there's no match, going to the front and adding them leaves you without ABMAYT (even if normally it would've autocompleted something), but then you can go to the end, add one more letter and you (hopefully) get what you wanted. 2) On the other hand, if what you (mis)typed matches something already, going to the front will leave what was autocompleted so far, and the user will learn to either hit backspace first or select the whole thing and start over. We could get fancy and keep track of whether the selection was from autocomplete and if it is and the user sets the cursor outside the selected text (but in the same "editor" of course) we automatically remove the selected text. Too fancy, I think. Let's first address the bug about the results list not reflecting what's in the url bar. Once we have a patch for that, let's play with ABMAYT to see what feels right.
I was playing around with composition and noticed that this bug is actually more noticable there. If you use the arrow keys to edit the address and then hit tab, it replaces whatever you had with the old best match (and of course this patch will make it not do that :)).
Comment on attachment 205534 [details] [diff] [review] the right patch >Index: autocomplete.xml >=================================================================== >@@ -1027,7 +1023,8 @@ > <parameter name="aResults"/> > <parameter name="aUseFirstMatchIfNoDefault"/> > <body><![CDATA[ >- if (this.mDefaultMatchFilled) return; >+ if (this.mInputElt.selectionEnd < this.currentSearchString.length || >+ this.mDefaultMatchFilled) return; Please move the return to the next line before checking in.
Attachment #205534 - Flags: review?(jag) → review+
Attachment #205534 - Flags: superreview?(neil.parkwaycc.co.uk)
Odd, left & right close the popup but home & end do not. Then there's emacs keys, such as Alt+A ;-)
Comment on attachment 205534 [details] [diff] [review] the right patch So basically this makes us autocomplete wherever the caret is (IE seems to do this too), but disables autofill unless the caret is at the end, right? I notice that navigator.js's URLBarClickHandler uses selectionStart rather than selectionEnd, I wonder if there's a good reason for that?
Attachment #205534 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
> Odd, left & right close the popup but home & end do not. yes, that is a bit odd. firefox closes it when hitting home & end. > So basically this makes us autocomplete wherever the caret is (IE seems to do > this too), but disables autofill unless the caret is at the end, right? yes > I notice that navigator.js's URLBarClickHandler uses selectionStart rather than > selectionEnd, I wonder if there's a good reason for that? It does so only after checking that selectioStart == selectionEnd (nothing is selected)
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #205534 - Flags: approval-branch-1.8.1?(neil)
Attachment #205534 - Flags: approval-branch-1.8.1?(neil) → approval-branch-1.8.1+
You need to log in before you can comment on or make changes to this bug.