1157822 - [Windows Management] [Notification Banner] [Lockscreen] Tapping on a notification banner will execute onclick callback behind the lockscreen, operating inconsistently with tapping on the lockscreen notification (non-banner).

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Status bar, Utility tray, Notification, defect)

Description

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150423_1007.txt

Description:
When you receive a transfer request notification while the device is on the lockscreen the notification will have both a banner, and a notification that goes into the lockscreen list. If you click on the banner the request page will open behind the lockscreen but the lockscreen remains. It also removes the notification from the list. 
This operates differently than just clicking on the notification in the list - which causes the device to move past the lockscreen to the transfer request. 


Repro Steps:
1) Update a Flame to 20150423010203
2) Pair Bluetooth with another device
3) Lock the screen (tap the power button)
4) Send a file to the D.U.T. from the other device
5) When the transfer request banner appears on the D.U.T. tap on it

Actual:
Notification in list goes away but nothing happens (request page appears behind lockscreen)

Expected:
Device will move past lockscreen and show the transfer request page


Environmental Variables:
Device: Flame 3.0 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150423010203
Gaia: 9d4f756aa35cb7f030a92f3c1f65fb55254ddd1d
Gecko: 0b202671c9e2
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


Repro frequency: 7/7
See attached: logcat, Video Clip: (youtube currently not able to process video, will update bug later with video URL)

Comment 1

[Joshua Mitchell (Inactive)]

This issue also reproduces on Flame KK 2.2, 2.1 and 2.0

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150423002502
Gaia: b838d0e7c163e66660dcb6e387d8339944a7a30e
Gecko: 8dce56574f28
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 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150422001201
Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c
Gecko: 685fa69b59dc
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 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150422000204
Gaia: 84898cadf28b1a1fcd03b726cff658de470282f0
Gecko: 1b4c18915e2c
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

Comment 2

[Gregor Wagner [:gwagner]]

What is the proper UX for this use case?

Comment 3

[Stephany Wilkes]

The expected behavior in the description field is what should be happening here. Thanks.

Comment 4

[[e-mail], [e-mail]]

Hi Greg, 

Per Stephany's suggestion[1], is the behavior possible and not broken lockscreen police? Thanks.

[1]: Expected: Device will move past lockscreen and show the transfer request page

Comment 5

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

I think it's fixable, but the patch is majorly for System part. Since the pop-up is not controlled by LockScreen, and the removed notification is removed by noficaition_screen.js. So if we want to patch this, we need to fire a unlocking request, while taking care the security concerns, from System/BT side.

And I also noticed that you can reproduce this with screenshot. So it would be a generic patch for most cases. Please note it also not a part of 'touchable' notification feature, at least not intentioned in it, since the pop-up was totally individually developed at the past version. So we may need to take some time to trace the code path.

Comment 6

[[e-mail], [e-mail]]

Greg, Thanks! It's a generic issue for notification banner. As Stephany's suggestion, the behavior might be same with 'click' on lockscreen::notification::open. But we also need to concern about security while clicks banner to unlock lockscreen(input key value to unlock). In advance, the callback of onclick function might be executed after screen unlocked.

Stephany, if I misunderstand, please incorrect me.

Michael, could you please investigate the issue since the problem is happened in system::notifications::banner. Thanks.

Comment 7

[[e-mail], [e-mail]]

Rename the title for generic issue.

Comment 8

[Michael Henretty [:mikehenrty][:mhenretty]]

Hmmm, I suggest we don't even show the banner on the lockscreen. What purpose does it have since we are guaranteed to see the notification in the lockscreen tray? To me, the banner is just to inform the user a notification came up when they are doing something on the phone, but when the lockscreen is up we will always see the notification. In any case, I will leave that up to Stephany.

Comment 9

[Gregor Wagner [:gwagner]]

For comment 8

Comment 10

[Rob MacDonald [:robmac]]

(In reply to Michael Henretty [:mhenretty] from comment #8)
> Hmmm, I suggest we don't even show the banner on the lockscreen. What
> purpose does it have since we are guaranteed to see the notification in the
> lockscreen tray? 

Thanks for clarifying, Michael. Steph ping'ed me on this one previously but I wasn't thinking of the behaviour in the lock screen context. I agree there is no need to show the toast on the homescreen as the same information is shown within the view itself. Sorry for any confusion.

Comment 11

[Gregor Wagner [:gwagner]]

Lets fix this.

Comment 12

[GitHub Autolander Bot]

Attachment: [gaia] albertopq:1157822-banner-lockscreen > mozilla-b2g:master

Comment 13

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8607569 [details] [review]
[gaia] albertopq:1157822-banner-lockscreen > mozilla-b2g:master

Looks good to me!

Comment 14

[GitHub Autolander Bot]

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

Comment 15

[zouyi(Leave from Mozilla)]

Attachment: 1050.mp4

Per commment8 and comment10, the expected result should be: the transfer request banner should not be shown on the home screen. So this bug has been successfully verified on latest Nightly Flame 3.0 & Nexus5 3.0 .
Actual results: Transfer request banner will not be shown on lockscreen. 
See attachment: 1050.mp4
Reproduce rate: 0/6

Device: Flame 3.0 build(Pass)
Build ID               20150526160204
Gaia Revision          8ca93673869a64e09ed6153c5402896822dfb253
Gaia Date              2015-05-26 19:31:37
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1e4e369822ac
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150526.195035
Firmware Date          Tue May 26 19:50:45 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus5 3.0 build(Pass)
Build ID               20150526160204
Gaia Revision          8ca93673869a64e09ed6153c5402896822dfb253
Gaia Date              2015-05-26 19:31:37
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1e4e369822ac
Gecko Version          41.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150526.195039
Firmware Date          Tue May 26 19:50:56 EDT 2015
Bootloader             HHZ12f