Some user study participants could not find the text field on top of the keyboard when trying to compose a message. A solution we considered is to bring up the keyboard when tapping the middle of the screen in the messaging app. Another option (in addition to or instead of the above) would be to increase the contrast between the text field and the message thread.

Stephany, which version were you using during the user study? I think what you propose is part of the Visual Refresh, see for example https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8394784 where we remove the border.

Hi Julien - we were using a ~1.4 special Rocketbar build. That visual refresh bug may cover it, so long as the keyboard behavior matches (and it sounds like it will). If you can confirm we can resolve this as a dupe. Thanks!

Omega, can you please confirm my comment 1? I don't think we have a bug for this though, so maybe we should keep this bug and make it block the visual refresh meta bug.

(In reply to Julien Wajsberg [:julienw] from comment #3) > Omega, can you please confirm my comment 1? > > I don't think we have a bug for this though, so maybe we should keep this > bug and make it block the visual refresh meta bug. I don't think bringing up the keyboard when tapping the middle of the screen is a good idea, since there might be existing messages there. Agreed with blocking the visual refresh meta bug. Maybe we can make the text field more visually clear.

Omega, we would do this only in the "new message" panel obviously, not in a thread panel with messages.

(In reply to Julien Wajsberg [:julienw] from comment #6) > Omega, we would do this only in the "new message" panel obviously, not in a > thread panel with messages. For "new message", yeah we can do that. The middle of screen and the text field look like the same area now.

Hey Oleg, this is part of Visual Refresh and actionnable right now, if you want it :)

(In reply to Julien Wajsberg [:julienw] from comment #8) > Hey Oleg, this is part of Visual Refresh and actionnable right now, if you > want it :) Sure, will consider this, ni? myself for now, just to not forget :) Thanks!

Just to confirm that "bring up keyboards" means to perform the following steps: 1. User clicks\taps in the middle of screen; 2. Check if keyboard is visible; 2.1 If visible (subject or message input is active) - do nothing and let keyboard to go away; 2.2 If hidden - call focus for our input\content editable; 3. If we called "focus" then we should position our cursor at the end (?) of contenteditable container as by default Gecko may put it to wrong location. Does it sound right? Regarding to step #3, for example we can use the same trick as email app uses: https://github.com/mozilla-b2g/gaia/blob/e3fc29c5d4a9196b0e32e246f3d0150ae0c39221/apps/email/js/cards/compose.js#L180 Looks like on focus, caret in content editable is placed with respect to current active selection, here you can play with focus button & blur via taps\clicks in different places (above or below content editable): http://people.mozilla.org/~azasypkin/content-editable.html

Attaching WIP patch.

About 3., bug 959201 is related; maybe you can handle it separately in bug 959201 using a new method "Compose.focusAtEnd()". The trick used by email is definitely the good path for this IMO. That said, I think we should not focusAtEnd in this case. Imagine the case the user leaves the cursor in the middle of the composer; then taps the recipient panel, then taps in the middle => IMO the cursor should stay were it was, it should not go in the end. About 2., I'd say it's the correct behavior. Let's ask Omega about the behavior in comment 10 and my comment 12.

(In reply to Julien Wajsberg [:julienw] (away until 5th May) from comment #12) > Let's ask Omega about the behavior in comment 10 and my comment 12. IMO it should be: 1. User clicks\taps in the middle of screen; 2. Make keyboard visible, and call focus for our input\content editable; 3. Position our cursor at the beginning of content editable container. The reason for 2 is: the middle of screen should be treated as an extension of the input; and, we now have a handy way to hide keyboard (bug 985331). The reason for 3 is: the middle of screen is prior to the input, so the focus should be at the beginning. However if user taps on the input, the focus should be at the position where he taps.

(In reply to Omega Feng [:Omega] from comment #13) > (In reply to Julien Wajsberg [:julienw] (away until 5th May) from comment > #12) > > Let's ask Omega about the behavior in comment 10 and my comment 12. > > IMO it should be: > 1. User clicks\taps in the middle of screen; > 2. Make keyboard visible, and call focus for our input\content editable; > 3. Position our cursor at the beginning of content editable container. > > The reason for 2 is: the middle of screen should be treated as an extension > of the input; and, we now have a handy way to hide keyboard (bug 985331). Omega, does that mean we now have no way to hide the keyboard in this view? (except sliding down the keyboard, but nobody knows this gesture). > The reason for 3 is: the middle of screen is prior to the input, so the > focus should be at the beginning. However if user taps on the input, the > focus should be at the position where he taps. This makes sense, but then, is it really what the user likely wants to do? Maybe we should not keep the empty space on top of the message; instead, we should keep the empty space on the _bottom_. Maybe for an upcoming version though, not now. What do you think?

(In reply to Julien Wajsberg [:julienw] (away May 8th) from comment #14) > Omega, does that mean we now have no way to hide the keyboard in this view? > (except sliding down the keyboard, but nobody knows this gesture). Now we can long press on Spacebar to hide keyboard (bug 985331). That's easier to be noticed than sliding down. > Maybe we should not keep the empty space on top of the message; instead, we > should keep the empty space on the _bottom_. Maybe for an upcoming version > though, not now. What do you think? Maybe it's a solution, but the layout will be different from existing message layout. We should make them consistent.

Comment on attachment 8416434 [details] GitHub pull request URL (wip) I've updated PR in accordance with Omega's feedback in comment 13. So it would be great if you can play with it a bit and leave your feedback!

Comment on attachment 8416434 [details] GitHub pull request URL (wip) r=me seems to work properly, even if I don't really understand why calling "focus" on dom.message puts the focus at the start. I can't make it work on a "normal" contenteditable in firefox. But well I couldn't make it not work properly on the device so let's go !

Comment on attachment 8416434 [details] GitHub pull request URL (wip) it's even r+ btw. Why didn't you want to ask for a review?

(In reply to Julien Wajsberg [:julienw] from comment #18) > Comment on attachment 8416434 [details] > GitHub pull request URL (wip) > > it's even r+ btw. Why didn't you want to ask for a review? We had several different proposals on that, so just wanted to get feedback first to be sure that behavior works for you in real life :)

Fixed nits, Travis is green. Also as we agreed Mochitest for "contenteditable & focus" will follow.

master: https://github.com/mozilla-b2g/gaia/commit/d5d8062dc251c57b3c4cc285ece3986ab83d43c2