1180149 - [Messages] Sometimes tapping on the send button does not work and merely hides the keyboard

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Julien Wajsberg [:julienw]]

STR:
1. Write a message, ready to be sent.
2. Tap on the "send" button.

Expected:
* The message is sent.

Actual:
* The message is not sent.

Happens very often for some users on Sony Z3C. But I couldn't really reproduce on Flame.

When I tried it seems that it happens when we tap more on the right of the button. We need to check whether the button is properly sized.

Comment 1

[Julien Wajsberg [:julienw]]

What happens:

1. we get the touchstart event.
2. the composer loses the focus.
3. the keyboard is removed.
4. the window is resized.
5. the touchend event happens on another element. (technically it's triggered on the same element because that's what the spec says, but the finger is not on the same element -- not sure how to see this programmatically)
=> the 'click' event is not generated

Possible solutions:
1. use touchstart or touchend instead of click. Caveat is that it won't be possible to cancel a button push by moving the finger.
2. somehow prevent losing the focus -- which could be a good thing if the user wants to send another message anyway. Maybe refocus the composer on touchstart?

Hey Tim, Oleg, wondering if one of you could have a better idea here...

Comment 2

[Julien Wajsberg [:julienw]]

I'll try to use https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-user-focus first :)

Comment 3

[Julien Wajsberg [:julienw]]

-moz-user-focus does not seem to work with touch events according to bug 894383... but after discussing with Vivien, we're not really sure this is actually the initial cause. Looks like edge gestures could be a part of the problem...

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Julien Wajsberg [:julienw] from comment #1)
> What happens:
> 
> 1. we get the touchstart event.
> 2. the composer loses the focus.
> 3. the keyboard is removed.
> 4. the window is resized.
> 5. the touchend event happens on another element. (technically it's
> triggered on the same element because that's what the spec says, but the
> finger is not on the same element -- not sure how to see this
> programmatically)
> => the 'click' event is not generated

(3) and (4) should exchange places here, and between (2) and (4) there are a 200ms timeout (from bug 1176926).

I think this *can* happen if (1) and (5) takes longer than 200ms, which is a really slow tap. To see (5) programmatically, use document.elementFromPoint().

> Possible solutions:
> 1. use touchstart or touchend instead of click. Caveat is that it won't be
> possible to cancel a button push by moving the finger.
> 2. somehow prevent losing the focus -- which could be a good thing if the
> user wants to send another message anyway. Maybe refocus the composer on
> touchstart?
> 
> Hey Tim, Oleg, wondering if one of you could have a better idea here...

I really really think we should just not remove the focus here, but I don't know if that would affect things like screen reader though.

Maybe it's time to investigate the possibility to give app explicitly control over keyboard state, like what iOS offered?

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Julien Wajsberg [:julienw] from comment #3)
> -moz-user-focus does not seem to work with touch events according to bug
> 894383... but after discussing with Vivien, we're not really sure this is
> actually the initial cause. Looks like edge gestures could be a part of the
> problem...

Can we still be able to turn off edge gestures and retest? Did we removed that flag already?

Comment 6

[Gabriele Svelto [:gsvelto] (PTO)]

On this topic I've got another related use-case that might be worth supporting. I dogfood with dual-SIMs all the time and it happens to me once in a while that I'll send a message using the non-default one. In this scenario this what I expect:

1. Compose message
2. Long-press the send button
3. Pick the desired SIM from the menu
4. Message is sent from the selected SIM

And this is what I get:

1. Compose message
2. Try long-pressing the send button
3. The keyboard closes, the send button is moved away, nothing else happens and I have to long-press

Comment 7

[Julien Wajsberg [:julienw]]

Etienne thinks he knows how to fix the issue :)

Comment 8

[Julien Wajsberg [:julienw]]

Let's see what happens after Etienne fixes the issue he sees; maybe we can do some things better also in the SMS app, but the current issue makes things difficult to debug.

Comment 9

[Etienne Segonzac (:etienne)]

(In reply to Julien Wajsberg [:julienw] from comment #7)
> Etienne thinks he knows how to fix the issue :)

Because I fixed it once already :) (bug 1063043)

Comment 10

[Oleg Zasypkin [:azasypkin]]

Hah can't believe bug 1063043 hit us again :) 

Please, let me know if it's and I'll see if I can create Messages integration test for that!

Comment 11

[GitHub Autolander Bot]

Attachment: [gaia] etiennesegonzac:bug-1180149 > mozilla-b2g:master

Comment 12

[Etienne Segonzac (:etienne)]

Comment on attachment 8629558 [details] [review]
[gaia] etiennesegonzac:bug-1180149 > mozilla-b2g:master

Lost a huge amount of time on this (not completely lost since I learned a lot about the sms app integration tests :)) but we can't cover this with an integration test.

To be more precise, we can't test touch-forwarding (from the system app to an app) on b2g-desktop since it requires APZC.

Anyway, here's a fix covered by an updated unit test :)

Comment 13

[Alberto Pastor [:albertopq]]

Comment on attachment 8629558 [details] [review]
[gaia] etiennesegonzac:bug-1180149 > mozilla-b2g:master

The code looks good to me, but I managed to still hide the keyboard clicking on the right edge. Asking julien for feedback to see if it helps with the initial STR.

Comment 14

[Etienne Segonzac (:etienne)]

Thanks, I'll land this (first?) patch by end of day today in order to hopefully have it part of the next Spark build. But I'll leave the bug open if we want to add some tweaks in the sms app itself.

Comment 15

[Julien Wajsberg [:julienw]]

Yes please land, unfortunately I don't have my dev Sony here so I won't be able to check before tomorrow...

Comment 16

[Etienne Segonzac (:etienne)]

System app part landed on master: https://github.com/mozilla-b2g/gaia/commit/51753dc49fb97afc8af938754af0c9106dbf1246

Comment 18

[(not reading bugmail) Nick Desaulniers [:\n]]

Attachment: fxos_texting.mov

Comment 19

[Julien Wajsberg [:julienw]]

Comment on attachment 8629558 [details] [review]
[gaia] etiennesegonzac:bug-1180149 > mozilla-b2g:master

Yes, this makes a huge difference.

Comment 20

[Julien Wajsberg [:julienw]]

I'm considering this fixed.

Please file a separate bug if some behavior does still look wrong.

When I tried, the only way I could make this happen again was when I had a multiline message and I tapped slightly too high on the button. Then the event fluffing logic thinks I'm tapping on the space above. But this is a lot less common than the previous bug.

Comment 21

[Julien Wajsberg [:julienw]]

bug 1181763 will help about the last issue I was mentioning in the previous comment.