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

RESOLVED FIXED

Status

()

--
enhancement
RESOLVED FIXED
16 years ago
13 years ago

People

(Reporter: sneakums, Assigned: eric)

Tracking

unspecified
x86
All
Points:
---
Bug Flags:
blocking0.8 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed0.9)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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

Comment 2

16 years ago
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

Comment 3

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

Prog.

Comment 4

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

Comment 5

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

Comment 6

15 years ago
Taking QA. Sorry for the bugspam
QA Contact: asa → davidpjames

Comment 7

15 years ago
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

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

Comment 9

15 years ago
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

15 years ago
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?
(Assignee)

Comment 11

15 years ago
I can look at fixing that.
(Assignee)

Comment 12

15 years ago
Created attachment 129636 [details] [diff] [review]
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).
(Assignee)

Updated

15 years ago
Attachment #129636 - Flags: review?(hewitt)

Comment 13

15 years ago
Not sure about changing nsAutoCompleteControlle.  Brian, your thoughts?
(Assignee)

Updated

15 years ago
Attachment #129636 - Flags: review?(hewitt) → review?(blake)

Updated

15 years ago
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)

Comment 15

15 years ago
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-

Comment 18

15 years ago
(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+
(Assignee)

Comment 20

15 years ago
(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?

Comment 21

15 years ago
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.
(Assignee)

Comment 22

15 years ago
Created attachment 146313 [details] [diff] [review]
Re-implementation of patch

fixing bit-rot
Attachment #129636 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #146313 - Flags: review?(bugs)

Updated

15 years ago
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
Last Resolved: 15 years ago
Resolution: --- → FIXED
Whiteboard: checkin0.9 → fixed0.9

Comment 26

15 years ago
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.