204706 - the cursor should remain at the end of the text field when arrowing down through completions

Status: RESOLVED FIXED

(Firefox :: Address Bar, enhancement)

Description

[Sean Neakums]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030505 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030505 Mozilla Firebird/0.6

When a completion has been selected by arrowing down to it, the cursor is placed
at the beginning of the URL bar's text field.  This means that the user either
must hit End or click at the end of the URL bar to either type more text in
order to narrow down the possible completions or go to a URL based upon the
selected completion.

The URL Bar in the pre-Firebid Mozilla browser used to work in this fashion, so
this may be considered a regression, but filing as enhancement.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Matthias Versen [:Matti]]

-> Phoenix (works in Mozilla)

Comment 2

[Erik]

Didn't find a previously filed bug for this 

=> confirming and setting OS = "All" as I see this also on Windows builds

btw: this impacts also form autocomplete, not only URL autocomplete

Comment 3

[Prognathous]

Confirmed with Win32-Firebird v0.6 (Gecko/20030516).

Prog.

Comment 4

[Jesse Ruderman]

*** Bug 212883 has been marked as a duplicate of this bug. ***

Comment 5

[Jesse Ruderman]

*** Bug 213497 has been marked as a duplicate of this bug. ***

Comment 6

[David P James]

Taking QA. Sorry for the bugspam

Comment 7

[John Levon]

Can somebody give some hints of where the fix might be ? I've been
looking around in toolkit/components/autocomplete/ and friends.

I think I know the points where we need to set the cursor (at certain
points where we do mInput->SetTextValue() in nsAutoCompletelController.cpp)
but I have no idea at all how I might call code to set the cursor position.

I can't even locate where SetTextValue might do anything at all :

    354 NS_IMETHODIMP nsAutoCompleteInput::SetTextValue(const nsAString &
aTextValue)
    355 {
    356     return NS_ERROR_NOT_IMPLEMENTED;
    357 }

Comment 8

[:deanis74]

Does this still happen in today's builds?  The fix for bug 203754 should have
fixed this.

Comment 9

[Erik]

Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030808
Mozilla Firebird/0.6.1+ the "autocompleted" part of the URI stays selected.
As a concequence the selected part gets deleted if the user starts entering text
without hitting the right arrow key to de-select the autocompleted part. 

I just compared with an old version of SeaMonkey and also IE 5.5: in both
browsers  ther the autocompleted part stays NOT selected after selecting an
entry from the list - hence the user can go on entering text without hitting
right arrow key. => What is the intended behaviour?

Comment 10

[:deanis74]

I agree with comment 9.  That's how IE, which I'm forced to use because I'm at 
my parents', works.

Eric, your fix for bug 203754 led to the behavior in comment 9.  Can you do up 
a new patch that still fixes that bug but also give us the behavior in the 
previous comment?

Comment 11

[eric lindvall]

I can look at fixing that.

Comment 12

[eric lindvall]

Attachment: patch to help selection algorithm

This should fix the selection algorithm such that when you use the arrow keys
to choose a URL, it puts the cursor at the end of the line, and if
"CompleteDefaultIndex" is enabled, it does select the rest of the line. (see
bug 203756 for a patch that allows for enabling this behavior).

Comment 13

[:deanis74]

Not sure about changing nsAutoCompleteControlle.  Brian, your thoughts?

Comment 14

[Mike Connor [:mconnor]]

Comment on attachment 129636 [details] [diff] [review]
patch to help selection algorithm

Brian, can you take a look at this please?

Comment 15

[:deanis74]

Now that the current behavior has been around for a while, I quite like it.

Comment 16

[Brian Ryner (not reading)]

Comment on attachment 129636 [details] [diff] [review]
patch to help selection algorithm

handing off review request to ben... he's considering which behavior he wants
to have here.

Comment 17

[Mike Connor [:mconnor]]

enhancements aren't showstoppers, which is all there is time for at this stage

Comment 18

[Prognathous]

(In reply to comment #16)
> (From update of attachment 129636 [details] [diff] [review])
> handing off review request to ben... he's considering which behavior he wants
> to have here.

Was any decision taken? does the patch need to be updated for Firefox?

Prog.

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 129636 [details] [diff] [review]
patch to help selection algorithm

r=[e-mail]

Comment 20

[eric lindvall]

(In reply to comment #19)
> (From update of attachment 129636 [details] [diff] [review])
> r=[e-mail]
> 

do we need an sr? or does someone else need to review this?

Comment 21

[Robert Parenton]

r=ben is good enough for Firefox.  You just need to find someone to check it in
if you don't have CVS access.  You can probably find someone on IRC willing to
do it, especially since it looks like a fairly simple patch.

Comment 22

[eric lindvall]

Attachment: Re-implementation of patch

fixing bit-rot

Comment 23

[Mike Connor [:mconnor]]

Comment on attachment 146313 [details] [diff] [review]
Re-implementation of patch

this doesn't need re-review, the difference is trivial

carrying over r=ben is fine

Comment 24

[Mike Connor [:mconnor]]

I'll check this in tomorrow with some other things

clearing blocker request, it'll make 0.9 anyway.

reassign to patch author.

Comment 25

[Mike Connor [:mconnor]]

checked in on trunk 2004-04-25 12:53
checked in on 1.7 branch 2004-04-25 12:54

Thanks Eric!

Comment 26

[Prognathous]

Thanks a lot!

Mconnor, can you also help get Eric's patch for Bug 203756 into v0.9? these two
autocomplete bugs are among the most obvious advantages Seamonkey still has over
Firefox, but now that one is fixed and the other has a patch pending review,
this can change.

Prog.