Closed Bug 1159031 Opened 9 years ago Closed 9 years ago

Proximity sensor is working even though voice call is in background

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)

RESOLVED WORKSFORME
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: anshulj, Unassigned)

Details

STR
1. Make a call
2. When the call is connected press home key to put the dialer in the background
3. Cover the proximity sensor

Observed: Screen goes off
Expected: Screen should stay on as long as dialer is in the background.

Is this an expected behavior?
What does the spec say?
Flags: needinfo?(firefoxos-ux-bugzilla)
Can we also do a branch check to see if this behavior is consistent?
Keywords: qawanted
QA Contact: pcheng
This issue affects all branches of Flame including on v18D-1 base image only.

Observed behavior: Proximity sensor still works when dialer is running in the background.

Device: Flame 3.0
BuildID: 20150427010202
Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff
Gecko: 37d60e3b8be6
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Device: Flame 2.2
BuildID: 20150427002504
Gaia: 265ca0bc9408c21fc4b25a259fcee7fb642cd06b
Gecko: 1908685d798d
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.1
BuildID: 20150427001201
Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c
Gecko: 82a14be0462c
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0
BuildID: 20150427000202
Gaia: 84898cadf28b1a1fcd03b726cff658de470282f0
Gecko: f700ee0a507d
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
I cannot reproduce this. Where exactly is the proximity sensor to cover?
Whiteboard: [CR 828264]
Whiteboard: [CR 828264] → [caf priority: p2][CR 828264]
Hi! Viral,

Please help on this case. Thanks

--
Keven
Flags: needinfo?(vwang)
Hi Sean,

Looks like the proximity control is in screen_manager.js, could you please help to check it in gaia side?
Thank you!
Flags: needinfo?(vwang) → needinfo?(selee)
This issue can be reproduced at Flame, and the screen will be turned off when 'near' property is true.
https://github.com/weilonge/gaia/blob/master/apps/system/js/screen_manager.js#L240

iPhone has the same behavior as well. I think this needs UX's confirmation. Thanks.
Flags: needinfo?(selee)
Not a blocker since its not a regression and probably the expected behavior. Waiting for UX input if we should fix it going forward.
blocking-b2g: 2.2? → ---
No longer blocks: CAF-v2.2-metabug
Whiteboard: [caf priority: p2][CR 828264]
Sorry, I can't confirm. What precisely is the user impact I should be looking for here? 

Flagging Carrie since this is Dialer.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(cawang)
Hi

Actually I think it's the expected behavior. If user is on the in-call status and put the call at the background to check stuff, we'd suppose that if the proximity sensor being covered on this stage, it will be that the user is going back to the call by moving the device to his ears. So I think the proximity sensor should be working during the call even when it's on the background (Because user is still on the call and the call is not being held). Thanks!
Flags: needinfo?(cawang)
Above explanation makes sense to me. Closing the issue.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.