1012889 - [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

Status: RESOLVED WONTFIX

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

Description

[Natalya Kot [:nkot]]

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

Comment 1

[Anthony Ricaud (:rik)]

Requesting feature-b2g: 2.0 because the dependent bug has that flag.

Comment 2

[Etienne Segonzac (:etienne)]

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.

Comment 3

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

(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.

Comment 4

[Carrie Wang [New account: [e-mail]]]

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!

Comment 5

[Etienne Segonzac (:etienne)]

(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.

Comment 6

[(inactive after 6/18) Alive Kuo [: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?

Comment 7

[Etienne Segonzac (:etienne)]

(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...

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

(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.

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

(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.

Comment 10

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

(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.

Comment 11

[howie [:howie]]

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.

Comment 13

[BMO Automation]

Firefox OS is not being worked on