Closed Bug 464598 Opened 14 years ago Closed 6 years ago
SNAV: snav can move focus out from single-line input fields only if cursor is at one of the widget edges
STEPS: 1) Open the attached test-case. 2) put focus in the single-line form input. 3) type any text (more than 3 characters for easier reproducing). 4) w/out moving focus out from the form, put cursor in the middle of the typed word (it can be any position different from the first and last positions). 5) press keyDown to move focus down through snav. CURRENT OUTCOME: it does not move focus down. EXPECTED OUTCOME: focus moved away from single-line input and put in multi-line input
we got better behaviour if we handle single and multiline inputs on their own.
lets get some tests case for this.
ok , I will make chrome://mochikit/content/chrome/toolkit/spatial-navigation/tests/test_snav_textFields.xul to run w/out failures according to the patch.
Status: NEW → ASSIGNED
added changes in toolkit/spatial-navigation/tests/chrome/test_snav_textFields.xul accordingly to the changes in patch #2. tests all passed : 59/59
changes applyable after changes in bug 463514. mark, doug asked for someone else to check that. I would be glad if you could...
Depends on: 463514
re-ping review ...
Attachment #357970 - Flags: review?(doug.turner) → review+
Comment on attachment 357970 [details] [diff] [review] handle singleline and multiline inputs separately (v4) + // we are at the start of the text, okay to move + if (target.selectionStart != 0) change this comment to read the: if there is text, there it isn't okay to move same here: + // we are at the start of the text, okay to move + if (target.selectionStart != 0) If we are not at the start of the text, it isn't okay to move. -<window title="Mozilla Bug 288254" +<window title="Mozilla Bug 436084" why this change. With those fixes, and a reasonable explanation for the window title change, r=.
(In reply to comment #9) > (From update of attachment 357970 [details] [diff] [review]) > + // we are at the start of the text, okay to move > + if (target.selectionStart != 0) > > > change this comment to read the: > if there is text, there it isn't okay to move ok > same here: > + // we are at the start of the text, okay to move > + if (target.selectionStart != 0) > If we are not at the start of the text, it isn't okay to move. ok > -<window title="Mozilla Bug 288254" > +<window title="Mozilla Bug 436084" it is probably a c&p typo. look: "Bug 288254 - (xblfindbar) Findbar XBL Widget " has nothing to do with our current bug.
Attachment #357970 - Attachment is obsolete: true
Comment on attachment 358046 [details] [diff] [review] handle singleline and multiline inputs separately (v5) carry dougt's r+
Attachment #358046 - Flags: review+
v6. the v5 patch mochitest part failed on MAC because it made use of HOME/END keys, which are not available in this platform. patch is the same as previous but fixed this issue.
Attachment #362174 - Flags: review?(doug.turner) → review+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Backed out because the new test was causing a lot of failures on Mac OS X: http://hg.mozilla.org/mozilla-central/rev/766303321a07 http://hg.mozilla.org/mozilla-central/rev/75de262e2a2e
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
doug, test is failing on MAC (and has been reopened twice) but I do not have a MAC box handy to make it work on that platform. Could you help me testing it on that platform please ?
This bug's parent component is going away. Should this bug be moved to an equivalent component in Android or iOS?
This is a Gecko bug thus irrelevant for Firefox for iOS. I don't know of an Android device with a directional pad that we support (Android 4.0+).
Status: REOPENED → RESOLVED
Closed: 14 years ago → 6 years ago
Resolution: --- → INCOMPLETE
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.