1082022 - [Dialer][Call Screen] Call is placed on Hold when phone proximity sensor turns off the screen.

Status: RESOLVED FIXED

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

Description

[Martin Shuman [:Marty]]

Attachment: logcat_Call_Hold.txt

Description:
As soon as I raised the device to the side of my head after answering the phone, the call would be placed on Hold.  I could Resume the call, and successfully use Speaker Phone, but any time I returned the device to the side of my head, and the Proximity Sensor turned off the screen, the call would be placed on Hold again.

I wasn't able to determine exact STR for this issue.  After restarting the device, this issue has not occurred again, leading me to believe that my phone had somehow fallen into a state where this issue occurs, but I am not sure the steps of how to enter that state.

This is my basic sequence of events where this occurred:
-I OTA'd from build 20141010040202.
-I received 2 calls while browsing the web, no problems experienced.
-I let the device lock itself after 1 minute of inactivity while the browser was the active app.
-I received a call at the lockscreen, and the proximity sensor began placing my phone on hold.
-This issue occurred on my next two received calls, one from the lockscreen, one when the device was unlocked.
-I restarted the device, and the issue no longer occurred, whether the device was locked or unlocked.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141010040202
2) OTA to build 20141013040202.
3) Open the Browser app, navigate to a webpage, then let the phone fall asleep.
4) Receive a call from the lockscreen
  
Actual:
Device put the call on Hold when proximity sensor shut of the screen.
  
Expected: 
Call remains open when the proximity sensor shuts off the screen.
  
Environmental Variables:
Device: Flame 2.2 Master (319MB)
BuildID: 20141013040202 (Full Flash)
Gaia: 3b81896f04a02697e615fa5390086bd5ecfed84f
Gecko: f547cf19d104
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
  
Repro frequency:  1/4
See attached: screenshot, logcat

Comment 1

[Martin Shuman [:Marty]]

Attachment: Call_Hold_Screenshot.png

Comment 2

[Peter Bylenga [:PBylenga]]

Steps-wanted to find better STR's for this issue.

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

I've narrowed down the STR to the following (the wait time before DUT picks up the call seems to be the key to repro):

STR:
0) Unplug DUT from USB
1) Have another phone call DUT
2) After the ringtone plays for about 7 seconds (the default ringtone played once), DUT picks up phone call
3) Cover the proximity sensor for 3 seconds, then uncover it

- Observe the call has been put on hold.

Repro rate: 3/3

Device: Flame 2.2 Master
BuildID: 20141013104008
Gaia: 2a536e4df82410178d8440cc710d8f838a95a0b9
Gecko: 78a4540b0a9c
Version: 36.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Comment 4

[Pi Wei Cheng [:piwei] (inactive)]

Forgot to add this issue is reproducible on both full flash and shallow flash, on 319MB mem (I haven't tried 512)

Comment 5

[Joshua Mitchell (Inactive)]

Excellent Steps-Wanted work - let's go ahead and get a branch check on this.

Comment 6

[Pi Wei Cheng [:piwei] (inactive)]

This issue does NOT occur on Flame 2.1 and Flame 2.0.

Observed behavior: Call does not get put on hold after following steps.

Device: Flame 2.1 (shallow flash)
BuildID: 20141013101509
Gaia: d51956f84ebec0dd8998654f01f9f24fe8527f51
Gecko: a0647b2686eb
Version: 34.0 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (shallow flash)
BuildID: 20141013043753
Gaia: 21fc294d6c9b78997142153fc32c3175b4835a89
Gecko: 93530962cca3
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 7

[Joshua Mitchell (Inactive)]

Marking this as a 2.2 Blocker - Regression and horrible UX to put a phone-call on hold unintentionally

Comment 10

[Pi Wei Cheng [:piwei] (inactive)]

b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20141008174803
Gaia: 1d3e427b61fb72b6f6f7a20ce6176f5a0d6c9db5
Gecko: a8d1167d0b27
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.

First Broken Environmental Variables:
Device: Flame
BuildID: 20141008181807
Gaia: f0a82790afad5564e0ada9ab321b1b2896e72e57
Gecko: c16b1a308eea
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Broken Gaia & Last Working Gecko - issue DOES repro
Gaia: f0a82790afad5564e0ada9ab321b1b2896e72e57
Gecko: a8d1167d0b27

First Broken Gecko & Last Working Gaia - issue does NOT repro
Gaia: 1d3e427b61fb72b6f6f7a20ce6176f5a0d6c9db5
Gecko: c16b1a308eea

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/1d3e427b61fb72b6f6f7a20ce6176f5a0d6c9db5...f0a82790afad5564e0ada9ab321b1b2896e72e57

Caused by Bug 1077331.

Comment 11

[Joshua Mitchell (Inactive)]

Broken by Bug 1077331 ? Can you take a look Doug ?

Comment 12

[Doug Sherk (:drs) (inactive)]

I think the best way to go for this is to back out bug 1077331 and mark it as dependent on the underlying problem, which is bug 991490. It doesn't look like there's a good workaround.

Comment 13

[Doug Sherk (:drs) (inactive)]

Fixed by the backout of bug 1077331.