Closed Bug 1012889 Opened 6 years ago Closed 2 years ago

[B2G][Dialer] Answering a call from the lockscreen then adding a contact to the call will bring the user to the lockscreen, not the Dialer app

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(tracking-b2g:backlog, b2g-v1.3 affected, b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED WONTFIX
tracking-b2g backlog
Tracking Status
b2g-v1.3 --- affected
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: nkot, Unassigned)

References

Details

Description:
Receiving a call on lockscreen, answering then adding a contact to the call will show the lockscreen. The user will have to unlock the screen to be able to see the Dialer/contacts app and to add a contact to the call.

Repro Steps:
1) Update Open_C to BuildID: 20140519040204
2) Have the test device on lockscreen
3) With a 2nd device call the test device
4) Answer the call on the test device
5) Select the 'phone' icon (3rd icon from the left)

Actual:
The phone displays the lock screen, not the Dialer/contacts app

Expected:
The user is taken to the Dialer app (contacts tab) so they can select a contact to add to the call

Environmental Variables:
Device: Open_C master m-c
BuildID: 20140519040204
Gaia: 101c500903a2477f9de1ea5ce523b9e0be4d45d0
Gecko: 41a54c8add09
Version: 32.0a1
P821A10V1.0.0B06_LOG_DL

Notes: 
the issue repros on Buri and other devices, repros on 1.3, 1.4 and master m-c

Repro frequency: 100% 
See video clip at https://www.youtube.com/watch?v=S6ts3YJtA_U
Blocks: 959011
Requesting feature-b2g: 2.0 because the dependent bug has that flag.
blocking-b2g: --- → 2.0?
I'm afraid this is invalid.
Picking up a call doesn't count as unlocking, and if it did the scenarios with a passcode would become inconsistent.
(In reply to Etienne Segonzac (:etienne) from comment #2)
> I'm afraid this is invalid.
> Picking up a call doesn't count as unlocking, and if it did the scenarios
> with a passcode would become inconsistent.
ni? to Mike Tsai for UX input.
Flags: needinfo?(mtsai)
I think we should separate the case into two scenario:

1. If users have set passcode to unlock the screen, they should enter the passcode before being taken to the Contact APP (Consider the security issue).

2. If users didn't set passcode to unlock the screen, they can access Contact APP directly after tapping "Add a call" icon. 

Thanks!
Flags: needinfo?(mtsai)
(In reply to Carrie Wang [:carrie] from comment #4)
> I think we should separate the case into two scenario:
> 
> 1. If users have set passcode to unlock the screen, they should enter the
> passcode before being taken to the Contact APP (Consider the security issue).
> 
> 2. If users didn't set passcode to unlock the screen, they can access
> Contact APP directly after tapping "Add a call" icon. 
> 

It wont be trivial :)
Needinfo-ing Alive to comment, but I don't think it'll fit in 2.0.
Flags: needinfo?(alive)
A simple workaroud in my mind:
Tell LockscreenWindow to close() when any webapps-launch/open-app event is fired to system app if passcode is not enabled.

Does this work for you?
Flags: needinfo?(alive)
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> A simple workaroud in my mind:
> Tell LockscreenWindow to close() when any webapps-launch/open-app event is
> fired to system app if passcode is not enabled.
> 
> Does this work for you?

I'm a bit afraid of the edge cases :/
Even if we ignore the .stayBackground launches, and app that does a .getSelf(launch()) would unlock the phone...
(In reply to Etienne Segonzac (:etienne) from comment #7)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> > A simple workaroud in my mind:
> > Tell LockscreenWindow to close() when any webapps-launch/open-app event is
> > fired to system app if passcode is not enabled.
> > 
> > Does this work for you?
> 
> I'm a bit afraid of the edge cases :/
> Even if we ignore the .stayBackground launches, and app that does a
> .getSelf(launch()) would unlock the phone...

If this is a concern then this bug should not be 2.0+.
Need further plan and discussion.... or either just ignore this request because we cannot tell.

Maybe what we could do for now: just disable the phone button when lockscreen is locked.
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #8)
> (In reply to Etienne Segonzac (:etienne) from comment #7)
> > (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> > > A simple workaroud in my mind:
> > > Tell LockscreenWindow to close() when any webapps-launch/open-app event is
> > > fired to system app if passcode is not enabled.
> > > 
> > > Does this work for you?
> > 
> > I'm a bit afraid of the edge cases :/
> > Even if we ignore the .stayBackground launches, and app that does a
> > .getSelf(launch()) would unlock the phone...
> 

OK, another proposal: tell from open-app request, there shall be a property to tell we are from system message and we are activity; if there is an activity request when lockscreen is locked, unlock it. All other case, do not unlock the lockscreen.
It's because activity is always launched from user input, and no getSelf-then-launch could trigger activity to unlock the lockscreen.
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #8)
> (In reply to Etienne Segonzac (:etienne) from comment #7)
> > (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> > > A simple workaroud in my mind:
> > > Tell LockscreenWindow to close() when any webapps-launch/open-app event is
> > > fired to system app if passcode is not enabled.
> > > 
> > > Does this work for you?
> > 
> > I'm a bit afraid of the edge cases :/
> > Even if we ignore the .stayBackground launches, and app that does a
> > .getSelf(launch()) would unlock the phone...
> 
> If this is a concern then this bug should not be 2.0+.
> Need further plan and discussion.... or either just ignore this request
> because we cannot tell.
> 
> Maybe what we could do for now: just disable the phone button when
> lockscreen is locked.
The nomination to 2.0? is because it blocks Bug 959011.
I don't feel we can decouple these two bugs.
this is not a bug more like late feature. it's not a blocker and by no mean should make into v2.0 based on this time frame.
blocking-b2g: 2.0? → backlog
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
blocking-b2g: backlog → ---
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.