Created attachment 8596703 [details] 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)
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
QA Whiteboard: [QAnalyst-Triage?]
What is the proper UX for this use case?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
The expected behavior in the description field is what should be happening here. Thanks.
Hi Greg, Per Stephany's suggestion, is the behavior possible and not broken lockscreen police? Thanks. : Expected: Device will move past lockscreen and show the transfer request page
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.
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.
Rename the title for generic issue.
Summary: [Windows Management] [Bluetooth] [Lockscreen] Tapping on a Bluetooth Transfer request notification banner will open the transfer request page behind the lockscreen, operating inconsistently with tapping on the lockscreen notification (non-banner). → [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).
Component: Gaia::Bluetooth → Gaia::System::Status bar, Utility tray, Notification
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.
blocking-b2g: --- → 3.0?
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
For comment 8
(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.
Lets fix this.
blocking-b2g: 3.0? → 3.0+
Created attachment 8607569 [details] [review] [gaia] albertopq:1157822-banner-lockscreen > mozilla-b2g:master
Attachment #8607569 - Flags: review?(mhenretty)
Comment on attachment 8607569 [details] [review] [gaia] albertopq:1157822-banner-lockscreen > mozilla-b2g:master Looks good to me!
Attachment #8607569 - Flags: review?(mhenretty) → review+
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/b830fde437465bc80fe960b1fd8b038d30ddcdc8
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
status-b2g-master: affected → fixed
Target Milestone: --- → 2.2 S13 (29may)
Created attachment 8611150 [details] 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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+] [MGSEI-Triage+]
status-b2g-master: fixed → verified
You need to log in before you can comment on or make changes to this bug.