1225210 - Search bar should be disabled immediately after dialing out a number, and perhaps disable it completely on active call screen

Status: RESOLVED WONTFIX

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

Description

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

Attachment: logcat of issue

Description:
This bug is written to address the failed verification for bug 1185709. It seems easy for users to hit this in real life usage - during the few seconds transition from dialing out a number to one puts the phone next to their ear, the rocketbar/search bar can be invoked accidentally since they're placed so close to each other, therefore they exit out of active call screen before proximity sensor takes effect. This confuses user if during a call they need to look at active callscreen to press something in response.

Also, I noticed that in active call screen, search bar is still invokable. Perhaps search bar needs to be turned off altogether during active callscreen to avoid this situation.

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

Attaching a logcat.

Device: Aries 2.6 Master
BuildID: 20151116140807
Gaia: e8c15ae4e5324a210000ee0a869a962aa542009f
Gecko: 4294bf91174b71ed7440dc491dac5d15394ec227
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.6 Master
BuildID: 20151116030435
Gaia: e8c15ae4e5324a210000ee0a869a962aa542009f
Gecko: 48d636f678b0e5162ab868dc9024a5ffe350460c
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Comment 1

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

Flame 2.5 and 2.2 are also affected.

Device: Flame 2.5
BuildID: 20151116173604
Gaia: 9473dbcbebf4e758a3b73200968efc69071b4312
Gecko: 17877d161e5f62726027ee70101a7004dcad5a69
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

Device: Flame 2.2
BuildID: 20151116032504
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: e772f343b736
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 2

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

[Blocking Requested - why for this release]:

The original issue this bug addresses was a blocker so nominating this as well.

Ni? on Etienne for visibility.

Comment 3

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

Note that bug 1222739 is likely another example of users hitting this.

Comment 4

[Etienne Segonzac (:etienne)]

I'd like to get some UX input on what's the exact expected behavior before making a patch.

Comment 5

[Tiffanie Shakespeare [:tif]]

From UX triage: 

We think that it would be ideal to just remove the rocketbar from in-progress call screen only. That was we avoid accidental taps and also it's not strange that the rocketbar doesn't work.

Thanks for pinging the UX team!

Comment 6

[Gregor Wagner [:gwagner]]

I don't think we should block 2.5 at this point but we should fix it going forward and uplift if appropriate.
Etienne, do you have cycles for this?

Comment 7

[BMO Automation]

Firefox OS is not being worked on