When proximity sensor becomes un-blocked during a call, there's a brief flash of "unlock" screen, with unlock buttons quickly being replaced by hangup button

RESOLVED WORKSFORME

Status

Firefox OS
Gaia::Dialer
P4
normal
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

({b2g-testdriver, polish, unagi})

unspecified
ARM
Gonk (Firefox OS)
b2g-testdriver, polish, unagi

Firefox Tracking Flags

(blocking-basecamp:-, b2g18+)

Details

(URL)

(Reporter)

Description

5 years ago
STR:
 1. Place a phone call. 
 2. After the call connects: cover up the top of the phone's screen with your hand (blocking proximity sensor)
 3. Now un-cover the top of the phone.  (un-blocking proximity sensor)

ACTUAL RESULTS: The lock-screen flashes for maybe half a second, encouraging me to touch the bottom of the phone to unlock it. THEN: The bottom of the phone suddenly turns into a hang-up button.


EXAMPLE USE-CASE WHERE THIS WOULD SUCK:
 (a) User calls some 1-800 number.
 (b) User waits on hold for 20+ minutes.
 (c) Finally user's call is answered, but first they have to "Press 1 for english" (or to select departments, or enter their PIN, or whatever)
 (d) User takes phone away from ear, so they can type stuff on the keypad.
 (e) User sees the unlock screen -- goes to unlock phone.
 (f) Right as they're about to touch the unlock animation, the "hangup" button appears right under their finger.

All that time they spent on hold has been wasted, because we just tricked them into hanging up. We just ruined their day. :(
Don't hesitate to renominate this with your own experience
blocking-basecamp: ? → -
This is a kinda annoying behavior all the time I place calls or get a call. So I can fully second Daniel's concerns here.

What is the reason why we show the lockscreen while a call is active? Whenever you have to interact with the device the necessary controls should be available immediately and not covered by the lockscreen. Even with the fact you can mistype and close the call. Why can't we simply disable that behavior and not turn on the lockscreen while a call is active?
(Reporter)

Comment 4

5 years ago
FWIW, this just bit me, in a series of steps similar to the end of comment 0.  I listened through my voicemail messages, and took my phone away from my ear at one point to press a numpad-key, to tell my voicemail to delete a particular message.  The phone initially showed me the lockscreen, so I instinctively touched the unlock area.  The hangup button appeared under my finger, and I was disconnected. :-/

I really think we need to fix this. I'm re-nominating, per comment 2, since I've now actually done an accidental-hangup from this (without trying to), so it's not a theoretical issue -- and also because I'm not the only one who's run up against it (per comment 3).
blocking-basecamp: - → ?
Triage: BB-, tracking-b2g18+
Works for me. Might be performance issue?
blocking-basecamp: ? → -
tracking-b2g18: --- → +
Keywords: polish
(Reporter)

Comment 6

5 years ago
(In reply to Joe Cheng from comment #5)
> Works for me. Might be performance issue?

In a sense, yes... in that I'm sure the lock-screen flashes for a shorter amount of time on faster devices.  The point is, though, it shouldn't be flashing at _all_ -- I'm on a call, and I left the phone UI front-and-center, and I'd expect it to still be there when I take my phone away from my ear to press some number keys.

What build does it WFYou on?
I was trying on a device that i grabbed from dev. Now that i am trying again with my nightly build on 12/21. I did see the lock screen flashed quickly (seems to be 100%)
Probably should take a patch if the fix is easy
but did not seem like something to block ship for
Priority: -- → P4
(Quoting Daniel Holbert [:dholbert] from comment #4)
> The phone initially showed me the lockscreen, so I
> instinctively touched the unlock area.  The hangup button appeared under my
> finger, and I was disconnected. :-/

This also happened to me today on the latest beta build.  The unresponsiveness of the dialer (this bug along with bug 832651 and bug 832842) makes placing phone calls requiring DTMF tones one of the most painful activities on the OS. This should definitely be higher priority than a P4 as it makes the phone feel very janky.
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Maybe we can ask for feedback from Michael.
Flags: needinfo?(mvines)
(tbh not sure what the ni? on me is for here so clearing)
Flags: needinfo?(mvines)
(Reporter)

Updated

5 years ago
Duplicate of this bug: 824093
I can't reproduce this on my Nexus S (which is a bit more laggy than Inari/Leo devices) running Gaia master. This bug is quite old, do you still experience this issue ?

FYI it seems that on Inari there is either no proximity sensor or it's broken.
Flags: needinfo?(dholbert)
(Reporter)

Comment 13

5 years ago
Retested with my unagi.  It looks like behavior has changed a bit here.  Now, the screen doesn't always turn back on when I uncover proximity sensor during a call -- I have to hit the power button.

But when I *do* hit the power button to turn the screen back on, I do sometimes see (about 50% of the time) a very brief flash of the lock screen.  Much shorter than it used to be (and possibly too short to cause any problems), but it's definitely visible for an instant, and it's a bit disconcerting. 

So, I can still reproduce this. (with the caveat that there may be an extra step now -- tapping power button -- to turn the screen back on.)

  Build ID: 20130611074722
  Update channel: unagi/1.1.0/beta
Flags: needinfo?(dholbert)
Daniel, that the screen doesn't turn on again is a separate issue and I have filed this a while back as bug 878408.
(Reporter)

Comment 15

5 years ago
Absolutely a separate issue -- I'm glad to know it's already tracked, and I didn't mean to imply that the scope of this bug should grow to encompass that.  I only brought it up because it means the STR for this bug have now changed a bit (while that bug exists, at least).
(In reply to Daniel Holbert [:dholbert] from comment #13)
> Retested with my unagi.  It looks like behavior has changed a bit here. 
> Now, the screen doesn't always turn back on when I uncover proximity sensor
> during a call -- I have to hit the power button.
> 
> But when I *do* hit the power button to turn the screen back on, I do
> sometimes see (about 50% of the time) a very brief flash of the lock screen.
> Much shorter than it used to be (and possibly too short to cause any
> problems), but it's definitely visible for an instant, and it's a bit
> disconcerting. 
> 
> So, I can still reproduce this. (with the caveat that there may be an extra
> step now -- tapping power button -- to turn the screen back on.)
> 
>   Build ID: 20130611074722
>   Update channel: unagi/1.1.0/beta

Thanks ! According to your reply, it's on v1-train. Could you give a try on master ?

I'll try and see if I reproduce on Inari with v1-train with the power button tip. I don't have an Unagi to test :/
(Reporter)

Comment 17

5 years ago
I was unable to test on master, because my cell connection wouldn't work when I flashed with master.
Blocks: 883821
Recap of my testing:

* not reproducible on the keon (my only other phone with a working proximity sensor)
* looks like it got a bit better indeed on the unagi since the video was shot

We could have a hacky workaround in gaia delaying the |this.screen.classList.remove('screenoff'); | in screen_manager.js but I don't think it's worth it.

It's a long shot, but maybe Michael would know why it's happening on some devices and not other...
Flags: needinfo?(mwu)

Comment 19

5 years ago
Don't think I would know without investigating more deeply..
Flags: needinfo?(mwu)

Comment 20

4 years ago
This bug (or similar) is still present in v1.2 on zte open (inari): after finishing a conversation I would expect to be able to hang up (red button) but the screen is black. If I press the power button to unlock the phone I see the hang up red button for a split second.
Revisit after some time and works for me
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.