992161 - [tarako] Setting is killed when alarm rings

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[Peipei Cheng (needinfo if you need my action)]

Steps to reproduce
-----------------------------------------------------------------
1. Start device
2. Setup an alarm
3. Launch Settings and wait for alarm rings
   --> When alarm rings, Setting was killed.


Test build
------------------------------------------------------------------
Gaia      32e15ec78cb245576a382468790d8f65461a5b3d
Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/e20c64a0ccd3
BuildID   20140403164001
Version   28.1
ro.build.version.incremental=eng.cltbld.20140403.201900
ro.build.date=Thu Apr  3 20:19:07 EDT 2014

Comment 1

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

this seems like an expected behavior when device memory is low
if there is no data loss, let's not block on this. thanks

Comment 2

[John Hammink]

If you haven't saved the setting and the alarm is fired, then you lose data.   

This general argument applies across the board (changing a setting or creating a calendar event or a mail  - and then losing  that data - when a notification or alarm is fired.  We should, of course, do more testing around these scenarios (ni - ing myself to do this).

Last foreground should not be killed when an alarm is fired.  We should always be able to maintain at least one foreground app (two is debatable) (renominating this bug).

Comment 3

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

(In reply to John Hammink from comment #2)
> Last foreground should not be killed when an alarm is fired.  We should
> always be able to maintain at least one foreground app (two is debatable)
> (renominating this bug).

Alarm/Clock is the foreground app by definition when it rings.

Also, most of the settings are applied on the fly, there is no dataloss if we got OOM'd.
The only exceptions are "dialogs" where settings are only applied when the user taps "OK" on the top-right.

Even if we want to save the pending data on "dialogs", we would have to come up with new UIs to keep these unapplied settings :-/ so I highly doubt this can be in Tarako scope.

Comment 4

[[:fabrice] Fabrice Desré]

Not blocking on this bug since the user impact is minimal: many settings are applied on the fly.

and: (Evelyn)
"It doesn't make sense to cache settings by Settings app itself, because this action takes as much time as writing it to mozSettings database. If we would lose data in this scenario, we will lose it as a draft."

We'll solve that properly with session restore in the next version.

Comment 5

[Montoya Clemmons (MClemmons)]

Following STR from Comment 0 with low battery (<20 percent) and not charging via USB, reproduced Setting App termination and return to homescreen 4/4 - 100 percent.

Following STR from Comment 0 with low battery (<20 percent) and charging via USB (computer, not wall outlet), did not reproduce Setting App termination. Setting App remained at point user last witnessed before alarm began - after user selected close or snooze to stop Alarm. 4/4 - 100 percent. 

Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140502014001
Gaia: a8e0ff550de08e58e4bf75af3cecf175b9b71e70
Gecko: 71790bf476cb
Version: 28.1
Firmware Version: sp6821a-gonk4.0-4-29

Comment 6

[John Hammink]

As per comment #4, this seems like a feature request which should be punted to whatever the next version is for Tarako.  (C'mon - you KNOW there's gonna be a next version!)

Comment 7

[ying.xu]

now clock and setting can be at background simultaneously.