1108833 - Inconsistent display of unread notifications on lockscreen between lock/unlock and restart of device

Status: RESOLVED INVALID

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

Description

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: logcat on Flame 2.2 doing the STR

Description:

The device does not display a notification on the lockscreen if user receives a notification while the device is awake, as opposed to when device is rebooted, notification is then displayed on lockscreen.

Additionally, the options in Settings app > Notifications don't seem to affect anything in this use case.

STR:
1) Receive an SMS (or any form of notification) notification on DUT while DUT is awake

- observe SMS notification pops up and retracts into a thin blue line on top. Do not clear the notification.

2) Press hardware power button twice to lock and unlock the device

- observe there is NO lockscreen notification displayed

3) Long-press the power button and "Restart"

- observe there IS lockscreen notification after restart

Expected: Observations from step 2 and step 3 are consistent

Actual: See step 2 & 3's inconsistent observations.

Notes:
1) Repro rate: 3/3
2) Attaching a logcat
3) Tested on:

Device: Flame 2.2 Master (shallow flash, 319MB mem)
BuildID: 20141208123406
Gaia: bd4dcc8c4582e2368b47b0e62506d3031fb2fc09
Gecko: cfeda36af765
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 1

[Joshua Mitchell (Inactive)]

QA-Wanted for Branch Checks

Comment 2

[Pi Wei Cheng [:piwei] (inactive)]

This issue also occurs on Flame 2.1. Following STR, step 2 doesn't display a notification on lockscreen but step 3 does.

Device: Flame 2.1
BuildID: 20141208070634
Gaia: e81d3e7590ad63113baaffd154fcfa73fc297499
Gecko: 199d127fbeae
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

---------------

This issue does NOT occur on Flame 2.0. Following STR, step 2 and step 3 both don't display a notification on lockscreen. Since the notification bar/tray refactor isn't implemented in 2.0, I'm not setting 2.0 tracking flag and not marking it a regression.

Device: Flame 2.0
BuildID: 20141208061237
Gaia: 856863962362030174bae4e03d59c3ebbc182473
Gecko: 2d0860bd0225
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 3

[Joshua Mitchell (Inactive)]

Nomming for 2.2 - seems too late to nom for 2.1 but this seems like some expected functionality that we should fix.

Comment 4

[howie [:howie]]

Triage: blocking.

Comment 5

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

Howie: Luke reminded me this is probably by-design: if user receive notification while it's "unlocked" (let's get rid of the confused "awake" in STR"), it's *should not* display on LockScreen, which is correct. And the seconds case, the system resending notifications after rebooting, is also correct. So this may be not a valid bug.

Summary:

1. *without* LockScreen, received notifications *would NOT* display on LockScreen after pressing the power button twice

2. system *should* resend all unread notifications on LockScreen after rebooting

3. without unlocking, notifications on LockScreen *should* stay on the screen, no matter how you press the power button

If there is a inconsistent consideration we should NI UX for more information.

Comment 6

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

And unfortunately Howie is OOO.

Comment 7

[howie [:howie]]

Thanks Greg, remove the blocking status until further clarification.

Hi Rob, can you check if this is by design based on Comment 5? Thank you.

Comment 8

[howie [:howie]]

Since Rob will be away for a while, ni Tiffanie for help, thanks.

Comment 9

[Tiffanie Shakespeare [:tif]]

Hello!

I'm not going to be super helpful on this one so I'm passing the buck. Francis, Gordon, or Jacqueline should be able to help out.

Thanks!

Comment 10

[Francis Djabri [:djabber]]

I'm afraid I can't find any relevant specs for this behavior on box, so I can't comment definitively, but this sounds like correct behaviour. Rob is back, so passing back over to him.

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: still waiting for UX feedback.

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I actually think we can take the assumption of comment 5 as a valid interpretation of the "correct" behavior and close this bug as INVALID.

Comment 13

[howie [:howie]]

Triage: agree INVALID as comment 5