1148632 - [Lockscreen] Tapping 'Open' on a lockscreen notification and then canceling the passcode lock page will still queue up the open activity and open it after eventually accessing homescreen, even after lockscreen camera activity

Status: VERIFIED FIXED

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

Description

[Joshua Mitchell (Inactive)]

Description:
The issue here is that when you select a notification on the lockscreen when passcode is enabled, it will bring up the passcode screen. After you successfully input the passcode and proceed to the homescreen the initial activity will load (screenshot shown in preview, msm shown in messenger). If you instead hit Cancel on the passcode entry screen it is a reasonable expectation that this will also cancel the activity the prompted the passcode entry screen to appear in the first place. This is not the case and the activity will still occur when you eventually access the homescreen. This can confuse some users; especially if some time has passed. You can also use the lockscreen camera for a variety of activities and then access the homescreen and the original lockscreen notification activity will still occur, which would be even less expected and confusing after a few minutes of camera usage. 


Repro Steps:
1) Update a Flame to 20150327010205
2) Create notifications that will appear on Lockscreen and turn on passcode lock
3) Lock the device
4) Tap 'open' on a notification 
5) tap cancel on the keypad
6) Slide to the left to access camera 
7) Tap home to return to lockscreen
8) Slide to the right and unlock the device

Actual:
The original 'open' action is carried out, even after a 'cancel' on the keyboard and using the camera

Expected:
Upon canceling the passcode entry keypad, the original 'open' action will also be canceled

Environmental Variables:
Device: Flame Master
Build ID: 20150327010205
Gaia: 249b8c08c1d57961ef6c905f3498fa62b032bf24
Gecko: e046475a75cb
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0


Repro frequency: 8/8
See attached: video: http://youtu.be/4ho7hjHqnCE

Comment 1

[Joshua Mitchell (Inactive)]

This issue also reproduces on Flame KK 2.2 and 2.1

This issue is not testable on 2.0 because lockscreen notifications do not have an 'open' option

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150327002500
Gaia: f9f62d7b69c9d46a28b5ca4f18993c90b5a2b26a
Gecko: 17079fdf6c6f
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


Device: Flame 2.1 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150325001202
Gaia: b8ae0df34362420fe4a9c90effa5247a1f5c844d
Gecko: 2a05cd42088b
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 2

[Joshua Mitchell (Inactive)]

* Note:  https://bugzilla.mozilla.org/show_bug.cgi?id=1072395 prevents using Screenshot Notifications to test this issue in branches prior to 3.0  - SMS and other notifications should work fine.

Comment 3

[Peter Bylenga [:PBylenga]]

I think this may be intended behavior, NI on component owner to confirm.

Comment 4

[Brogan Zumwalt [Inactive]]

Added qawanted to check Flame 3.0 on v18D-1 base

Comment 5

[Brogan Zumwalt [Inactive]]

Issue DOES reproduce on Flame 3.0 with v18D-1 base

The original 'open' action is carried out, even after a 'cancel' on the keyboard and using the camera

Device: Flame 3.0
Build ID: 20150327010205
Gaia: 249b8c08c1d57961ef6c905f3498fa62b032bf24
Gecko: e046475a75cb
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Comment 6

[Gerry Chang [:gchang]]

Hi Greg,
The cancel button doesn't cancel the 'open' action. I think this is not expected behavior. This might need your help to fix.

Comment 7

[Greg Weng [:snowmantw][:gweng][:λ]]

Howie: should we fix a bug on all branches like this? Since from the comments show that the behavior was incorrect since the first day QA verified the feature, and then they now start to check it again to find out the bugs like this. I know it's necessary for product since we're in the train model (*in theory*), but if it exists so long and never been found until now, especially the codebase changes a lot from v2.1 to v3.0, it may be risky to fix it individually. 

Gerry: we could have an offline discussion about your recent tests on Notifications for more details.

Anyway, I need to check the spec first to see if the spec mentioned the behavior like this. Since the 'cancel' is irrelevant to the notification from the code path in my recollection. If not, the spec may need to be updated. Otherwise, we may miss this from the long time ago.

Comment 8

[GitHub Autolander Bot]

Attachment: [gaia] snowmantw:bug1148632 > mozilla-b2g:master

Comment 9

[GitHub Autolander Bot]

Attachment: [gaia] snowmantw:bug1148632-2.2 > mozilla-b2g:v2.2

Comment 10

[GitHub Autolander Bot]

Attachment: [gaia] snowmantw:bug1148632-2.1 > mozilla-b2g:v2.1

Comment 11

[howie [:howie]]

Triage: blocking as 2.2 first. the risk of uplift to 2.1 need RM to make decision.

Comment 12

[Greg Weng [:snowmantw][:gweng][:λ]]

Comment on attachment 8585918 [details] [review]
[gaia] snowmantw:bug1148632 > mozilla-b2g:master

Since on master it's green on Gaia-Try:

https://treeherder.mozilla.org/#/jobs?repo=gaiarevision=68640dd82c429c36e16319109bd1aa864fa7f1bd

I now set the review flag.

Comment 13

[Greg Weng [:snowmantw][:gweng][:λ]]

Comment on attachment 8585923 [details] [review]
[gaia] snowmantw:bug1148632-2.2 > mozilla-b2g:v2.2

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): The lost part of the original bug. It should be implemented at the very first.
[User impact] if declined: But occurs.
[Testing completed]: Not sure if the result is good since it's still broken even after I revert the patch. It looks like the v2.2 has encountered serious problems on TaskCluster, so whether with or without my patch the branch keeps broken See:

1. With my patch:
https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=073b14f19ccb6b52e69ae1cb43c26a066c15e411

2. Without my patch (reverted):
https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=ace5922c11f1b8a0c558ea98b954113979ba65dd

[Risk to taking this patch] (and alternatives if risky): If the test is unreliable then there is a backing out risk.
[String changes made]: No

Comment 14

[bhavana bajaj [:bajaj]]

waiting for master landing here

Comment 15

[GitHub Autolander Bot]

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/0ae5e7a529bb2d66a0aacc724467e93fdde82fcb

Comment 16

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/cec00d643f517ffd96cde559cd3bbd43ab85816c

Comment 17

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame Master.

Result: The original 'open' action is cleared when the screen is unlocked.

Environmental Variables:
Device: Flame 3.0 (KK, 319mb, full flash)
Build ID: 20150417010203
Gaia: 3cd0a9facce26c2acc7be3755a17131a6358e33f
Gecko: 51e3cb11a258
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

===================================================
This issue still reproduces on Flame 2.2.

Result: The original 'open' action is carried out, even after pressing the cancel button and opening up Camera on lockscreen.

Environmental Variables:
Device: Flame 2.2 (KK, 319mb, full flash)
Build ID: 20150417002504
Gaia: d50b8a3919a7b4d8d289f150d3b9bed704ebafa9
Gecko: 5ebf32030512
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