SMS app is having a painfull bug that prevent using SMS for chatting with friend by sending/receiving many messages in a short period of time. Steps to reproduce: - Launch the sms app - open a thread - focus the message input, the keyboard appear - Type something in the text message - Tap on send Actual result: - The keyboard disappear and the input loose focus. Expected result: - The keyboard stays and the input keeps the focus so that we can still type a new message. I really don't think any platform work will fix that issue. As clicking on a button will give the focus to the button and the keyboard will disappear. So I don't think bug 766066 will fix that issue. I haven't been able to apply bug 766066's patch and test it.

Here is same patch than bug 810304, only with sms app fix (i.e. without window manager fix).

[:ochameu] As we are talking in bug https://bugzilla.mozilla.org/show_bug.cgi?id=810304#c25 this behaviour is easily reproducible in all apps in the platform (not only in SMS), so probably the bug would be a 'System' or 'Keyboard' bug. That's why we need to identify where are the bugs or the bug and try to fix it without standalone workarounds in every app. Vivien suggested how to reproduce it here: https://bugzilla.mozilla.org/show_bug.cgi?id=810304#c12 and there are other scenarios here: https://bugzilla.mozilla.org/show_bug.cgi?id=810304#c14 From my point of view, bug 821414 sounds like a standalone 'workaround' for getting the expected result, but probably the problem is not there and, as [:alive] and [:ttaubert] told you, there are more issues behind this weird behaviour of Keyboard. However I will check your code and I will try to come back with more feedback.

Can we have UX input here?

Tested with steps provided. Actual result: - The keyboard disappear, the input loose focus and the message is not sent. Alexandre, if your patch solves the non sent message I would block on this.

(In reply to dscravaglieri from comment #4) > Tested with steps provided. > > Actual result: > - The keyboard disappear, the input loose focus and the message is not sent. For me, the message is sent, but the keyboard disappear. It might be because I'm using mozilla-central instead of beta. > > Alexandre, if your patch solves the non sent message I would block on this. So I have no idea if it fix such thing as I'm not able to reproduce it.

(In reply to Alexandre Poirot (:ochameau) from comment #5) > (In reply to dscravaglieri from comment #4) > > Tested with steps provided. > > > > Actual result: > > - The keyboard disappear, the input loose focus and the message is not sent. > > For me, the message is sent, but the keyboard disappear. It might be because > I'm using mozilla-central instead of beta. What happen if you don't type fast on the button, by holding your finger and releasing for example?

(In reply to Vivien Nicolas (:vingtetun) from comment #6) > What happen if you don't type fast on the button, by holding your finger and > releasing for example? Without this patch, exact same thing than bug 810304 comment 12. In this bug I just didn't wanted to focus on the touch'n move issue, but just the simple button press. But my patch fix that too.

(In reply to Vivien Nicolas (:vingtetun) from comment #6) > (In reply to Alexandre Poirot (:ochameau) from comment #5) > > (In reply to dscravaglieri from comment #4) > > > Tested with steps provided. > > > > > > Actual result: > > > - The keyboard disappear, the input loose focus and the message is not sent. > > > > For me, the message is sent, but the keyboard disappear. It might be because > > I'm using mozilla-central instead of beta. > > What happen if you don't type fast on the button, by holding your finger and > releasing for example? Then the keyboard disappears and you need to click on send button again to send the SMS. This should be fixed when bug 810304 is fixed. I'd suggest we close this bug as it is a duplicated of bug 810304 and open a new one with the behaviour David and Vivien described that depends on bug 810304 to be solved.

Comment on attachment 691925 [details] Pull request 7003 (In reply to Daniel Coloma:dcoloma from comment #8) > (In reply to Vivien Nicolas (:vingtetun) from comment #6) > > (In reply to Alexandre Poirot (:ochameau) from comment #5) > > > (In reply to dscravaglieri from comment #4) > > > > Tested with steps provided. > > > > > > > > Actual result: > > > > - The keyboard disappear, the input loose focus and the message is not sent. > > > > > > For me, the message is sent, but the keyboard disappear. It might be because > > > I'm using mozilla-central instead of beta. > > > > What happen if you don't type fast on the button, by holding your finger and > > releasing for example? > > > Then the keyboard disappears and you need to click on send button again to > send the SMS. This should be fixed when bug 810304 is fixed. I'd suggest we > close this bug as it is a duplicated of bug 810304 and open a new one with > the behaviour David and Vivien described that depends on bug 810304 to be > solved. I think a lot of misunderstanding comes from bug 810304 not beeing clear enough. Alexandre has open this bug which target a very specific problem for this particular app so it feels reasonable to me to keep it as if since the other bug is a different bug if I trust Tim Taubert. About the fix Alexandre propose for this patch. There is no keyboard patches coming that will fix/prevent the focus to be given to an element when the user click on it. Actually such a fix will prevent you to get rid of the keyboard and breaks a lot of things in all applications... The only solution if you want a particular button of your application to not steal the focus when the user click on it is to *do some specific code* for it. Sounds 100% normal to me and the patch sounds sane. Actually this is the same code that is done for the keyboard application itself when the user press a key. r+.

Comment on attachment 691925 [details] Pull request 7003 a=me since this fix a real usability issue with a very simple/easy fix. People will be able to use the sms app and have discussions again (while the other window manager bug that Alexandre tried to land in the other bug will land too).

Alexandre can you fix the small comment I made so we can land this code?

Can we change the description of the bug so it is clear what the patch is solving? The initial description did not mention the SMS is not sent.

Done.

Landed: https://github.com/mozilla-b2g/gaia/commit/71f4a097c0e7c5df4bdf830e561834a3643cf9ff

[:vingetun] As we have talk several times, it's a non-written rule to request a review for one of the owner of the app at least in order to check that the code it's working properly. No rush for merging, no rush for making patches that does not solve bugs. This is reopened because, as I told you, this is EASY reproducible in other apps and it's a Keyboard problem. I dont want more workarounds at least in the SMS app, and overall when it's 'solving' no bug. Other scenario: - Open FTU - Go though the steps 'Wifi' step - Choose one Wifi with password - Type the password - Press 'Join' without release your finger What's up? Keyboard dissapears, and when you release the finger the click event takes NO effect (the same as in 'send' button in SMS App) Expected: Keyboard doesnt have to dissapear in every 'mouseDown' event. Keyboard should be there until 'click' was done completely. Please make a backout of this PR and focus on the real problem tracked here https://bugzilla.mozilla.org/show_bug.cgi?id=810304 . Thanks.

Changing the behaviour of the keyboard will drive us into troubles. This patch is accurate.

If we are landing this, is bug 810304 still a blocker or should it be moved out?

(In reply to Dylan Oliver [:doliver] from comment #18) > If we are landing this, is bug 810304 still a blocker or should it be moved > out? I ask for clarification in bug 810304 because is it not 100% clear what it is about.

(In reply to Dylan Oliver [:doliver] from comment #18) > If we are landing this, is bug 810304 still a blocker or should it be moved > out? It is, but it's really an sms-centric version of bug 819595 AFAICT. Since both are fixed by bug 823619 it doesn't really matter how we do the accounting.