Closed Bug 283777 Opened 20 years ago Closed 19 years ago

Right arrow key after selecting autocomplete result no longer uses selected item


(Firefox :: Address Bar, defect)

Windows XP
Not set





(Reporter: asa, Assigned: dveditz)



(Keywords: fixed-aviary1.0.5, regression)


(1 file, 1 obsolete file)

In html forms we used to be able to select an auto-complete item and hit the
right arrow and it would fill that item placing the caret at the end of that
word. Now hitting the right arrow dismisses autocomplete. IE's right arrow on
autocomplete does nothing. We used to be better and now we're either similar or
worse. It would be good to get this back to being better. Tested with 1.0.1 on
windows XP
For the record, this worked in 1.0.
This is fallout from bug 270697, I assume.
dveditz, do you want to take this?  Ben can certainly fix it, but you were last
to touch and may be best assignee.  Bryner would help too, I bet.

Keywords: regression
Summary: autocomplete regressed → Right arrow key after selecting autocomplete result no longer uses selected item
Attached patch restore old right-arrow behavior (obsolete) — Splinter Review
In the spirit of sheer nitpickiness the right-arrow is doing what it has always
done: close the popup and nothing more. The text was already filled in because
selecting an item did it.

This patch restores right-arrow functionality. left-arrow functionality is one
character different: in the past the caret would be one character before the
end, this patch puts it at the end like right-arrow instead. If left-arrow had
done something useful like put the caret at the beginning it might have been
worth trying to preserve, but for one character I think this is OK.
Assignee: bugs → dveditz
Attachment #175688 - Flags: superreview?(bryner)
Attachment #175688 - Flags: review?(
Comment on attachment 175688 [details] [diff] [review]
restore old right-arrow behavior

Neil isn't a toolkit peer, and toolkit doesn't require SR.

One thought, is handleEnter really the right name still, now that we're not
just calling it on when pressing Enter?
Attachment #175688 - Flags: superreview?(bryner)
Attachment #175688 - Flags: review?(
Attachment #175688 - Flags: review+
*** Bug 284985 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.3?
Attachment #175688 - Flags: approval-aviary1.1a?
Attachment #175688 - Flags: approval-aviary1.0.3?
Comment on attachment 175688 [details] [diff] [review]
restore old right-arrow behavior

a=chase approved for landing on the trunk
Attachment #175688 - Flags: approval-aviary1.1a? → approval-aviary1.1a+
Comment on attachment 175688 [details] [diff] [review]
restore old right-arrow behavior

approval-aviary1.0.3-, nominating for approval-aviary1.0.4
Attachment #175688 - Flags: approval-aviary1.0.4?
Attachment #175688 - Flags: approval-aviary1.0.3?
Attachment #175688 - Flags: approval-aviary1.0.3-
checked in to trunk
Closed: 19 years ago
Flags: blocking-aviary1.0.4?
Flags: blocking-aviary1.0.3?
Flags: blocking-aviary1.0.3-
Resolution: --- → FIXED
Flags: blocking-aviary1.1?
(In reply to comment #9)
> checked in to trunk
could this have caused bug 290172 ?

HandleEnter is no good because in the location bar or search bar, Enter causes
the browser to immediately begin loading a new page.  This is bug 290172. 
Attachment 180740 [details] [diff] to that bug is a reimplementation of the fix for this bug. 
The only difference compared to the committed patch (attachment 175688 [details] [diff] [review]) is that
the left arrow moves the insertion point to one character before the end.  See
comment 4.  I experimented with having the left arrow key move the insertion
point to the beginning of the string, but I didn't like that in cases where
completeselectedindex is set.

This patch approximates the behavior of Firefox 1.0 as nearly as I am able to
discern.  The only difference seems to be that completeselectedindex seems to be
set for text fields in 1.0 and is not set for text fields on the trunk.  (It is
set for the location bar and search bar, though.)
This is a fix for the 1.0.x branch using the same strategy that was used in bug
290172.  It restores the desired side arrow key behavior without making the
location bar unpleasant.  Since the bug is a regression from 1.0 in the 1.0.x
series, mconnor asked me to port that patch from the trunk.
Attachment #180857 - Flags: review?(mconnor)
Attachment #180857 - Flags: approval-aviary1.0.4?
Comment on attachment 180857 [details] [diff] [review]
Patch for AVIARY_1_0_1 branch

not sure if/when we'll have a 1.0.4, but this meets current criteria
(regression from a security fix) and is on trunk already.
Attachment #180857 - Flags: review?(mconnor) → review+
Comment on attachment 175688 [details] [diff] [review]
restore old right-arrow behavior

Don't want this one
Attachment #175688 - Attachment is obsolete: true
Attachment #175688 - Flags: approval-aviary1.0.4? → approval-aviary1.0.4-
Flags: blocking-aviary1.0.4? → blocking-aviary1.0.4+
Flags: blocking-aviary1.0.4?
1.0.4 is not taking non-critical security fixes.

Flags: blocking-aviary1.0.4? → blocking-aviary1.0.4-
Whiteboard: have patch for regression
dveditz:  Do we need an sr= before approving this for 1.0.5?
Attachment #180857 - Flags: approval-aviary1.0.5? → approval-aviary1.0.5+
Let's get this on the Aviary branch... a=jay
Whiteboard: have patch for regression → need branch landing
landed attachment 180857 [details] [diff] [review] on the aviary1.0.1 branch
Whiteboard: need branch landing
You need to log in before you can comment on or make changes to this bug.