Last Comment Bug 231754 - Mac: pressing up/down arrow key does not move caret to beginning/end of url bar or text box
: Mac: pressing up/down arrow key does not move caret to beginning/end of url b...
Status: RESOLVED FIXED
[polish-hard] [polish-interactive][po...
: polish, ue
Product: Toolkit
Classification: Components
Component: Autocomplete (show other bugs)
: unspecified
: PowerPC Mac OS X
: P4 normal with 23 votes (vote)
: mozilla1.9
Assigned To: Neil Deakin
:
: Marco Bonardo [::mak]
Mentors:
: 234956 239020 258191 262976 268754 275586 319433 330001 351978 356883 422171 (view as bug list)
Depends on: 129173
Blocks: 440515
  Show dependency treegraph
 
Reported: 2004-01-21 13:44 PST by Jennifer
Modified: 2011-05-30 22:44 PDT (History)
47 users (show)
mbeltzner: wanted‑next+
mbeltzner: blocking1.9-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
something like this perhaps? (2.07 KB, patch)
2008-04-06 18:20 PDT, Neil Deakin
no flags Details | Diff | Splinter Review
don't cancel with a selection present, remove -1, and add Mac-only test (5.82 KB, patch)
2008-04-07 08:21 PDT, Neil Deakin
gavin.sharp: review+
mbeltzner: approval1.9+
Details | Diff | Splinter Review
add ifdef around code (6.10 KB, patch)
2008-04-08 11:54 PDT, Neil Deakin
no flags Details | Diff | Splinter Review

Description Jennifer 2004-01-21 13:44:39 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040120 Firebird/0.8.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040120 Firebird/0.8.0+

In other applications, pressing the upward arrow key jumps to the beginning of
the line in one-line text boxes (i.e. the url bar) or if the current line is the
first line, and the end of the line if the down arrow key is pressed. Firebird
doesn't do this and breaks consistency.

Reproducible: Always

Steps to Reproduce:
1. Type a URL into the URL bar
2. Click somewhere in the middle to put the cursor there
3. Try to move to beginning or end of URL with up or down arrow keys

Actual Results:  
No cursor movement

Expected Results:  
Cursor should jump to start or end of line
Comment 1 James Anthony 2004-01-27 20:27:33 PST
Confirming as RFE
Comment 2 Wayne Woods 2004-03-06 17:01:02 PST
*** Bug 234956 has been marked as a duplicate of this bug. ***
Comment 3 Chocky 2004-03-09 03:50:39 PST
BTW, text-inputs on OSX usually accepts "emacs-shortcuts" like :
ctrl-a (resp. ctrl-e): jump to start (resp. end) of line
ctrl-d: remove one char after caret

kill-yank (ctrl-w ctrl-y) can usually be used too.
Comment 4 PikeUK 2004-03-29 13:46:33 PST
*** Bug 239020 has been marked as a duplicate of this bug. ***
Comment 5 bryan kennedy 2004-09-10 13:15:13 PDT
*** Bug 258191 has been marked as a duplicate of this bug. ***
Comment 6 HARUNAGA Hirotoshi 2004-10-06 05:48:31 PDT
*** Bug 262976 has been marked as a duplicate of this bug. ***
Comment 7 Ethan Smith 2004-11-10 10:36:30 PST
*** Bug 268754 has been marked as a duplicate of this bug. ***
Comment 8 Mike Calmus 2004-11-13 12:23:02 PST
I'm not sure this should be considered an enhancement since it is contrary to
the behavior expected within MacOS. Also, it works fine in Mozilla.
Comment 9 Johann Assam 2004-11-13 17:15:10 PST
This shortcut may not be part of any official Apple HIG documentation, but I can
comfortably say that many if not most expect this functionality from their
applications. Up/Down has been used for years (especially pre-OS X) to move the
caret from text boxes.
Comment 10 Mike Pinkerton (not reading bugmail) 2004-11-15 09:30:13 PST
i don't do firefox -> ben
Comment 11 Uri Bernstein (Google) 2004-12-22 12:35:30 PST
*** Bug 275586 has been marked as a duplicate of this bug. ***
Comment 12 Uri Bernstein (Google) 2004-12-22 12:40:05 PST
The "URL bar" part of this bug is a duplicate of bug 129173.
Comment 13 Kathleen Brade 2004-12-22 12:42:46 PST
Mozilla 1.7.3 works fine.  Another bug reported that 1.7.5 has this regression.
 Urlbar aside, I miss up/down arrow functionality in input fields in Firefox
1.0.  They work fine in textareas.
Comment 14 Dan Roca 2004-12-22 13:06:47 PST
The bug I entered was marked as a dupe of this one, but this one doesn't seem to
have all the information that mine did - so here's the info:

Up/Down arrow keys should move to start/end of a line for text input fields.
(IE. text input fields in the page, the URL field, search field in the toolbar,
any preferences that has text input, etc)

This bug exists in Firefox 1.0, and Mozilla 1.7.5 (but not in Camino)

-Note: Mozilla 1.7.5 (and 1.7.3) seems to work fine for all areas (input field,
textarea
field, in the Preferences) except for the URL field.
-Note: Firefox 1.0 seems to work fine in textareas and most of the preferences
fields, but not in input fields, nor with the URL field, nor the Google search
field, nor in the Preferences for the location of the homepage field.
Comment 15 Kevin Riggle 2005-02-27 22:53:00 PST
Other related keybindings which work in other Mac applications and not Firefox for moving to the ends 
of a text-entry field are Ctrl-A/Ctrl-E and Ctrl-left-arrow/Ctrl-right-arrow.
Comment 16 Aaron Sloman 2005-09-24 11:05:32 PDT
(In reply to comment #0)

> In other applications, pressing the upward arrow key jumps to the beginning of
> the line in one-line text boxes (i.e. the url bar) or if the current line is the
> first line, and the end of the line if the down arrow key is pressed. Firebird
> doesn't do this and breaks consistency.

That may be what Mac users expect, but I am not a mac user and I much prefer
what the current behaviour does in firefox, namely in the URL bar, firefox allow
s me to use up/down arrow keys to move through the history of previous URLs as
it also does in many menus in forms, etc.

If I wish to go to beginning or end of line, I can use left/right arrows, or
CTRL-A CTRL-E (controlled by ~/.gtkrc-2.0)

I would definitely prefer this not to change.

> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Type a URL into the URL bar
> 2. Click somewhere in the middle to put the cursor there
> 3. Try to move to beginning or end of URL with up or down arrow keys
> 
> Actual Results:  
> No cursor movement

Do you get no movement even if you have viewed several previous urls?

Perhaps I've misunderstood.
Aaron
www.cs.bham.ac.uk/~axs
Comment 17 Kathleen Brade 2005-09-25 08:12:55 PDT
Aaron (comment 16) -- you admit you aren't a Mac user so why are you opposed to
fixing this for the Macintosh version of Firefox???  Not to be snide, but I
don't think your opinion (as a non-Mac person) should apply to the Macintosh
version of Firefox.

>Do you get no movement even if you have viewed several previous urls?
The caret does not move when the up/down arrow keys are pressed.  Instead a list
of urls appear and your focus changes (which really sucks).  If you are unlucky
you can completely lose the url you were trying to edit.
Comment 18 Johann Assam 2005-09-28 00:37:12 PDT
I, as do others I've spoken with, thoroughly agree that commenter #16 has no idea what he's talking 
about. The self-admitted Linux user has no business dictating on a product he hardly uses, if ever. Aaron, 
just as they're certain 'norms' you expect in GTK/Linux interfaces (graphical or otherwise)  that may not be 
documented, Mac users equally expect this sort of functionality from their programs. Again, this is a Mac-
only request, so I fail to see the reason for your post at all.
Comment 19 Uri Bernstein (Google) 2005-10-03 03:35:00 PDT
This bug goes away (except in the URL bar, which is bug 129173) if you set
"browser.formfill.enable" to false.

We need to decide what to do here. Here are some options:
1. Restore the beginnig/end functionality of up/down arrow and provide other
means for accessing the formfill feature.
2. Restore the beginnig/end functionality only when there are no autocomplete
options available.
3. Enable autocomplete only when the caret is at the end of the text field,
restore beginnig/end functionality in all other cases.
4. Do nothing (i.e. WONTFIX this bug)

Thought? Other suggestions?
Comment 20 Mike Calmus 2005-10-03 04:11:26 PDT
(In reply to comment #19)

I'd like to see some combination of option 1 and option 2.

Option 2 would always be applied and really makes sense regardless of anything
else that is done. I suggest a possible improvement upon this option at the end
of my post.

Additionally, we should add the ability to use a "Fill in form" option similar
to that used in Seamonkey. Then the user could entirely disable the current form
autocomplete but still have a way to fill in forms. This option really has merit
even absent this bug.

In concert with option 2, the up/down functionality could be availble not just
when no matches exist but also if the user "dismissed" any available options by
hitting escape. I see "dismissal" working basically until some other key is
pressed. In other words, if I start typing a phrase and get a match, hitting
escape would clear the matching text. At that point pressing up or down would
work as is the intent of this bug until I press some other character that causes
a match.

One concern is that I don't really know the current functionality of up/down in
the context of auto-complete. Is it used to cycle between possible matches? If
so, the intended functionality of this bug could be restored not just in the
cases given but really in any case when one or fewer matching options are found.
Comment 21 Kathleen Brade 2005-10-03 05:32:37 PDT
Uri (comment 19) -- thanks for sharing the root of this problem (autofill of
form fields).  I had no idea the conflict was coming from there.

Can someone tell me where the form fill code is (and/or the key binding)?

The problem seems to be that the down arrow key event is being consumed by the
form fill code when it shouldn't be.  If there is no match the list shouldn't
appear and the event should be propagated to the edit field to handle.

Simon--do you have an opinion on the specification for this functionality?
Comment 22 Uri Bernstein (Google) 2005-10-03 06:03:21 PDT
(In reply to comment #21)
> Can someone tell me where the form fill code is (and/or the key binding)?

Try here:
http://lxr.mozilla.org/mozilla/source/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp#356
Comment 23 Kathleen Brade 2005-10-03 06:27:49 PDT
I haven't managed to get my tree working since upgrading to 10.4; can someone
try making these changes?

1) Move the following block of code into the if (isOpen) block (line 388):
 382           // Prevent the input from handling up/down events, as it may move
 383           // the cursor to home/end on some systems
 384           *_retval = PR_TRUE;

This makes sense to me; if the list is open, I expect the arrows to be
navigating that list.

2) Copy the same block of code from #1 above to the else block but only in the
case where there is a resultCount.

 418             PRUint32 resultCount;
 419             mResults->Count(&resultCount);
 420             if (resultCount) {
 421               if (mRowCount) {
 422                 OpenPopup();
 423               }
 424             } else
 425               StartSearchTimer();

Does not setting *_retval let the event out to the editor keybindings?


Note to self: file a bug on autocomplete causing loss of data and not taking
advantage of editor undo/redo.
Comment 24 zug_treno 2005-12-08 08:10:45 PST
*** Bug 319433 has been marked as a duplicate of this bug. ***
Comment 25 Dan Roca 2005-12-08 08:27:57 PST
(In reply to comment #19)

Yeah, I also agree that a combo of option #1 and #2 would be best. While you're in auto-fill, pressing escape will get you out of it. At that point, pressing up/down should move to the beginning/end of line.

Now, I'm not sure how you should get back in to auto-fill mode. (Maybe something like Shift-Esc - I dunno).

Regardless of whether #1 gets implemented, I think #2 should still be done.
Comment 26 Uri Bernstein (Google) 2006-03-10 03:04:50 PST
*** Bug 330001 has been marked as a duplicate of this bug. ***
Comment 27 Hiro 2006-09-09 15:44:47 PDT
*** Bug 351978 has been marked as a duplicate of this bug. ***
Comment 28 John Spradlin 2006-10-26 11:12:21 PDT
What about behavior like this?

Show the auto-fill field as normal. But leave the focus on the text field. 

If the down arrow is pressed while the cursor is somewhere in the middle of the line, jump to the end of the line, as is customary for Mac apps.

If the down arrow is pressed while the cursor is at the end of the line, go into the auto-fill section and use the usual up/down behavior from then on.

This would give Mac users the expected textbox behavior without making them jump through hoops (control-this or that) to get the auto-fill field that everyone's grown accustomed to.
Comment 29 Ken Weingold 2006-11-24 16:50:08 PST
Please do something about this for Firefox on OS X.  This behavior drives me nuts.  I know I can use those emacs keystrokes for jumping to the beginning  and end of a line, but I see now way to do that movement in combination with the Shift key for highlighting the whole line.
Comment 30 bassooner42 2007-01-02 22:51:59 PST
A macish way that ive gotten around this bug is to highlight the whole text field with command-A, then left or right arrow to move the cursor to the beginning or end of that field.  The auto fill behavior has actually retrained me to do this, as at first I was annoyed by the enhanced behavior.  
Comment 31 Ken Weingold 2007-01-03 06:20:16 PST
That works, but doesn't help with something I often do, which I am sure many others do as well, which is moving the cursor somewhere in the middle of the line of text and highlighting from there to the beginning or end of the line with Shift and an up or down arrow.
Comment 32 bassooner42 2007-01-03 19:04:25 PST
In that case I would move the cursor somwhere in the middle of the line of text, then use command+shift+arrowkey 
This will select from your selection point to the end of the line in the direction of the arrow.
Comment 33 Benjamin Esham 2007-04-02 12:46:40 PDT
Using CTRL-A and CTRL-E is not always possible; for some sites, like Wikipedia (and other MediaWiki-powered sites), those keys are bound with JavaScript to e.g. "Edit this Page."  In that situation, pressing CTRL-E in a text field will navigate to a different page, which is jarring and presents the possibility of data loss.  Besides, Command-Up and Down are the system-standard shortcuts for beginning and end, while CTRL-{AEKW} are more "power-user" shortcuts.
Comment 34 Joseph R. Kiniry 2007-04-03 07:40:48 PDT
Re: Benjamin Esham

Such keypress actions may be overridden by JavaScript application when textboxes in a browser window have the focus; I have no problem with that.  But if the URL bar has the focus, no JavaScript program should be able to receive input (IMO).  Unfortunately, it is not clear to me that Firefox has a fixed policy wrt input focus, as I witness varying behavior across platforms and builds (e.g., sometimes the URL bar has the focus, sometimes a tab [but not HTML frame] has focus, other times elements of an HTML frame has focus, etc. willy-nilly).
Comment 35 Benjamin Esham 2007-04-13 14:25:10 PDT
(In reply to comment #33)
> Besides, Command-Up and Down are the system-standard shortcuts

Of course, I meant to write simply "Up and Down", with no modifier keys.
Comment 36 Halle Winkler 2007-08-28 11:56:09 PDT
Holding out hope that this can be fixed so I can make Firefox my browser.
Comment 37 Alex Faaborg [:faaborg] (Firefox UX) 2007-11-21 00:19:10 PST
In april Colin wrote a blog post asking for feedback on how we could improve Firefox on the mac (http://iamthewalr.us/blog/2007/04/20/firefox-on-the-mac/).  Over 1000 emails came in, and the one thing that really surprised me was the vast number of people mentioning this specific issue, it was even more mentioned than complaints about Firefox crashing:

performance	21%
theme	12%
native widgets in the content area	11%
keychain support	10%
startup time	9%
drag and drop support similar to the bookmarks toolbar on windows	8%
--> text field navigation (up arrow for start, down error for end)	8%
crashing	7%

Of all the top issues on mac, this one is by far the easiest to fix.  In fact, given that user's are listing this on mostly the same level as the theme itself, I think we should block on finally getting this bug fixed.
Comment 38 Halle Winkler 2007-11-21 04:38:27 PST
Thanks, Alex.  It's already clear how many people are seriously bothered by this bug by the fact that 10 duplicates of it have been filed, as well as still-open bug 129173 (which also has a dupe submitted).  Considering that it's a minority browser on a minority platform and how vanishingly few people will bother to file a bug here instead of just downloading Camino, that's something.

I wish this would be seen as "minor" and not a request for an enhancement, since it's a basic keypress behavior for the OS which has been overridden by FF.
Comment 39 Mike Beltzner [:beltzner, not reading bugmail] 2007-11-21 08:52:46 PST
Not blocking, but would take a fix.

Uri: a while back in comment 19 you asked what we should do here. I agree with Mike's assertion in comment 20, which is to do a hybrid 1/2 approach (which is what seems to be the OS X standard for autocomplete text fields) where:

 when no autocomplete results available, 
    up arrow brings user to start of text field
    down arrow brings user to end of text field

 when autocomplete results are available,
    down arrow pops up autocomplete result list
    up/down arrows scroll through results
Comment 40 Uri Bernstein (Google) 2007-11-21 11:31:29 PST
(In reply to comment #39)

This, I think, is what I meant in option 2 (up/down are restored to their start/end functionality when no results are available, but otherwise behave as they do today).

I remember trying to implement this back then, and finding out that it is not easy. The process of searching for autocomplete results is done asynchronously (in nsAutoCompleteController::StartSearchTimer). Therefore, at the key event handler, we might not yet know whether the search will yield any results or not, and therefore we can't restore the default behavior based on that information.
The solution would probably be to save the event type somewhere (specifically, we need to know whether this was an up-arrow or down-arrow press), and call the default event handler if we eventually discover that no results were found.

Unfortunately, it is unlikely that I'll be able to work on this myself anytime soon, so someone else will have to take it if we want it for 1.9.
Comment 41 Uri Bernstein (Google) 2008-02-29 05:32:25 PST
*** Bug 356883 has been marked as a duplicate of this bug. ***
Comment 42 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-02-29 07:41:38 PST
From comment 13 in the bug that just got duped to this one (but paraphrased a bit)

As another option, how about the autocomplete search only firing off if the cursor is already at the beginning or end of a field, and if you're in the middle, do what the users of the OS expect.

For example:

User presses the down arrow key:
 - Am I at the end of the line?
    No - go to the end of the line
    Yes - start the automcomplete process
User presses the up arrow key:
 - Am I at the beginning of the line?
    No - go to the beginning of the line
    Yes - start the autocomplete process

This is already the behavior used in Camino.
Comment 43 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-02-29 11:23:55 PST
--> Tookikt:Autocomplete, as this is a bug in that code and affects all toolkit apps (e.g. SeaMonkey), not just Firefox.
Comment 44 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-02-29 11:26:39 PST
Bleh, that ate the blocking-firefox3-, wanted-firefox3+ flags :/  Renominating so someone can re-set the appropriate ones.
Comment 45 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-04-05 18:44:43 PDT
Usability issue on Mac...  This is a bug, not an enhancement.  Renominating based on that change, not sure the drivers realized that when it got triaged.
Comment 46 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-04-05 18:46:35 PDT
For the record, this was marked as wanted-firefox3+ before it got moved into the Toolkit product and lost the flag.
Comment 47 Josh Aas 2008-04-06 10:06:42 PDT
I doubt this qualifies for blocking status but I'd highly recommend getting an owner and trying to land this for the release. This really is a big deal on Mac OS X, it has been showing up explicitly in reviews for years and gets on my nerves daily. I don't have time to do most of the work right now but I'd definitely contribute code reviews, advice, and testing.
Comment 48 Mike Beltzner [:beltzner, not reading bugmail] 2008-04-06 12:11:41 PDT
I agree with Josh; doesn't block, but highly desired, especially if there's an easy patch.

Smokey - is there anything we can use from Camino here, along the lines of justdave's suggestion in comment 42?
Comment 49 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-04-06 18:16:02 PDT
Camino's autocomplete is in ObjC with very little talking to Gecko, so I think the only thing you can use is the logic ;)  

You can see our implementation via bug 247837, though (we don't trigger on up, so you won't see any checking for that, whereas Toolkit does trigger on up and should check for it).
Comment 50 Neil Deakin 2008-04-06 18:20:59 PDT
Created attachment 313986 [details] [diff] [review]
something like this perhaps?
Comment 51 Josh Aas 2008-04-06 18:52:06 PDT
Neil - we really need this to work for all single-line text fields, so the URL bar and single-line text controls in web forms. I assume if we made that fix then we wouldn't need to make a fix specific to the URL bar.
Comment 52 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-04-07 02:12:20 PDT
That patch looks good to me. I think you need to remove the "- 1" from the selectionEnd check, though. We should probably also not cancel the event if the selectionStart != selectionEnd.

Josh: I'm not sure I understand your comment correctly, but that patch fixes both content inputs and the URL bar.
Comment 53 Neil Deakin 2008-04-07 05:57:19 PDT
The AutocompleteController is attached as a key listener for both the url field and form control inputs as they both have autocomplete support, so this patch affects both.
Comment 54 Håkan Waara 2008-04-07 05:59:29 PDT
What about XUL textfields that do not have autocomplete? Do they exist? This should be something that works the same in all single-line textfields.
Comment 55 Neil Deakin 2008-04-07 06:04:10 PDT
(In reply to comment #54)
> What about XUL textfields that do not have autocomplete? Do they exist? This
> should be something that works the same in all single-line textfields.

Cursor up/down works properly in all textboxes. This bug is caused because the autocomplete listener is opening the popup and calling event.stopPropagation so that the default key shortcuts don't happen.
Comment 56 Josh Aas 2008-04-07 06:32:05 PDT
Comment on attachment 313986 [details] [diff] [review]
something like this perhaps?

This needs to work when there is a text selection too. Hit cmd-l to select all text in the URL bar. Then hit the up arrow. I'd expect the selection to go away and the insertion point to go to the beginning of the line.

Thanks for the explanation about autocomplete, makes sense now.
Comment 57 Neil Deakin 2008-04-07 08:21:06 PDT
Created attachment 314093 [details] [diff] [review]
don't cancel with a selection present, remove -1, and add Mac-only test
Comment 58 Mike Beltzner [:beltzner, not reading bugmail] 2008-04-07 12:55:29 PDT
Comment on attachment 314093 [details] [diff] [review]
don't cancel with a selection present, remove -1, and add Mac-only test

a=john gruber
Comment 59 Mike Beltzner [:beltzner, not reading bugmail] 2008-04-07 14:46:29 PDT
(a=beltzner, for realz)
Comment 60 Jesse Ruderman 2008-04-07 17:04:45 PDT
I think the new logic should be Mac-only, so that on Windows and Linux, the down arrow can continue to open autocomplete even when there is a selection or the caret is not at the end.
Comment 61 Mike Beltzner [:beltzner, not reading bugmail] 2008-04-08 07:09:09 PDT
This bug is currently mac only, so I have been expecting that the patch is mac-only as well. Is that not the case?
Comment 62 Neil Deakin 2008-04-08 11:18:50 PDT
I'll add some ifdefs around the code change to make it Mac only. 
Comment 63 Neil Deakin 2008-04-08 11:54:17 PDT
Created attachment 314381 [details] [diff] [review]
add ifdef around code
Comment 64 Jesse Ruderman 2008-07-18 01:17:43 PDT
*** Bug 422171 has been marked as a duplicate of this bug. ***
Comment 65 Alex Faaborg [:faaborg] (Firefox UX) 2009-06-23 00:16:46 PDT
This bug's priority relative to the set of other polish bugs is:
P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day.

This issue was listed as more annoying than crashing on OS X, details in comment #37

Note You need to log in before you can comment on or make changes to this bug.