355 bytes, text/html
[GitHub issue by nhirata on 2012-07-25T23:02:45Z, https://github.com/mozilla-b2g/gaia/issues/2824] ## Environment : Otoro phone, build 2012-07-25 Taken from default.xml in b2g-distro: * "platform_build" revision= 2163d79af8c06ffcf7607a83e01dc5bf1107fd8e * "gaia" revision= 578593de74dd70a0aa6c3d4a5f652d739e342694 * "mozilla-central" revision= 3632e0895ae248b818dd50317534b4cb4cdc934a * "gonk-misc" revision= c6a9a256cd4a1c53696488739d36778b9dbfc881 ## Repro : 1. launch contacts 2. click on the + button to add a contact 3. click in the Name field 4. hit return ## Expected : * the cursor will go to the next field (Last name) ## Actual : * the phone number gets deleted ## Note : * if you hit return again, a new phone number will get added * if you hit return in a form field in browser, it doesn't do anything.
[GitHub comment by albertopq on 2012-08-01T16:25:07Z] @lodr @RudyLu ? May be is worthy the Keyboard sending a tab code (9) instead an enter one in every input field (except textareas and inputs type=search)?
[GitHub comment by RudyLu on 2012-08-13T06:54:32Z] Hi @albertopq, As far as I know, the current behavior is the default behavior for web form handling. Pressing [Enter] key in a form field (input) would trigger onclick of the first button in the form. You may see the following link as a simple example, http://jsfiddle.net/94MdF/ I would suggest that we handle the [Enter] key event in the Contacts app. to jump to the next form field. Thank you.
[GitHub comment by albertopq on 2012-08-13T07:57:14Z] Thanks for the feedback @RudyLu. I'll implement it in the Contacts app itself, then. Regards
[GitHub comment by albertopq on 2012-08-28T17:16:01Z] After @chrisvargauk spending some time trying to fix it in the Contacts app, we realized that is not that easy. I have discussed it with @vingtetun and we both agree that makes sense having a "Next" button inside the keyboard with the following input types: text, url, number, tel, email. @timdream @RudyLu @lodr , what do you think? Does it makes sense to send a tab event instead a enter for those types?
[GitHub comment by RudyLu on 2012-08-29T03:58:08Z] I think this means we would need add another key as [Next] in the keyboard. 1. This may need UX input since there is no such design for current keyboard layout spec. cc @caseyyee, @rafaelrebolleda 2. I just gave it a try to send [Tab] from keyboard app. but it could not change the focus to the next input field. It seems it might need more work to complete this feature.
[GitHub comment by rafaelrebolleda on 2012-08-30T02:30:19Z] The Keyboard Specs do indeed talk about this feature :) I definitely think the key should be "Next" in certain occasions. However, relying on the input type is not enough on a general basis. At least the last field may not necessarily be "Next", specially if we're talking about fixing this on beyond the contacts app.
[GitHub comment by RudyLu on 2012-08-30T03:37:40Z] @rafaelrebolleda, thanks for the reminding. But I think what our spec suggest is to replace [New Line] with [Next]. However, here I think we need an extra [Next] key. I have seen it is mentioned in spec p.10 that we may add [Previous] and [Next] at the top of the keyboard. This should fit the case we are discussing here, right?
[GitHub comment by rafaelrebolleda on 2012-08-30T11:21:10Z] No prob. The "new line" was just an example of how that key could take on different functions depending on context. I think "next" is perfectly valid example. I also suggested using the bar on top, but AFAIK that hasn't been a full agreement on that. I can check with @caseyyee and @jcarpenter on that. We may have a conflict with word suggestion (about which I think we also need to talk :) beyond the Contacts app.
[GitHub comment by autonome on 2012-09-25T02:17:26Z] Is the design clear here? @RudyLu do you have enough information to begin fixing?
[GitHub comment by RudyLu on 2012-09-25T02:45:41Z] Hi @autonome, For this issue, we need, 1. UX to define the final UI hehavior. 2. after UX is clear, we would check what Gecko support is needed. 3. Gaia implementation Thanks.
[GitHub comment by autonome on 2012-09-25T04:44:17Z] Thanks Rudy. @jcarpenter do you know if this is in a spec somewhere? On Mon, Sep 24, 2012 at 7:45 PM, Rudy Lu <email@example.com> wrote: > Hi @autonome <https://github.com/autonome>, > > For this issue, we need, > > 1. UX to define the final UI hehavior. > 2. after UX is clear, we would check what Gecko support is needed. > 3. Gaia implementation > > Thanks. > > — > Reply to this email directly or view it on GitHub<https://github.com/mozilla-b2g/gaia/issues/2824#issuecomment-8841882>. > >
[GitHub comment by jcarpenter on 2012-09-25T07:01:15Z] > Thanks Rudy. @jcarpenter do you know if this is in a spec somewhere? @rafaelrebolleda said: > The Keyboard Specs do indeed talk about this feature :) I definitely think the key should be "Next" in certain occasions. However, relying on the input type is not enough on a general basis. At least the last field may not necessarily be "Next", specially if we're talking about fixing this on beyond the contacts app. I defer to @caseyyee and @rafaelrebolleda on this. They are keyboard owners. Casey and Rafa, can you recommend a final v1 solution here?
[GitHub comment by rafaelrebolleda on 2012-09-26T08:37:41Z] Not really :( I've been giving this some deep thought, but it ultimately boils down to what we can actually do based on how gecko and gaia talk to each other. From what I've been hearing here and there, the keyboard and the view don't know much about each other. Could we split the `enter` key in two ([next], [new line], probably iconified) the same way we split the "?123" key when multiple languages are available? Perhaps change the [next] to [submit] if in the last field, and otherwise rely on touch to submit.
6 years ago
Assignee: nobody → alberto.pastor
Created attachment 673960 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/5942 Pointer to Github pull-request
6 years ago
Attachment #673960 - Flags: review?(21) → review-
Comment on attachment 673960 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/5942 r+ but please add a comment explaining why you check for clientX == 0 and clientY == 0.
Attachment #673960 - Flags: review?(21) → review+
With this fix, it will stop removing the phone number when hitting ENTER, but won't jump to the next input. Per Vivien, I added a comment in the code explaining it and created a bug for tracking the Keyboard issue (#809452).
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Verified on the 11/12 otoro us build that hitting enter does not remove the phone number, nor does it jump to the next input.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.