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

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

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.

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!

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

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?

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

Firefox OS is not being worked on