356883 - Pressing up/down arrow in a single line text field fails to go to the beginning/end of the field on Mac OS X

Status: RESOLVED DUPLICATE of bug 231754

(Toolkit :: Autocomplete, defect)

Description

[John Wilson]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0

On a Mac, using the down arrow in a single-line input box takes you to the end of the contents in the box. This is the same as using the "End" key on a Windows machine.

In FF 2.0 rc2 this functionality is broken. For example using the up or down in the Summary field (on this bug report form, just above this Details field) does NOT move the cursor. In another app, like Safari, or FF 1.5, using the up arrow takes the cursor to the beginning of the field and using the down arrow takes the cursor to the end of the field. 

This is true for all fields in most Mac apps, and it was true for FF 1.5.x. In FF 2.0rcX (both rc1 and rc2) this doesn't work.

I just tested the arrow keys in this multi-line edit box on the last line and the down arrow DID take me to the end of the line, so the problem may only be in 1-line fields.

Reproducible: Always

Steps to Reproduce:
1. Type some stuff into a 1-line field - on a Web form or any FF 2.0 app field, like the URL field or the Find field.
2. Move the cursor into the middle of the typed field content.
3. Use the up or down arrow and notice that the cursor doesn't move.
4. Try the same test in any other Mac app and the cursor will move to the beginning or end of the field.

Actual Results:  
Cursor doesn't move.

Expected Results:  
Cursor should move to the beginning or end of the field. This is expected behavior on Macs.

This is one of the important user interface differences between Macs and Windows OS's. On a Mac users expect to be able to use the arrow keys to move immediately to the beginning or end of a one-line field. In Windows users expect to use the Home and End keys for the same thing. 

BTW, the Home and End keys don't work on a Mac either, so currently Mac users can't use either keyboard method to get to the beginning or end of a field.

Comment 1

[Steve England [:stevee]]

Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!

Comment 2

[John Wilson]

I just retested this behavior again in FF 2.0.0.4 and the same thing happens. 

This time I used a the Google Advanced Search page and typed some misc. numbers into "without the words" field. The up and down arrows still do nothing. I also double-checked several other programs (iTunes and Entourage). When I type text into a field in those programs (used a search field for both), the up and down arrow keys do behave like the home and end keys in a Windows application - they take you to the beginning and end of the field.

So, this is still non-standard Mac behavior. 

Comment 3

[Dave Miller [:justdave]]

This is still broken in 3.0b2

Given the major push for "works like a Mac app" in the Mac version of FF3 this probably ought to get fixed for FF3.

Comment 4

[Samuel Sidler (old account; do not CC)]

Does this belong in Widget:Cocoa?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Core::Widget:Cocoa

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This works fine (and always has) in Gecko (content) text fields in Camino, which suggests the problem is in something that interacts either with single-line text fields or with key event handling but which is *not* shared between Firefox and Camino.

Your guess is as good as mine as to what that might be; the app theme is the only thing that seems remotely "probable" (and even that's a bit of a stretch), but incidentally it coincides with the regression range given here (between fx 1.5 and fx 2.0)....

Comment 7

[Colin Barrett [:cbarrett]]

If the title is accurate, isn't this a dupe of another bug?

Comment 8

[Josh Aas]

I'm pretty sure this is not a Cocoa widget bug. Over to "Layout: Form Controls" since that is where I guess the issue is.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Form controls don't handle the key navigation, really.  This needs to be in editor, or possibly some UI component (given that it works in Camino).

What really needs to happen here is that someone needs to find the regression range, at which point we'll know what change broke this.

What I can contribute to that is that in current trunk seamonkey this is broken, but in 2006-09-28-06 it works.  So the trunk regression is somewhere in between those.  If someone hunts down the day it broke, we can figure out what broke it.

Comment 10

[Phil Ringnalda (:philor)]

Well, sort of - the SeaMonkey regression was somewhere in late July or early August, a time which I'm quite sure would narrow it down to when it switched to toolkit's autocomplete.

Comment 11

[Phil Ringnalda (:philor)]

Attachment: Fix v.1

Roughly speaking, borrowed from http://mxr.mozilla.org/seamonkey/source/xpfe/components/autocomplete/resources/content/autocomplete.xml#1030

Comment 12

[Phil Ringnalda (:philor)]

I suppose I should note that I don't think this is a regression for Firefox (1.5.0.10 seems to have exactly the same behavior as 2.0.0.x and trunk, and the code seems to have been written to do the same thing since before it was even enabled), and I don't think removing up/down as a shortcut to open autocomplete when there's something to show is a very good idea at this point, and I'm not convinced that having up/down do different things based on whether there's autocomplete data for what you've typed is a good thing, so... r+? wontfix? Dunno.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I meant to add what I mentioned to Phil when we were discussing this after chasing it down last week: Toolkit could also do (on Mac OS X, at least) what we implemented in Camino when people wanted the "press down to open autocomplete child window" in our location bar. If the cursor is somewhere in the text of the the field, up/down move to the beginning/end of the field as expected, but if the cursor is already at the end of the field, down will open the autocomplete child window (you could also do the same with up, since up apparently also invokes autocomplete).

Presumably (just guessing, though) this would also allow up/down to work properly in single-line fields where there is nothing to autocomplete or when autocomplete is not enabled (which has been a persistent annoyance to me every time I'm in Firefox checking something ;) ).

Comment 14

[Mike Connor [:mconnor]]

comment 13 makes sense.

This is not a regression, it shouldn't be a blocker at this point, but this would be good to solve for Fx3

Comment 15

[Uri Bernstein]

This is (the 10th) duplicate of bug 231754. Marking as such.