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

Confirming as RFE

*** Bug 234956 has been marked as a duplicate of this bug. ***

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.

*** Bug 239020 has been marked as a duplicate of this bug. ***

*** Bug 258191 has been marked as a duplicate of this bug. ***

*** Bug 262976 has been marked as a duplicate of this bug. ***

*** Bug 268754 has been marked as a duplicate of this bug. ***

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.

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.

i don't do firefox -> ben

*** Bug 275586 has been marked as a duplicate of this bug. ***

The "URL bar" part of this bug is a duplicate of bug 129173.

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.

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.

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.

(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

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.

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.

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?

(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.

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?

(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

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.

*** Bug 319433 has been marked as a duplicate of this bug. ***

(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.

*** Bug 330001 has been marked as a duplicate of this bug. ***

*** Bug 351978 has been marked as a duplicate of this bug. ***

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.

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.

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.

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.

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.

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.

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).

(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.

Holding out hope that this can be fixed so I can make Firefox my browser.

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.

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.

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

(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.

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.

--> Tookikt:Autocomplete, as this is a bug in that code and affects all toolkit apps (e.g. SeaMonkey), not just Firefox.

Bleh, that ate the blocking-firefox3-, wanted-firefox3+ flags :/ Renominating so someone can re-set the appropriate ones.

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.

For the record, this was marked as wanted-firefox3+ before it got moved into the Toolkit product and lost the flag.

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.

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?

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).

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.

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.

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.

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.

(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 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 on attachment 314093 [details] [diff] [review] don't cancel with a selection present, remove -1, and add Mac-only test a=john gruber

(a=beltzner, for realz)

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.

This bug is currently mac only, so I have been expecting that the patch is mac-only as well. Is that not the case?

I'll add some ifdefs around the code change to make it Mac only.

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