859214 - [Buri][Lockscreen]Unread event will miss after restart.

Status: RESOLVED DUPLICATE of bug 874364

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

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.19.053
 Firefox os  v1.0.1
 Mozilla build ID: 20130327153857
 
 +++ This bug was initially created as a clone of Bug #434508 +++
 
 DEFECT DESCRIPTION:
 [Lockscreen]Unread event will miss after restart.
 
  REPRODUCING PROCEDURES:
 1.Short press power key to lock screen,make an incoimg call/SMS,don't deal with it.
 2.Short press power key to light screen,check both lock screen and notification display missed call/SMS .
 3.Long press power key to restart,check both lock screen and notification don't display missed call/SMS .->ko
   comment:Long press power key to power off then power on or plug out battery then insert,has the same result as restart.
 
  EXPECTED BEHAVIOUR:
 Both lock screen and notification display missed call/SMS .
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 3/3
 
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #434508 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[xiupinglong]

It seems the unread notifications should storied in DB.

Comment 2

[Joe Cheng [:jcheng] (please needinfo)]

triage: only blocking if it is not showing up in both notification bar/lock screen. if it's showing in notification bar (just not on lock screen), should not block.

QAWANTED to confirm and alive, can you look into it? if you are overlaoded, please reassign. thanks

Comment 3

[Jan Jongboom [:janjongboom] (inactive)]

Verified this.

Alive: if you're busy I can take this.

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to janjongboom from comment #3)
> Verified this.
> 
> Alive: if you're busy I can take this.

I'm looking into this, thanks!

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

As comment 1 said, we don't store any notification. Once the phone is rebooted(by crashing or other cause), any notification would be lost.

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

I am not sure if we should store "any" notification in system.
AFAIK android doesn't store unread notifications by OS itself, but some of the apps may re-notify the user after rebooting.

For this we are also unable to have the app acquire "we are booting" before it is opened.
This smells like a late feature..

Comment 7

[Jan Jongboom [:janjongboom] (inactive)]

Workaround idea: store the notifications and when someone clicks it after reboot just launch the corresponding app, we lose the context of the notification (doesn't jump to the right path in the app) but this would solve it for SMS + Phone at least.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

It looks to me a hack to store every notification's whole data. Think about an app is keeping sending notifications accidentally or intentionally, the system app would keep doing I/O when that happens.

We ought to let gecko store the notificationID before system app sends 'desktop-notification-click' or 'desktop-notification-close' mozContentEvent to gecko, and when next time booting, send mozChromeEvent to system-app again if so.

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive] from comment #8)
> It looks to me a hack to store every notification's whole data. Think about
> an app is keeping sending notifications accidentally or intentionally, the
> system app would keep doing I/O when that happens.
> 
> We ought to let gecko store the notificationID before system app sends
> 'desktop-notification-click' or 'desktop-notification-close' mozContentEvent
> to gecko, and when next time booting, send mozChromeEvent to system-app
> again if so.

And, if gaia needs to do some data store, we may have trouble because save/restore are both asynchronously, which results in race condition.

Comment 10

[Dietrich Ayala (:dietrich)]

Daniel, the risk vs reward here seems quite low. Can you evaluate to see if TEF requires this to actually block the release?

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Dietrich Ayala (:dietrich) from comment #10)
> Daniel, the risk vs reward here seems quite low. Can you evaluate to see if
> TEF requires this to actually block the release?

Agree we should consider again if this is blocking tef release, because this looks like a late feature request. It's worthy to be leo+ or tracking-b2g+ but I recommend don't do this in tef timeframe to avoid regression.

Comment 12

[Jose Manuel Cantera]

(In reply to Alive Kuo [:alive] from comment #8)

> 
> We ought to let gecko store the notificationID before system app sends
> 'desktop-notification-click' or 'desktop-notification-close' mozContentEvent
> to gecko, and when next time booting, send mozChromeEvent to system-app
> again if so.

yes, I agree. The problem should solved at Gecko level

Comment 13

[Daniel Coloma:dcoloma]

(In reply to Dietrich Ayala (:dietrich) from comment #10)
> Daniel, the risk vs reward here seems quite low. Can you evaluate to see if
> TEF requires this to actually block the release?

I already pointed out during triage that we should not fix this for v1.0.1, tef- is then. Should we nominate it for leo?

Comment 14

[Alex Keybl [:akeybl]]

This is a feature request given the current implementation, would need to be discussed with the product team if it were to be prioritized for v1.1.

Comment 15

[Cheng-An, XIONG]

(In reply to Alex Keybl [:akeybl] from comment #14)
> This is a feature request given the current implementation, would need to be
> discussed with the product team if it were to be prioritized for v1.1.

shall we keep the leo? flag or use another flag before the final conclusion is reached?

which v1.next version is planned?

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

This one is already implemented in master(2.2), I am not sure what's the bug number...
Alex? Could you dupe it?