818623 - [Dialer] if an outside call hangs up and calls again, the second call does not ring nor give the incoming overlay

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect, P1)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

## Environment :
Unagi phone, build 2012-12-4

## Repro :
1. make sure that the phone is unlocked
2. call b2g phone on another device
3. hang up
4. immediately call b2g phone again

## Expected :
1. another incoming call from the same number, overlay should appear

## Actual :
1. overlay doesn't appear, no ringing

## Note :
1. I have had friends that hang up and called me again immediately like this.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

maybe related to bug 811655; note if the phone is locked, it will get the call.  locked screen state versus nonlocked screen state seems to show different results.

Comment 2

[alberto.pastor]

After investigating a little bit, it seems that telephony.calls.length == 0 every time the Dialer is open, and that's why the second time you call it fails. In fact, it will fail on firts time as well if you previously open the Dialer.

This line is the one that closes the oncall when telephony.calls.length == 0

https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/dialer.js#L304

I would  say that's a platform issue, but I don't know how that is possibly related to the fact the Dialer app is open or closed.

CCing some people to get new ideas.

Jose Antonio, any idea in the Backend side?

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Alberto Pastor from comment #2)
> After investigating a little bit, it seems that telephony.calls.length == 0
> every time the Dialer is open, and that's why the second time you call it
> fails. In fact, it will fail on firts time as well if you previously open
> the Dialer.
> 
> This line is the one that closes the oncall when telephony.calls.length == 0
> 
> https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/
> js/dialer.js#L304
> 
> I would  say that's a platform issue, but I don't know how that is possibly
> related to the fact the Dialer app is open or closed.
> 
> CCing some people to get new ideas.
> 
> Jose Antonio, any idea in the Backend side?
In bug 812368, we sent out 'telephony-new-call' system message right at the moment when we receive a ringing call notification from the modem, for solving bug 812059, though at that time we do not have complete information about the new call. We think it's okay without complete call info because we just want to start bringing up the dialer content process while the modem is getting ready to tell us more. However, when the dialer is open, the DOM may not acquire any call. 

Also, in bug 811192, I added https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/dialer.js#L304 but I realized that I should be more careful of the condition for 'exitCallScreen'. I will say this is rather a gaia issue and IMHO, the possible approach could be listening to 'callschanged' event first and then checking 'telephony.calls.length' to make sure that 'the zero calls length' results from a call ending, instead of the DOM being not ready. How do you think about this? Thanks :)

Comment 4

[Etienne Segonzac (:etienne)]

Hey Alberto,

I'm still unable to reproduce this, still happening for you?

Comment 5

[Alex Keybl [:akeybl]]

If reproducible, this would likely be a P1 certification blocker. If not, Resolved/WFM.

Comment 6

[alberto.pastor]

I'm still able to reproduce it with last gecko/gaia. Someone in qa can take a look?

In the maintime, I'm going to work in a quickfix in gaia for not depending on telephony.calls.length in the way we are doing right now as hsinyi was suggesting.

Thanks!

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Alberto Pastor from comment #6)
> I'm still able to reproduce it with last gecko/gaia. Someone in qa can take
> a look?
> 

Lastest == m-c + master ? Can you include the changeset you use to reproduce, we fail to do it here :)

Comment 8

[Dietrich Ayala (:dietrich)]

Driving retriage: Continued problems reproducing, blocking-. If we get reports from other sources able to reproduce w/ steps, please re-nominate.

Comment 9

[David Flanagan [:djf]]

I can reproduce this, exactly as described in the STR.

I can make the bug go away if I kill the dialer app after the first call.

This is with a gecko build from vingtetun.  I don't know the details of the build.

Renominating.

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to David Flanagan [:djf] from comment #9)
> I can reproduce this, exactly as described in the STR.
> 
> I can make the bug go away if I kill the dialer app after the first call.
> 
> This is with a gecko build from vingtetun.  I don't know the details of the
> build.
> 
> Renominating.

This is a build against m-c and I can not reproduce it using b2g18.

Comment 11

[David Flanagan [:djf]]

I can also reproduce this with the phone asleep.

With the phone sleeping, the first call rings normally, and I answer and hang up.  Then, I put the phone back to sleep.  Then I call again.  This time the phone wakes up but does not diplay the answer controls.  Sometimes, there is a partial ring, less than 1 second of the ring tone, but then silence and now way to answer.

When I hang up on the other phone, the device goes back to sleep, so it seems to know that the call has disconnected.

If I wake the phone up and go to the homescreen and kill the dialer app, then the phone starts working again.

Comment 12

[David Flanagan [:djf]]

Even if this only occurs in m-c, I think we need to understand it and fix it so it doesn't come back and bite us later in the product cycle.

The fact that killing and restarting the Gaia app fixes the bug makes me think that we can at least guard against or workaround this bug in Gaia.

Comment 13

[David Flanagan [:djf]]

I've also reproduced this bug with out the hang up step.  If I answer the first call and then disconnect from either phone, I sometimes don't receive the second call. Nothing seems consistent, though.

Comment 14

[alberto.pastor]

Hi,

I think the bug is when receiving a call and the dialer is already open. It doesn't matter if you answered/hanged up the previous call. As I said in https://bugzilla.mozilla.org/show_bug.cgi?id=818623#c2 , we are checking  if telephony.calls.length > 0, and for some strange reason, it returns 0 when the dialer is already open.

Comment 15

[Etienne Segonzac (:etienne)]

(In reply to Alberto Pastor from comment #14)
> Hi,
> 
> I think the bug is when receiving a call and the dialer is already open. It
> doesn't matter if you answered/hanged up the previous call. As I said in
> https://bugzilla.mozilla.org/show_bug.cgi?id=818623#c2 , we are checking  if
> telephony.calls.length > 0, and for some strange reason, it returns 0 when
> the dialer is already open.

We are checking telephony.calls.length in the app frame (and not the attention screen) to avoid this (or try to avoid it :))

Maybe we need another work around while waiting for bug 823958.

Comment 16

[Francisco Jordano [:arcturus] [:francisco]]

Hi all,

I'm unable to reproduce this after Etienne change in bug 822722. I've tried several cases and both, me and Alberto, are not able to reproduce with the current gaia code and latest from m-c.

If we comment this line:
https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/dialer.js#L105

We will be able to reproduce it, constantly.

So will close it as WFM, cause the workaround in gaia seems to be working. Of course waiting for bug 823958 to be solved ;)

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Something seemed to have gotten fixed.  I am guessing from comment 16:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/f2460bf17811
Gaia   693a1b8e123eb9e8084231692cc8d89eba182be5
BuildID 20130114230201
Version 18.0

Otoro

Comment 18

[Gene Lian (I already quit Mozilla)]

Sorry, we need to reopen this. Both m-c or b2g18 build doesn't work.

STR
==============================
  1. Call b2g phone from another mobile.
  2. Hang up.
  3. Call again.

Expected
==============================
  The second call should ring.

Actual
==============================
  The second call doesn't ring.

Note
==============================
  If the Dialer app doesn't launch then the call will always ring. It doesn't ring only when the Dialer app is alive. That's why the second call will fail because the Dialer app has been launched by the first call. Therefore, if you kill the Dialer app after the first call, then the second call will succeed to ring.

Comment 19

[Gene Lian (I already quit Mozilla)]

(In reply to Gene Lian [:gene] [:clian] from comment #18)
> Sorry, we need to reopen this. Both m-c or b2g18 build doesn't work.

Correction: after more testings with Hsin-Yi, the b2g18 is working but not for m-c. The most weird thing is, if this is a Gaia issue, why it doesn't work for m-c? Also, it doesn't meet the comment #16, which was saying the m-c was working well.

Not sure if we need to nominate for tef+ if it doesn't affect b2g18. However, I think this bug is horrible and definitely needs too be fixed even for m-c, because it potentially means my friend cannot reach me anymore after our first chat.

Comment 20

[alberto.pastor]

Is not a gaia issue. We can try to workaround it, but the real problem comes from Bug 823958.

I'm not sure why now is working with b2g18 and not m-c, but what is clear is that the problem is we try to access some information that returns null, not because it is null but because the info is not ready yet. Apparently the info is ready sooner depending on the build you use.

In my opinion, this is a serious problem. We need to find a way to workaround it in Gaia in the meanwhile Bug 823958 is not fixed.

(In reply to Gene Lian [:gene] [:clian] from comment #19)
> (In reply to Gene Lian [:gene] [:clian] from comment #18)
> > Sorry, we need to reopen this. Both m-c or b2g18 build doesn't work.
> 
> Correction: after more testings with Hsin-Yi, the b2g18 is working but not
> for m-c. The most weird thing is, if this is a Gaia issue, why it doesn't
> work for m-c? Also, it doesn't meet the comment #16, which was saying the
> m-c was working well.
> 
> Not sure if we need to nominate for tef+ if it doesn't affect b2g18.
> However, I think this bug is horrible and definitely needs too be fixed even
> for m-c, because it potentially means my friend cannot reach me anymore
> after our first chat.

Comment 21

[Francisco Jordano [:arcturus] [:francisco]]

As Alberto says in comment 20 this is a problem related to the backend.

It's already workarounded in gaia, the more we try to solve probably we will be adding more problems. I've requested the QA Telefonica team to try b2g18 backend to be tested in unagi, otoro and the two developers phones announced recently.

If the problem cannot be reproduced we would like the tef+ (now implicit as a bb+) to be removed and fixed in previous releases via bug 823958

Comment 22

[isabelrios]

From QA Telefonica team we can say that the problem only appeared once on unagi but never again with the same sample or others. We tried to reproduce the bug with otoro, unagi and the two developers phones.
Don't know the conditions when the problem happened or how to reproduce it again.

Naoki, since you saw this problem at the first place, or Gene, as you reopened the bug, could you please try to reproduce it with the latest build? Thanks

Thanks

Comment 23

[isabelrios]

More info: Tested with all the devices with b2g18

Comment 24

[Alex Keybl [:akeybl]]

Not a blocker until it's an issue on b2g18

Comment 25

[Gene Lian (I already quit Mozilla)]

(In reply to Isabel Rios [:isabel_rios] from comment #22)
> Naoki, since you saw this problem at the first place, or Gene, as you
> reopened the bug, could you please try to reproduce it with the latest
> build? Thanks

Yes, we don't have this problem on b2g18. It only happens on m-c.

Comment 26

[Gene Lian (I already quit Mozilla)]

I think we got the root cause. Bug 812368 produces this bug, which has been checked in into m-c but not for b2g18. However, that bug is a tef+ one and waiting for check-in. We need to fix the bug here or provide a follow-up for bug 812368, so that bug 812368 can safely be landed to b2g18 as well.

Do we have any Gaia-solution for this second-call problem?

Comment 27

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Attachment: Pull request to gaia

'exitCallScreen' when we got notified there's no call.

Comment 28

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 705751 [details]
Pull request to gaia

Hi Etienne,

The main concept is that, I think we should be more careful before asking callScreen to be closed. We open call screen when there's a new call, and it shall be to close the screen when we got notification that there's no call. This patch works well even with Bug 812368 applied to b2g-18.

Could you help review this? Thank you :)

Comment 29

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

this bug blocks bug 812368 (which is TEF+)
once bug 812368 lands, status-b2g18 will become affected. this fix needs to land on b2g18!

Comment 30

[Etienne Segonzac (:etienne)]

Comment on attachment 705751 [details]
Pull request to gaia

Nothing guarantees us that the callScreen will be loaded by the time we get notified that there is no call right? And then we won't get anymore notifications :/

That said worst case scenario we get a callScreen with no call and the user has to press the hang-up button to get out. Which is better than missing a call and less likely to happen. So feel free to land this.

Comment 31

[Gene Lian (I already quit Mozilla)]

Could any Gaia members help with the merge? :) When it's done, then it's safe to land bug 812368, which is a tef+ and rushing to be landed today.

Comment 32

[Francisco Jordano [:arcturus] [:francisco]]

Landed

https://github.com/mozilla-b2g/gaia/commit/63e87f0bbd4c1bc5ac5d2a372acae8e22f4beaa3

Comment 33

[Francisco Jordano [:arcturus] [:francisco]]

Hi this bug has been nominated again to be picked for branch 1.0.0.

It was a tef+ before and will be a problem once that bug 812368 lands in b2g18.

Thanks

Comment 35

[Alex Keybl [:akeybl]]

Marking b2g18 as affected due to bug 834350 and comment 33. We need to uplift this today. I'm talking with jhford about ensuring this makes it onto the v1-train and v1.0.0 branches.

Comment 36

[James Lal [:lightsofapollo]]

uplifted...

Comment 37

[Walter Chen[:ypwalter][:wachen]]

Verified fixed in pvt b2g18 user build.

Gaia:
  Rev     7cacbcb8042b49d816a34de8e9767dcedefa6d84
  B-D     2013-01-25 02:57:10
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18/rev/32c2cc3e19ff
BuildID   20130124140859
Version   18.0

Comment 38

[mdaniloff]

Smoketest regression
Verified fixed Build 20130125070201
gecko:94a2d6fcdfde
gaia:c814c79378b9
user can recieve incoming calls succesfully
Reprod: 10/10 on 4 devices

Comment 39

[Lukas Blakk [:lsblakk] use ?needinfo]

Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.

Comment 41

[Octavian Damiean [:mainerror]]

We have a regression. I can reproduce the exact same bug using the described steps above and the workaround in comment #9 works too.

Hardware Revision: qcom
Platform Version: 24.0a1
Build Identifier: 20130527104420
Git Commit Info: ca0af90c