1185709 - Callscreen disappears during a call, difficult to get it back

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[(not reading bugmail) Nick Desaulniers [:\n]]

sometimes when on a call, the current call screen disappears and I cannot hang up! I still see a blue pulsing strip near the top of the screen to indicate that I'm still in a call.  I wonder if the proximity sensor has something to do with this?

Comment 1

[Alessio Placitelli [:Dexter]]

I have the exact same issue, with a twist: if I slide down the top of the screen to show current stuff, and try to go back to the "Call Screen", it *sometimes* displays a call screen with no contact name/number which makes me unable to hang the call.

Comment 2

[Gabriele Svelto [:gsvelto] (PTO)]

I've already encountered this though not very often and I'm 100% positive we have a bug filed already for it but I can't find it right now :-(

Comment 3

[(not reading bugmail) Nick Desaulniers [:\n]]

I was able to pull down the notifications shade, then tap return to call in progress.  Still, super frustrating.

Comment 4

[Michael Henretty [:mikehenrty][:mhenretty]]

[Blocking Requested - why for this release]:

This is an issue with the callscreen attention window, which puts it in the window management realm instead of the dialer. This is very frustrating for me as well.

It's nice to be able to hide the callscreen attention window when trying to look something up while on a call. But the attention window should not hide automatically, which it does sometimes. Nominating.

Comment 5

[Hubert Figuiere [:hub]]

Looks a hell lot like bug 1176756 that seemed to be gone.

But I have seen it happening since.

Comment 6

[Gabriele Svelto [:gsvelto] (PTO)]

One thing I've noticed is that we install the proximity sensor event handler that turns of the screen only upon we receive the first telephony callschanged event:

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/screen_manager.js#L283

This means that while the callscreen is sliding in the screen doesn't turn off, and when it does there's a noticeable lag between the sensor being triggered (by putting a finger on it) and when the screen turns off. I suspect that I've often hit buttons with my cheek during that delay and this might have caused the callscreen to be minimized.

It could be something else but I've noticed the screen not being turned off right away once I put the phone to my ear so it might be worth investigating.

Comment 7

[Jean-Yves Avenard [:jya]]

+1 , over one minute it took me to get back and find a way to hang up a call.

Worse, if you have the lock screen activated, after being on a call for a short while, look at the phone to hang up: get the lock screen. unlock the phone: no more dialler. try to slide the notification down : thins instead triggers the proximity sensor and the screen turns off.

In the end I found the sliding my finger down, keep far away from the sensor on the right side of the screen let you display the notification screen and you can go back in the dialler from there

I must have left the longest voicemail ever since using this phone, seeing that I usually can't hang up

Comment 8

[Hubert Figuiere [:hub]]

I noticed that this happens when I initiate a call from the call log. It doesn't when I receive the call.

Comment 9

[Hubert Figuiere [:hub]]

Another annoying side effect is that the dialer to dial and the dial to perform "touch tone" operation (like with voicemail) aren't the same. So I was confused as to why the voicemail system didn't take my PIN to read the message. Until I realised that the call screen was gone and that I had to perform all these acrobatics to get it back....

Comment 10

[Etienne Segonzac (:etienne)]

There's so much on this bug it's hard to find where to start.
First, while on a call, triggering the proximity sensor on then off doesn't make the callscreen go away (not even minimized), that's good.

Then, when pressing home to voluntarily minimize the callscreen, the minimized version is completely white! Instead of showing the call duration and all.

Gabriele, do you have a bug filed for that? It's rather fragile since I think it's just a media query (we resize the callscreen's iframe to "trigger" the minimized version)?

Then when the screen is locked, from the WindowManager standpoint we're always showing the minimized version of the callscreen, which is good :) But since it's just a white bar it's not helping much with getting back to the call.

Comment 11

[Gabriele Svelto [:gsvelto] (PTO)]

This looks like bug 1202909, not a dialer bug though as we didn't land anything in the callscreen after the 29th of August and this started happening only today on my phone.

Comment 12

[Etienne Segonzac (:etienne)]

Now that bug 1202909 landed it would be cool to give this another run and (hopefully) come up with clearer STR expected/actual to guide what needs to happen here.

Comment 13

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

It seems highly likely that this issue is hit because a user has hit an area on the screen that goes to another page before the callscreen is brought up and before proximity sensor takes effect.

STR:
1) Initiate a call on DUT by any method (dialer, call log, or contacts app)
2) After step 1, immediately tap on search bar/rocketbar, and then cover up the proximity sensor

- notice that it takes a few seconds before the screen turns off, so you have plenty of time to hit the search bar.

3) the other end picks up the call
4) uncover the proximity sensor

Expected: Screen turns on showing active call screen

Actual: Screen turns on showing the screen at step 1

Video showing the issue:
https://www.youtube.com/watch?v=GqHWFzaHoz0

Reproduction rate: 4/5

Issue is reproducible on:
Device: Aries 2.5
BuildID: 20150911175048
Gaia: b467811f80e3000ca35e30821bc09f606cf93ee8
Gecko: 3a7e419d7cdc2c182a891b5d7a8e027c2372f75d
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Device: Flame 2.5
BuildID: 20150911030227
Gaia: 6280500a6cb8d1b178cdd163450e36d22846fbed
Gecko: c0abc2a6e11f52761366e029eb1bae4c9864a8a3
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Device: Flame 2.2
BuildID: 20150911032501
Gaia: 7a427e0f8aa6c185a9e22358006b97c19435ca4a
Gecko: 0d9c46d01861
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 14

[Etienne Segonzac (:etienne)]

(In reply to Pi Wei Cheng [:piwei] from comment #13)
> It seems highly likely that this issue is hit because a user has hit an area
> on the screen that goes to another page before the callscreen is brought up
> and before proximity sensor takes effect.

Thanks! That's super actionable.

Comment 15

[GitHub Autolander Bot]

Attachment: [gaia] etiennesegonzac:bug-1000523 > mozilla-b2g:master

Comment 16

[GitHub Autolander Bot]

Attachment: [gaia] etiennesegonzac:bug-1185709 > mozilla-b2g:master

Comment 17

[Etienne Segonzac (:etienne)]

Comment on attachment 8660771 [details] [review]
[gaia] etiennesegonzac:bug-1185709 > mozilla-b2g:master

We clearly want to listen to proximity events for "dialing" calls, but we're not getting a statechange event for those (since the call is already "dialing" when we add the listener).

This patch fixes that without regressing neither bug 822164 nor bug 1000523.

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8660771 [details] [review]
[gaia] etiennesegonzac:bug-1185709 > mozilla-b2g:master

Sigh, we really need some way to protect the whole flow for ScreenManager actions.

Comment 19

[Carsten Book [:Tomcat]]

https://github.com/mozilla-b2g/gaia/commit/68527c76318839e0e510ee37f19c6f9f8a96289c

Comment 20

[Chris Fishlock]

Any work required on the 2.2 branch as the problem was also reported against 2.2?

Apologies if this is a stupid comment, I'm new to all this.

Comment 21

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

The STR at comment 13 is NOT fixed and still reproducible on latest. Would you like a new bug written or reopen this bug? I discovered that this is not fixed by bug 1222739.

Reproducible on:
Device: Aries 2.6 Master
BuildID: 20151113123209
Gaia: e8c15ae4e5324a210000ee0a869a962aa542009f
Gecko: faf815a0fa9b052a38bce00c0c2aa1e2c9610936
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Device: Flame 2.5
BuildID: 20151113083704
Gaia: 142a25e39196f036978e0dd6c94640bd8d4d692a
Gecko: 2ed226048f70df93060f5cbb26dba6d6b09538fb
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Comment 22

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Unless Etienne says otherwise, please open a new bug for this issue.

Comment 23

[Etienne Segonzac (:etienne)]

(In reply to Jayme Mercado [:JMercado] from comment #22)
> Unless Etienne says otherwise, please open a new bug for this issue.

oh yes definitely, will be much easier to manage with a new bug!

Comment 24

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

New bug filed. See the 'see also' bug.