Closed
Bug 996900
Opened 11 years ago
Closed 11 years ago
[Messaging] Bring up keyboard when user taps in the middle of the Messaging screen.
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect)
Tracking
(feature-b2g:2.0, tracking-b2g:backlog, b2g-v2.0 fixed)
RESOLVED
FIXED
2.0 S2 (23may)
Tracking | Status | |
---|---|---|
b2g-v2.0 | --- | fixed |
People
(Reporter: swilkes, Assigned: azasypkin)
References
Details
(Whiteboard: ux-most-wanted, user-research)
Attachments
(1 file)
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.
Comment 1•11 years ago
|
||
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.
Flags: needinfo?(swilkes)
Reporter | ||
Comment 2•11 years ago
|
||
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!
Flags: needinfo?(swilkes)
Comment 3•11 years ago
|
||
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.
Flags: needinfo?(ofeng)
Updated•11 years ago
|
Blocks: sms-visual-refresh
Comment 5•11 years ago
|
||
(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.
Flags: needinfo?(ofeng)
Comment 6•11 years ago
|
||
Omega, we would do this only in the "new message" panel obviously, not in a thread panel with messages.
Flags: needinfo?(ofeng)
Comment 7•11 years ago
|
||
(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.
Flags: needinfo?(ofeng)
Comment 8•11 years ago
|
||
Hey Oleg, this is part of Visual Refresh and actionnable right now, if you want it :)
Assignee | ||
Comment 9•11 years ago
|
||
(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!
Flags: needinfo?(azasypkin)
Assignee | ||
Comment 10•11 years ago
|
||
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
Assignee: nobody → azasypkin
Status: NEW → ASSIGNED
Flags: needinfo?(azasypkin) → needinfo?(felash)
Assignee | ||
Updated•11 years ago
|
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Assignee | ||
Comment 11•11 years ago
|
||
Attaching WIP patch.
Comment 12•11 years ago
|
||
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.
Flags: needinfo?(felash) → needinfo?(ofeng)
Comment 13•11 years ago
|
||
(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.
Flags: needinfo?(ofeng)
Comment 14•11 years ago
|
||
(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?
Flags: needinfo?(ofeng)
Comment 15•11 years ago
|
||
(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.
Flags: needinfo?(ofeng)
Assignee | ||
Comment 16•11 years ago
|
||
Comment on attachment 8416434 [details] [review]
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!
Attachment #8416434 -
Flags: feedback?(felash)
Updated•11 years ago
|
blocking-b2g: --- → backlog
Comment 17•11 years ago
|
||
Comment on attachment 8416434 [details] [review]
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 !
Attachment #8416434 -
Flags: feedback?(felash) → feedback+
Comment 18•11 years ago
|
||
Comment on attachment 8416434 [details] [review]
GitHub pull request URL (wip)
it's even r+ btw. Why didn't you want to ask for a review?
Attachment #8416434 -
Flags: review+
Assignee | ||
Comment 19•11 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #18)
> Comment on attachment 8416434 [details] [review]
> 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 :)
Assignee | ||
Comment 20•11 years ago
|
||
Fixed nits, Travis is green. Also as we agreed Mochitest for "contenteditable & focus" will follow.
Keywords: checkin-needed
Comment 21•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S2 (23may)
Updated•11 years ago
|
Keywords: checkin-needed
Updated•11 years ago
|
status-b2g-v2.0:
--- → fixed
Updated•11 years ago
|
feature-b2g: --- → 2.0
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•