909821 - [Messages] Unable to send with Send button while keyboard is active

Status: RESOLVED DUPLICATE of bug 921928

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Allen Maxwell]

Attachment: SmsLog.txt

Description:
After user selects a recipient and types a messsage the user is unable to send message until keyboard is minimized.

Repro Steps:
1) Updated Buri to v1.2 Build ID: 20130827040201
2) Select SMS
3) Select a recipient
4) type a message
5) press send

Actual:
SMS message will not send

Expected:
SMS message send to desired recipient(s)

Environmental Variables
Build ID: 20130827040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/e42dce3209da
Gaia: 599214a0f41eece076dc83cd85f5b27f8cfe67f2
Platform Version: 26.0a1

Notes:
- SmsLog.txt
- User will be able to SMS message if keyboard is minimized

Comment 1

[Natalya Kot [:nkot]]

just to clarify the actual result:
> Actual:
> SMS message will not send

- an SMS eventually will be sent but the user has to tap "Send" button continuously, it might take up to 8-20 sec until the button will work

regression range:
Build ID: 20130807070231 - does NOT reproduce
Gecko: http://hg.mozilla.org/mozilla-central/rev/1fb5d14e8348
Gaia: 322389dddc458c3105978b7db6f485d8894cc487
Platform Version: 26.0a1

Build ID: 20130807161117 - Reproduces
Gecko: http://hg.mozilla.org/mozilla-central/rev/79b5c74ef97b
Gaia: 43557e5392ab37d4f8c1fa08184cf1541b249a54
Platform Version: 26.0a1

*US_20130823

Comment 2

[Rick Waldron [:rwaldron]]

Sorry, I don't know how or why the title was reverted.

Comment 3

[Jason Smith [:jsmith]]

Not a smoketest blocker - you can still send SMS with keyboard not active.

Comment 4

[Jason Smith [:jsmith]]

I don't think this is dom device interfaces issue either - this is a problem in the keyboard, which could be a problem either in Gaia::SMS, Gaia::Keyboard, or B2G::General.

Comment 5

[Rick Waldron [:rwaldron]]

(In reply to Jason Smith [:jsmith] from comment #4)
> I don't think this is dom device interfaces issue either - this is a problem
> in the keyboard, which could be a problem either in Gaia::SMS,
> Gaia::Keyboard, or B2G::General.

Cannot reproduce:
- gaia@0395f26211f9742b8bcaf1182851ab3413f89bda (master)
- b2g18 (built from b2g18 nightly on Sunday)


Allen, can you confirm whether or not this issue exists with the latest as listed above?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Rick Waldron from comment #5)
> (In reply to Jason Smith [:jsmith] from comment #4)
> > I don't think this is dom device interfaces issue either - this is a problem
> > in the keyboard, which could be a problem either in Gaia::SMS,
> > Gaia::Keyboard, or B2G::General.
> 
> Cannot reproduce:
> - gaia@0395f26211f9742b8bcaf1182851ab3413f89bda (master)
> - b2g18 (built from b2g18 nightly on Sunday)
> 
> 
> Allen, can you confirm whether or not this issue exists with the latest as
> listed above?

This isn't the right build information you are testing with. This bug is with 1.2, which is gaia master + mozilla central.

Comment 7

[Julien Wajsberg [:julienw]]

I wonder if the problem is not related with event fluffing (that I don't know very well, and I don't even know if that's enabled): the device thinks we tap on the keyboard, however, if we tap more in the same place, we eventually can tap the button.

Vivien, would you have directions for this ?

Comment 8

[Julien Wajsberg [:julienw]]

Talked with vivien, I'll try to disable event fluffing on my phone and see if this fixes the problem in this case.

Comment 9

[Julien Wajsberg [:julienw]]

So this is very subjective, but it looks like disabling event fluffing helps.

Also, I can't reproduce the problem on Keon (same gecko, same gaia). I don't know what that means. Maybe we don't enable event fluffing on all platforms ?

Comment 10

[Julien Wajsberg [:julienw]]

So it happens in Keon but it's more difficult to trigger, maybe because the coords given by the driver are higher in the page ? Vivien thinks :mwu might know about this.

And he thinks that Timothy would know about the event fluffing part.

Thanks all

Comment 11

[Timothy Nikkel (:tnikkel)]

(In reply to nkot from comment #1)
> just to clarify the actual result:
> > Actual:
> > SMS message will not send
> 
> - an SMS eventually will be sent but the user has to tap "Send" button
> continuously, it might take up to 8-20 sec until the button will work
> 
> regression range:
> Build ID: 20130807070231 - does NOT reproduce
> Gecko: http://hg.mozilla.org/mozilla-central/rev/1fb5d14e8348
> Gaia: 322389dddc458c3105978b7db6f485d8894cc487
> Platform Version: 26.0a1
> 
> Build ID: 20130807161117 - Reproduces
> Gecko: http://hg.mozilla.org/mozilla-central/rev/79b5c74ef97b
> Gaia: 43557e5392ab37d4f8c1fa08184cf1541b249a54
> Platform Version: 26.0a1
> 
> *US_20130823

This corresponds to http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1fb5d14e8348&tochange=79b5c74ef97b

And I don't see any event fluffing related changes in there, so I'm guessing it's not event fluffing related.

(In reply to Julien Wajsberg [:julienw] from comment #9)
> So this is very subjective, but it looks like disabling event fluffing helps.
> 
> Also, I can't reproduce the problem on Keon (same gecko, same gaia). I don't
> know what that means. Maybe we don't enable event fluffing on all platforms ?

I don't think we change whether event fluffing is enabled or not based on the the phone hardware.

Tracing what happens during a failed press on the send button in this function http://mxr.mozilla.org/mozilla-central/source/layout/base/PositionedEventTargeting.cpp?force=1#248 might be helpful if the problem is there.

Comment 12

[Julien Wajsberg [:julienw]]

The gaia changelog is https://github.com/mozilla-b2g/gaia/compare/322389dddc458c3105978b7db6f485d8894cc487...43557e5392ab37d4f8c1fa08184cf1541b249a54

Nothing seems related here either.

> I don't think we change whether event fluffing is enabled or not based on the phone hardware.

Yep I saw the problem is on keon too after all, even if for some reason it's not so painful.

Comment 13

[Timothy Nikkel (:tnikkel)]

(In reply to Julien Wajsberg [:julienw] from comment #12)
> The gaia changelog is
> https://github.com/mozilla-b2g/gaia/compare/
> 322389dddc458c3105978b7db6f485d8894cc487...
> 43557e5392ab37d4f8c1fa08184cf1541b249a54
> 
> Nothing seems related here either.

I only checked the mozilla-central changeset list for event fluffing related changes, not changes that might have caused this.

Comment 14

[Michael Wu [:mwu]]

I don't know what's going on here.

Comment 15

[Julien Wajsberg [:julienw]]

So I think the problem here is more related to how the touch driver handles touch.

Comment 16

[Joe Cheng [:jcheng] (please needinfo)]

qawanted to help confirm this

Comment 17

[isabelrios]

Hi,
Checking with unagi device, v1.2 cannot reproduce, just tapping once on Send while the keybord is active works fine
Gecko-8c76bfd
Gaia-239332a
With a buri device, v1.2 too, it does not work the same way. It is necessary to press twice or more times to get the SMS sent.

Comment 18

[Julien Wajsberg [:julienw]]

Isabel, here are some more questions for you:

* can you try also on Buri 1.1 ?
* do you "feel" (for example on the keyboard) that there is an offset when you compare where you tap and where the device reacts ?

Thanks a lot !

Comment 19

[isabelrios]

Hi Julien,
> * can you try also on Buri 1.1 ?
Yes,just tried and I would say the bahaviour is better there.

> * do you "feel" (for example on the keyboard) that there is an offset when
> you compare where you tap and where the device reacts ? 
It is difficult to say..maybe an small one above all seen with the keys in the borders

Comment 20

[Julien Wajsberg [:julienw]]

So:
* disabling event fluffing definitely helps
* disabling words suggestion definitely helps too

Comment 21

[Julien Wajsberg [:julienw]]

btw I disable event fluffing using this in my build/custom-prefs.js :

  user_pref('ui.mouse.radius.enabled', false);
  user_pref('ui.touch.radius.enabled', false);

Comment 22

[Julien Wajsberg [:julienw]]

Attachment: SMS app layout for reference

Comment 23

[Julien Wajsberg [:julienw]]

Timothy,

I investigated a little more with Vivien, and we have a possible explanation. Please see attachment 811126 [details] for reference.

As you probably know, the keyboard is a separate app, as an iframe, really covers the whole screen. The above transparent part has "pointer-events: none" while the below opaque part has "pointer-events: auto". Also, the keyboard app has "mozpasspointerevents".

Therefore, our thought is that when touching the send button, the event first encounters the keyboard frame, find the word suggestion list element, and stops there.

Do you think this is possible ?

Vivien thinks that remoting the keyboard app in bug 816874 might fix this bug, so we could wait that that bug lands (seems like it will land soon) and test again ?

Comment 24

[Timothy Nikkel (:tnikkel)]

Thanks for the clear explanation and screenshot.

(In reply to Julien Wajsberg [:julienw] from comment #23)
> As you probably know, the keyboard is a separate app, as an iframe, really
> covers the whole screen. The above transparent part has "pointer-events:
> none" while the below opaque part has "pointer-events: auto". Also, the
> keyboard app has "mozpasspointerevents".

Ok. The "mozpasspointerevents" part is not relevant though until the keyboard app is OOP though, right?

So the net effect of this is that the pointer-events: none on the top part means it should not be in the returned list of frames from nsLayoutUtils::GetFramesForArea, and won't be considered an event target.

> Therefore, our thought is that when touching the send button, the event
> first encounters the keyboard frame, find the word suggestion list element,
> and stops there.

That could happen. I would think that we would keep going after finding the word suggestion element, but maybe the code in GetClosest in layout/base/PositionedEventTargeting.cpp either rejects the send button or thinks it is a worse match.

Tracing through the loop in GetClosest when we mistarget a touch to see why we reject the send button exactly would be helpful.

> Vivien thinks that remoting the keyboard app in bug 816874 might fix this
> bug, so we could wait that that bug lands (seems like it will land soon) and
> test again ?

If there is a bug here then we should probably fix it even if making the keyboard OOP means we don't see that particular bug in this case. It'll probably come up in another situation, I think our event fluffing code could still use improving.

Let me know if this is helpful or you need more info.

Comment 25

[Joe Cheng [:jcheng] (please needinfo)]

triage: users seem not blocked from sending a message. please ask for approval for landing into v1.2

Comment 26

[Julien Wajsberg [:julienw]]

Joe, I really think this should be fixed, as this will be very annoying to our users.

Comment 27

[Joe Cheng [:jcheng] (please needinfo)]

triage: leave it as koi? before we get more information. this was minused base on comment 17 saying that it is not reproducible on unagi and only reproducible somteimes on a buri. QAWANTED to understand more on the reproducibility of this bug so i can be decided better.

meanwhile, Julien, do we have further insights into why this device specific? (it seems)
 thanks

Comment 28

[Julien Wajsberg [:julienw]]

I think this is not device specific, but different device drivers makes it more apparent by adding an offset (or not) to the touch coordinates. The offset adds other problems in other parts of Gaia BTW.

This means that when the user thinks he's touching the center of the send button, what the app receives is that he's touching the top of the send button, which does not trigger the bug then. At least that's my wild guess. But also this offset makes it more difficult to eg touch the back button correctly (at least for me).

Comment 29

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #27)
> triage: leave it as koi? before we get more information. this was minused
> base on comment 17 saying that it is not reproducible on unagi and only
> reproducible somteimes on a buri. QAWANTED to understand more on the
> reproducibility of this bug so i can be decided better.
> 
> meanwhile, Julien, do we have further insights into why this device
> specific? (it seems)
>  thanks

Unagi is not a target 1.2 device and therefore, should not be used to justify triage decisions. You need to use production devices to establish a triage decision. Buri is a target device. If it turns this out reproduces on Buri and not a different production device, then we probably need to talk to the Buri guys about fixing this on their end.

Comment 30

[Joe Cheng [:jcheng] (please needinfo)]

(In reply to Jason Smith [:jsmith] from comment #29)
> 
> Unagi is not a target 1.2 device and therefore, should not be used to
> justify triage decisions. You need to use production devices to establish a
> triage decision. Buri is a target device. If it turns this out reproduces on
> Buri and not a different production device, then we probably need to talk to
> the Buri guys about fixing this on their end.

agree. is it possible that we confirm this on all 3 existing devices? QAWANTED for Buri/Leo/Ikura

Comment 31

[Natalya Kot [:nkot]]

Tested on Buri, Leo and Inari – the issue can be reproducible on all of them.

It is much easier to reproduce on Buri. On Leo and Inari "Send" button becomes unresponsive only after selecting/tapping in word suggestions.

Comment 32

[Julien Wajsberg [:julienw]]

Vivien told me that bug 921928 will probably fix this too.

Comment 33

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] from comment #32)
> Vivien told me that bug 921928 will probably fix this too.

Why is this renomed?

Comment 34

[Julien Wajsberg [:julienw]]

This is a mistake, sorry for this dear triagers.

Comment 35

[Julien Wajsberg [:julienw]]

Yep, this is fixed now, then I'm duping this bug to bug 921928.