Closed Bug 294642 Opened 20 years ago Closed 18 years ago

Up and Down Arrows moves text insertion point left or right on Textbox with autocomplete="off" attribute

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 3 beta2

People

(Reporter: awburns, Assigned: uriber)

References

Details

(Keywords: testcase)

Attachments

(2 files)

testcase
266 bytes, text/html
Details
remove keybindings
1.69 KB, patch
neil
: review+
neil
: superreview+
beltzner
: ui-review+
mtschrep
: approval1.9+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.7) Example page: <html><body><form><input type="text" name="x" autocomplete="off" value="123456789" /></form></body></html> Open page in Firefox, select the text box. Press up and down arrows on Keyboard. I find that the text insertion point (Claret? You know, the vertical line thing) moves left or right when up and down keys are pressed. Remove the attribute 'autocomplete="off"', reload the page, and this behaviour ceases. Reproducible: Always Steps to Reproduce: 1.Create page contain HTML code: <html><body><form><input type="text" name="x" autocomplete="off" value="123456789" /></form></body></html> 2.Save code, open page. 3.Select Textbox 4.Press up arrow. Claret (text insertion point) will move left. 5.Press down arrow. Claret will move right. Actual Results: Up and down arrow moved text insertion point left and right. Expected Results: Nothing, I guess. That's what happens without the autocomplete="off" attribute. That's what would happen in other browsers
-> Keyboard Navigation
Component: General → Keyboard Navigation
QA Contact: general → keyboard.navigation
I have the same situation with the UP/DOWN key. The big problem, however, is that the LEFT/RIGHT arrow keys don't do anything when entering text in text input boxes, IF JAVASCRIPT IS DISABLED. Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b2) Gecko/20050603 Firefox/1.0+
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
Reopening. I can see this with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070304 Minefield/3.0a3pre This does not affect Linux, apparently. I'll check later with Mac.
Severity: minor → normal
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file testcase —
Keywords: testcase
These keybindings were probably added on purpose, since *some* one-line input boxes on Windows indeed behave this way. However, I still think they should be removed because: 1. Text input controls in IE don't use them. 2. The vast majority of input controls have autocomplete="on", so the user is not likely to expect up/down to work this way. 3. This is a trap for web developers who implement their own autocomplete: They must remember to kill the default handlers for up/down arrows, but they can only find this out by testing on Mozilla/Win.
Attachment #258128 - Flags: superreview?(bzbarsky)
Attachment #258128 - Flags: review?(bzbarsky)
Attachment #258128 - Attachment is patch: true
Attachment #258128 - Attachment mime type: application/octet-stream → text/plain
I'm not the right person to review this... you probably want to get UI-review from the usual suspects and then get review from some Windows person.
Attachment #258128 - Flags: ui-review?(beltzner)
Attachment #258128 - Flags: superreview?(bzbarsky)
Attachment #258128 - Flags: review?(bzbarsky)
Comment on attachment 258128 [details] [diff] [review] remove keybindings >- <handler event="keypress" keycode="VK_UP" command="cmd_charPrevious"/> >- <handler event="keypress" keycode="VK_DOWN" command="cmd_charNext"/> >- <handler event="keypress" keycode="VK_UP" modifiers="shift" command="cmd_selectCharPrevious"/> >- <handler event="keypress" keycode="VK_DOWN" modifiers="shift" command="cmd_selectCharNext"/> I think those should be "cmd_beginLine" and "cmd_endLine", actually, in the single line case. At least on OSX, but we might as well do it for the entire field.
Attachment #258128 - Flags: ui-review?(beltzner) → ui-review-
Note that my proposed patch is Windows-specific (the behavior on OS X is currently as you describe - so no need to change it). What you propose (the OS X behavior) is not standard on Windows, so I'm not sure why we would like to implement it there (I thought we were trying to emulate native control behavior as closely as possible). But If you really think we should do that, I'll make a modified patch (when I have time).
Mike, you weren't CCed so you probably never saw comment #10. Care to respond to it now? Thanks.
Comment on attachment 258128 [details] [diff] [review] remove keybindings (In reply to comment #10) > What you propose (the OS X behavior) is not standard on Windows, so I'm not > sure why we would like to implement it there (I thought we were trying to > emulate native control behavior as closely as possible). But If you really > think we should do that, I'll make a modified patch (when I have time). Oops, I see. Sorry. I'll give this my blessing, then, sure, and deal with the other thing over in bug 231754.
Attachment #258128 - Flags: ui-review- → ui-review+
Attachment #258128 - Flags: review?(neil)
Attachment #258128 - Flags: review?(neil) → review+
Comment on attachment 258128 [details] [diff] [review] remove keybindings Thanks, Neil. I think I need your sr+ as well, for the record.
Attachment #258128 - Flags: superreview?(neil)
Attachment #258128 - Flags: approval1.9?
Attachment #258128 - Flags: superreview?(neil) → superreview+
Assignee: nobody → uriber
Attachment #258128 - Flags: approval1.9? → approval1.9+
Checking in mozilla/content/xbl/builtin/win/platformHTMLBindings.xml; /cvsroot/mozilla/content/xbl/builtin/win/platformHTMLBindings.xml,v <-- platformHTMLBindings.xml new revision: 1.26; previous revision: 1.25 done
Status: NEW → RESOLVED
Closed: 20 years ago → 18 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 M10
Version: unspecified → Trunk
Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9b2pre) Gecko/2007112605 Minefield/3.0b2pre ID:2007112605
See Also: → 1260840
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: