903903 - [Buri][Settings]Functions in Settings display abnormally when the phone memory is almost full.

Status: RESOLVED WONTFIX

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

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.179
 Firefox os  v1.1
 Mozilla build ID:20130730070228
 
 Created an attachment (id=481036)
 adb log
 
 DEFECT DESCRIPTION:
 Many functions in Settings display abnormally when the phone momory is almost full.
 
 REPRODUCING PROCEDURES:
 Precondition:Fill memory almost full(Left:40 KB)
 
 1.Launch Settings app.-> Sound->Ringer->Change->Select a tone such as "Oldring" -> It has no sound->Done->Click "Change" again->You'll find it still highlight the before ringtone "Buoy".-> KO1&KO2
 2.Back->Long press power key->Silence incoming calls->It has no "Silence" icon in status bar.->KO3
 3.Back->Enable USB storage->Disable USB Storage->It still displays "Enabled"-> KO4
 
 EXPECTED BEHAVIOUR:
 For KO1:It should have sound when select one ringtone.
 For KO2:It should highlight the selected ringtone"Oldring".
 For KO3:It should have "Silence" icon in status bar.
 For KO4:It should display "Disabled" when disable USB Storage.
 
 ASSOCIATE SPECIFICATION:
 TEST PLAN REFERENCE:
 TOOLS AND PLATFORMS USED:
 USER IMPACT:
 Mid
 REPRODUCING RATE:
 5/5
 For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Attachment: adb log

Comment 3

[sync-1]

Clone from brother

Comment 4

[sync-1]

Attachment: PIC2 for KO4

Comment 5

[sync-1]

Clone from brother

Comment 6

[sync-1]

Attachment: pic1 for KO1&KO2

Comment 7

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

my understanding is that when the storage is almost full, write access will be blocked. Given that there are no more write access, these can be expected.
Fabrice, can you confirm this? Thanks

Comment 8

[Andrew Overholt [:overholt]]

We discussed behaviour around disk full situations for v1 as well.  Dave can probably also provide information here.

Since this doesn't seem like a regression, we can't block on this.  Maybe for koi we can do better with low disk space situations.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #7)
> my understanding is that when the storage is almost full, write access will
> be blocked. Given that there are no more write access, these can be expected.
> Fabrice, can you confirm this? Thanks

That's correct. Once a 5 MB limit is hit, the user is presented with a toast indicating that low storage has been hit. We then block write access until 10 MB of free storage is hit again. We also persist a notification that indicates that the storage is low until the 10 MB of free space is hit.

There is definitely odd behavior that happens as a result of write access right now (like this bug), but given that the user is well aware of the low storage situation, I agree we can't block on this.

Comment 10

[[:fabrice] Fabrice Desré]

Jason is right. I'm curious how the reporter managed to get down to 40k of free space in normal operating mode (ie. without pushing files with adb to fill the /data partition).

Comment 11

[Fernando Jiménez Moreno [:ferjm]]

We would need some extra information about this issue:

1- How did you get down to 40k?
2- Did you get any notifications about the device running out of space like the ones shown in [1]?
3- Which device are you using for testing this? Has it got fanotify kernel support?

[1] https://bug861921.bugzilla.mozilla.org/attachment.cgi?id=746407

Comment 12

[xiaokang.chen]

(In reply to Fernando Jiménez Moreno [:ferjm] (PTO from 30/7 to 26/8) from comment #11)
> We would need some extra information about this issue:
> 
> 1- How did you get down to 40k?
pushing files with adb to fill the /data partition.
> 2- Did you get any notifications about the device running out of space like
> the ones shown in [1]?
yes, I have got this notification.
> 3- Which device are you using for testing this? Has it got fanotify kernel
> support?
Buri device.

And I think the key point is not the way I got into this situation but how will we deal with the memory full situation.
Imagine this: in the memory full situation, a user got the notificaion but don't know what's the meaning and how to get out of the situation. He launched settings and found he still can change the swich/checkbox/radio buttons but these changed didn't take effect. Why don't we popup a message to tell the user "Sorry, memory full, you can't do settings now and please delete some data..." and didn't change the value of swich/checkbox/radio buttons when the user do some settings.
Anyway, we should do better than v1.1.

Comment 13

[Fernando Jiménez Moreno [:ferjm]]

(In reply to xiaokang.chen from comment #12)
> (In reply to Fernando Jiménez Moreno [:ferjm] (PTO from 30/7 to 26/8) from
> comment #11)
> > We would need some extra information about this issue:
> > 
> > 1- How did you get down to 40k?
> pushing files with adb to fill the /data partition.
> > 2- Did you get any notifications about the device running out of space like
> > the ones shown in [1]?
> yes, I have got this notification.
> > 3- Which device are you using for testing this? Has it got fanotify kernel
> > support?
> Buri device.
> 
> And I think the key point is not the way I got into this situation but how
> will we deal with the memory full situation.
> Imagine this: in the memory full situation, a user got the notificaion but
> don't know what's the meaning and how to get out of the situation. He
> launched settings and found he still can change the swich/checkbox/radio
> buttons but these changed didn't take effect. Why don't we popup a message
> to tell the user "Sorry, memory full, you can't do settings now and please
> delete some data..." and didn't change the value of swich/checkbox/radio
> buttons when the user do some settings.
> Anyway, we should do better than v1.1.

Thanks for clarifying it.

I totally agree with you that the current solution is not good enough, specially in terms of UX. The first issue that we tried to solve for v1.1 was that the device could become a brick if the /data partition is filled. We solved that and now we need to evolve it with advanced functionality and a better UX. There are already some discussions about the tools required for it. Check [1], for example.

Apart from other required actions, showing a popup when the user tries to modify a setting when the device is low sounds good to me, but it feels like we need to come up with a wider solution for every app, not only for settings. We block writes in indexedDB, localStorage and offline cache when a low storage situation is detected, so we probably need to notify in all the cases that an attempt to write via any of these APIs under this condition is requested.

I'll bring this topic to the dev-b2g mailing list as soon as possible so we can discuss the options there.

[1] https://groups.google.com/forum/#!topic/mozilla.dev.webapi/UMu7nqWoQZM

Comment 14

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

Any solution will likely be an extra feature, which we will not be able to do at v1.2 timeframe.

Comment 16

[Ivan Tsay (:ITsay)]

Dave,

While do triage this one, we think the solution should be more comprehensive in platform instead of resolving it app by app in system. May I have your comments for changing the component to the correct one. Is it Core->DOM?

Comment 17

[Dave Hylands [:dhylands]]

We already detect low memory and post a generic message. To make user friendly messages requires the app to do something intelligent.

How important the fact that you can't write because of low memory space depends highly on the app (for some apps this will have no impact, for the settings app, it has a very serious impact).

Comment 18

[Ivan Tsay (:ITsay)]

Triage: Need UX team input on the UI behavior to inform user about the disc full. Will address this issue in the future release.

Comment 19

[Stephany Wilkes]

Flagging Omega on Settings.

Comment 20

[Omega Feng [:Omega] [:馮於懋]]

Stephany, I think it should be an issue for the entire system, not just for Settings.
Maybe we can to handle this by showing a toast/dialog to inform users or guide them to do something.

Comment 21

[Stephany Wilkes]

Sorry, Omega; the component affected is noted as Settings in this bug. Flagging Harly to see if this is/should be a Building Blocks issue, though this may end up being a feature call for the Systems Front-end team.

Comment 22

[Harly Hsu[:harly]]

Hi Stephany,
I don't think that this is a pattern which is related to BB. But I would suggest the same thing as Omega has pointed out which we could provide a toast/dialog when system is low on memory.

Comment 23

[BMO Automation]

Firefox OS is not being worked on