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

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

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

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

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

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

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

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.

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

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.

Fixed by the backout of bug 1077331.