Closed Bug 208871 Opened 18 years ago Closed 15 years ago

Does not surf to history list item I clicked

Categories

(SeaMonkey :: Location Bar, defect)

defect
Not set
minor

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)

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
Attached patch just close the popup (obsolete) — Splinter Review
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)
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.
Attachment #205464 - Attachment is obsolete: true
Attachment #205525 - Flags: review?(jag)
Attachment #205464 - Flags: superreview?(jag)
Attachment #205464 - Flags: review?(jag)
Attached patch the right patchSplinter Review
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)
Blocks: 136687
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+
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.