Closed Bug 204706 Opened 20 years ago Closed 19 years ago

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

Categories

(Firefox :: Address Bar, enhancement)

x86
All
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: sneakums, Assigned: eric)

References

Details

(Whiteboard: fixed0.9)

Attachments

(1 file, 1 obsolete file)

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:
-> Phoenix (works in Mozilla)
Component: URL Bar → Autocomplete
Product: Browser → Phoenix
QA Contact: claudius → asa
Version: Trunk → unspecified
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Confirmed with Win32-Firebird v0.6 (Gecko/20030516).

Prog.
*** Bug 212883 has been marked as a duplicate of this bug. ***
*** Bug 213497 has been marked as a duplicate of this bug. ***
Taking QA. Sorry for the bugspam
QA Contact: asa → davidpjames
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 }

Does this still happen in today's builds?  The fix for bug 203754 should have
fixed this.
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?
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?
I can look at fixing that.
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).
Attachment #129636 - Flags: review?(hewitt)
Not sure about changing nsAutoCompleteControlle.  Brian, your thoughts?
Attachment #129636 - Flags: review?(hewitt) → review?(blake)
Flags: blocking0.8?
Comment on attachment 129636 [details] [diff] [review]
patch to help selection algorithm

Brian, can you take a look at this please?
Attachment #129636 - Flags: review?(blake) → review?(bryner)
Now that the current behavior has been around for a while, I quite like it.
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.
Attachment #129636 - Flags: review?(bryner) → review?(bugs)
enhancements aren't showstoppers, which is all there is time for at this stage
Flags: blocking0.8? → blocking0.8-
(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 on attachment 129636 [details] [diff] [review]
patch to help selection algorithm

r=ben@mozilla.org
Attachment #129636 - Flags: review?(bugs) → review+
(In reply to comment #19)
> (From update of attachment 129636 [details] [diff] [review])
> r=ben@mozilla.org
> 

do we need an sr? or does someone else need to review this?
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.
fixing bit-rot
Attachment #129636 - Attachment is obsolete: true
Attachment #146313 - Flags: review?(bugs)
Flags: blocking0.9?
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
Attachment #146313 - Flags: review?(bugs)
I'll check this in tomorrow with some other things

clearing blocker request, it'll make 0.9 anyway.

reassign to patch author.
Assignee: hewitt → eric
Flags: blocking0.9?
Whiteboard: checkin0.9
checked in on trunk 2004-04-25 12:53
checked in on 1.7 branch 2004-04-25 12:54

Thanks Eric!
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: checkin0.9 → fixed0.9
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.
You need to log in before you can comment on or make changes to this bug.