Closed
Bug 208871
Opened 21 years ago
Closed 18 years ago
Does not surf to history list item I clicked
Categories
(SeaMonkey :: Location Bar, defect)
SeaMonkey
Location Bar
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: spiro.multimax, Assigned: ajschult784)
References
Details
(Keywords: fixed-seamonkey1.1a, fixed1.8.1)
Attachments
(1 file, 2 obsolete files)
1.34 KB,
patch
|
jag+mozilla
:
review+
neil
:
superreview+
neil
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
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.
Comment 1•21 years ago
|
||
Confirmed w/ 1.4rc3 on W2k
Comment 2•19 years ago
|
||
Confirmed on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050302
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 3•18 years ago
|
||
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.
Assignee: hewitt → ajschult
Status: NEW → ASSIGNED
Attachment #205464 -
Flags: superreview?(jag)
Attachment #205464 -
Flags: review?(jag)
Comment 4•18 years ago
|
||
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?
Assignee | ||
Comment 5•18 years ago
|
||
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
Comment 6•18 years ago
|
||
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.
Assignee | ||
Comment 7•18 years ago
|
||
Attachment #205464 -
Attachment is obsolete: true
Attachment #205525 -
Flags: review?(jag)
Attachment #205464 -
Flags: superreview?(jag)
Attachment #205464 -
Flags: review?(jag)
Assignee | ||
Comment 8•18 years ago
|
||
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 :)).
Attachment #205525 -
Attachment is obsolete: true
Attachment #205534 -
Flags: review?(jag)
Attachment #205525 -
Flags: review?(jag)
Comment 9•18 years ago
|
||
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+
Assignee | ||
Updated•18 years ago
|
Attachment #205534 -
Flags: superreview?(neil.parkwaycc.co.uk)
Comment 10•18 years ago
|
||
Odd, left & right close the popup but home & end do not. Then there's emacs keys, such as Alt+A ;-)
Comment 11•18 years ago
|
||
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+
Assignee | ||
Comment 12•18 years ago
|
||
> 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: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•18 years ago
|
Attachment #205534 -
Flags: approval-branch-1.8.1?(neil)
Updated•18 years ago
|
Attachment #205534 -
Flags: approval-branch-1.8.1?(neil) → approval-branch-1.8.1+
Assignee | ||
Updated•18 years ago
|
Keywords: fixed-seamonkey1.1a,
fixed1.8.1
Updated•15 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•