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

RESOLVED FIXED

Status

Firefox OS
Gaia::System::Window Mgmt
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: julienw, Assigned: etienne)

Tracking

({foxfood})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
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...
Flags: needinfo?(timdream)
Flags: needinfo?(azasypkin)
(Reporter)

Comment 3

3 years ago
-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...
(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?
Flags: needinfo?(timdream)
(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?
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
(Reporter)

Comment 7

3 years ago
Etienne thinks he knows how to fix the issue :)
Assignee: nobody → etienne
Flags: needinfo?(azasypkin)
(Reporter)

Comment 8

3 years ago
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.
(Assignee)

Comment 9

3 years ago
(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)
(Assignee)

Updated

3 years ago
Component: Gaia::SMS → Gaia::System::Window Mgmt
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!
Created attachment 8629558 [details] [review]
[gaia] etiennesegonzac:bug-1180149 > mozilla-b2g:master
(Assignee)

Comment 12

3 years ago
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 :)
Attachment #8629558 - Flags: review?(apastor)
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.
Attachment #8629558 - Flags: review?(apastor)
Attachment #8629558 - Flags: review+
Attachment #8629558 - Flags: feedback?(felash)
(Assignee)

Comment 14

3 years ago
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.
(Reporter)

Comment 15

3 years ago
Yes please land, unfortunately I don't have my dev Sony here so I won't be able to check before tomorrow...
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1180774
(Reporter)

Comment 19

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

Yes, this makes a huge difference.
Attachment #8629558 - Flags: feedback?(felash) → feedback+
(Reporter)

Comment 20

3 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Reporter)

Comment 21

3 years ago
bug 1181763 will help about the last issue I was mentioning in the previous comment.
(Reporter)

Updated

3 years ago
See Also: → bug 1181763
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1178039
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1179492
You need to log in before you can comment on or make changes to this bug.