891344 - (sms-low-storage) [SMS/MMS] When storage is low with "Device space low" message displayed on status bar, device can't send nor receive sms/mms, we need to warn the user

Status: RESOLVED WONTFIX

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

Description

[Enpei]

When "device space low" message pops up, under this condition, MT a sms to device, it will not receive any.
Then send a sms to other device(please check attached video), as you can see on the video, after press send button, the sending icon keeps spinning even another device receives the message already. After back to message thread list, the first message become unread which is already read before. Then tap the message just sent, the text message is gone.

* Build Number (Both Gecko and Gaia)                 
Gaia:     1436e2778b90bd74635b0b94d1cf8ccb0d71b60c
  B-D     2013-06-25 17:04:16
Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18/rev/29933d1937db
BuildID   20130625070217
Version   18.0

* Reproduce Steps
1. Fill large file to /data and system will pop up "device space low" message.
Filesystem                 Size         Used         Free    Blksize
/data                  1007.90M      973.78M       34.12M       4096
2. Make sure all message in Message app are read.
3. MO a SMS to another device.
You will see sending icon spins even another site has got the message.
4. Back to Message list.
The 1st message has unread item.
5. Tap the message sent in step 3.
The text message sent is not in the thread.

* Expected Result
1. Need to know whether storage low will impact sms/mms function or not. If not, MT/MO sms/mms should work anyway.
2. If sms/mms functions will be disabled when storage is low, proper UI will be needed for user to know that releasing memory can enable them again.

Comment 1

[Enpei]

Attachment: logcat

Comment 2

[Enpei]

Video file is larger than 10MB, please check \\fs1.mozilla.com.tw\Public\QA\Enpei\891344.mp4 or let me know where I can upload the file to for you to check.

Enpei

Comment 3

[Fernando Jiménez Moreno [:ferjm]]

(In reply to echu from comment #0)
> When "device space low" message pops up, under this condition, MT a sms to
> device, it will not receive any.

We block any write to indexedDB, localStorage or appcache when we are in a low storage situation. So the device is probably receiving the MT sms/mms but it is not able to store it in the DB.

We can probably trigger MT events to allow the UI to show the incoming messages the same way that we can probably allow sending messages without storing them in the mobile message database.

Comment 4

[Gene Lian (I already quit Mozilla)]

One question: what does "MT" mean?

Comment 5

[Enpei]

MT - Mobile terminated, MO - Mobile originated, I will use "Send a message" term next time in case confusing people.

Comment 6

[Ken Chang[:kenkai]]

It is necessary for Madai project. Set 1.4+.

Comment 7

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Julien,

IMHO, for this issue, I'd like to suggest to separate it into 2 parts:
1. Inform the device user what cannot be done when storage is full. (Incoming Message is not able to be retrieved and Sending a message is not allowed.)
   - It seems that there has already been a notification informs user that the storage is low.
   - Can we reuse this notification with more informative wording to inform user that some features like messaging cannot be worked properly when storage is full?
   - Or can message App provide this specific info by listening to the status of device storage?
2. In this storage full situation, if the user still tries to send a text/multimedia message, the device shall notify the user that the message is not able to be sent due to storage full.

Hence, 
for the 1st part, it needs to be done in gaia layer.
for the 2nd part, we have filed a bug in bug#832140 to expose more error cause when accessing the MobileMessageDB, 
but we also need gaia's help to adopt the new error cause to inform user a proper error that the message is not able to be sent because of full storage.

How about keeping this bug for gaia and focusing on the change in gecko side by depending on bug#832140?

Do you agree this proposal or do you have other suggestion on this bug?

Bevis

Comment 8

[Julien Wajsberg [:julienw]]

Sounds good :)

Comment 9

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Enpei,

I just followed the reproducible steps you mentioned with same build ID and mater build on unagi.
However, I can not see the device pop up "device space low" message after I fill up /data partition to less than 5 MB.

Can you help to clarify if there is anything I missed?

Here are the commands I use to generate files and push to /data partition in Ubuntu:
1. genrandom <size in kb> <filename>
2. adb push <filename> /data/

Comment 10

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Julien,

Since this is a 1.4+ bug, 
will you also help to assign an owner to follow up this bug in gaia part mentioned in comment#7?
Or do we need someone else to support this instead?

Regards,
Bevis Tseng

Comment 11

[Fabien Cazenave [:kaze]]

Having a look as soon as bug 832140 gets ready.

Comment 12

[Bevis Tseng[:bevis][:btseng](Exited)]

After consulting Fabrice offline, 
to know if DiskSpaceWatcher is working on the test device,
"The first thing to do is to check if fanotify is actually enabled in the
kernel of the device you're using. The easy way to check that is to
restart b2g, and look into logcat. If you see the line "Warning: No
fanotify support in this device's kernel." then it's no surprise that
nothing works! If you have support, we'll have to dig deeper."

So far, In the devices I tried: unagi/hamachi, 
I saw same warning in the logcat after restart b2g.

Hence, we need the device that enables fanotify for further development.

Hi Enpei,

Would you please help to clarify which device you used while testing?

Thanks & regards,
Bevis Tseng

Comment 13

[Bevis Tseng[:bevis][:btseng](Exited)]

After discussed with Enpei offline, the test device is Leo.
We also need to know what else devices running 1.4 enable fanotify in its kernel for further developing/testing.

Comment 14

[Julien Wajsberg [:julienw]]

I surely hope all shipping devices have this support :/

Comment 15

[Bevis Tseng[:bevis][:btseng](Exited)]

Just re-flash latest base image of hamachi provided by vendor.
Now, I can reproduce this issue now.

Hi Thomas,

To fix/verify this bug, we have to make sure that 
the "fanotify" in the kernel of the test device is enabled mentioned in comment#12.

Can you help us to clarify what devices we have that enable this feature?
and can we request vendors to support this in the future if not enabled?

Regards,
Bevis Tseng

Comment 16

[thomas tsai]

what's the project?

Comment 17

[Bevis Tseng[:bevis][:btseng](Exited)]

Currently, this issue is marked as 1.4+.

Not for a specific project but for all the shipped and going to be shipped devices/projects, 
whether the fanotify is/will be enabled?

Comment 18

[thomas tsai]

yes, kernel always enables the function.

Comment 19

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

1.4? do not believe this is required for 1.4+ for Maida
ni? Wayne

and feature should not be plused

Comment 20

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

triage: add this to backlog

Comment 21

[Bevis Tseng[:bevis][:btseng](Exited)]

Change the dependency to bug 974820 because the solution to provide new error cause is no longer depends on the errorCode while accessing IndexedDB.

Comment 22

[Wayne Chang [:wchang]]

A Madai required feature depends on this, setting this 1.5+ so it is not lost.

Comment 23

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

it looks like we have all the gecko changes needed (bug 974820). Bevis can you please confirm?

Wayne, what is expected for Gaia? is Partner going to contribute? thanks

Comment 24

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Joe,

Yes, Gecko part has been done in bug 974820.

Regards,
Bevis Tseng

Comment 25

[David Scravaglieri [:scravag]]

Julien, please reassign if needed

Comment 26

[Julien Wajsberg [:julienw]]

We need UX for this.

Comment 27

[Carrie Wang [New account: [e-mail]]]

Omega will take care of the Message APP. Passing this to him. Thanks!

Comment 28

[Wayne Chang [:wchang]]

Partner specific needs are taken by and tracked by partner in bug 973784

Comment 29

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

Here is a UX proposal:
If storage is low, when launching Messages app, show a toast "You cannot send/receive messages since the storage is low." And the following items are disabled:
Compose message button
Attach button
Recipient list & add contact button
Message/subject input field

Comment 30

[Julien Wajsberg [:julienw]]

Thanks Omega!

Hey Bevis, do you know how we can know this? Should we have a new event from the MobileMessaging API? Or is there any more generic way of knowing this?

My preference would be for the Gecko API because the API knows how much storage it needs.

Comment 31

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Julien Wajsberg [:julienw] from comment #30)
> Thanks Omega!
> 
> Hey Bevis, do you know how we can know this? Should we have a new event from
> the MobileMessaging API? Or is there any more generic way of knowing this?
> 
> My preference would be for the Gecko API because the API knows how much
> storage it needs.

Hi Julien,

Please check the implementation in storage_watcher.js [1] for reference to
see How |DeviceStorage| can be used to inform that the Disk is full or not.
Internally, MobileMessageDB check isDiskFull via DiskSpaceWatcher which
is also used inside DeviceStorage.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/storage_watcher.js#L130

Comment 32

[Julien Wajsberg [:julienw]]

Bevis, how much space do we need to receive a MMS successfully? 1MB?

Also, do you think it could be possible to be notified that there is an error when receiving a SMS/MMS? This could be a better way...

Comment 33

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Julien Wajsberg [:julienw] from comment #32)
> Bevis, how much space do we need to receive a MMS successfully? 1MB?
> 
> Also, do you think it could be possible to be notified that there is an
> error when receiving a SMS/MMS? This could be a better way...

Hi Julien,

I'll suggest to add more information in the lowDiskSpaceNotification 
fired by app/system/storage_watcher instead.
Then, we don't have to do additional notification when receiving SMS/MMS.

Comment 34

[Julien Wajsberg [:julienw]]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #33)
> (In reply to Julien Wajsberg [:julienw] from comment #32)
> > Bevis, how much space do we need to receive a MMS successfully? 1MB?
> > 
> > Also, do you think it could be possible to be notified that there is an
> > error when receiving a SMS/MMS? This could be a better way...
> 
> Hi Julien,
> 
> I'll suggest to add more information in the lowDiskSpaceNotification 
> fired by app/system/storage_watcher instead.
> Then, we don't have to do additional notification when receiving SMS/MMS.

My idea was to notify the user that a message was not delivered because of this, instead of just notifying that the storage is low. I mean, both are useful.

I think I've seen this on older feature phones, and I think this would be a very good addition for us.

Comment 35

[Bevis Tseng[:bevis][:btseng](Exited)]

It sounds more likely to be a one-time notification.
IMHO, unless this notification is persistent (like low-disk-storage),
otherwise, this notification is not really useful to take user's attension. :(
That's why I prefer to have more generally notification for storage full instead.

Comment 37

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

triage: this was 2.0+ because it was used for madai tracking.
but Wayne's now using [m+] in whiteboard for madai tracking.
then i don't believe we need to block 2.0 with this
ni? Wanye

Comment 38

[Wayne Chang [:wchang]]

Still setting 2.0+ given the device's inability to receive SMS and also with madai v.s. 2.0 dates, we'll need this by 2.0 time in order for madai to see this.

Comment 39

[Julien Wajsberg [:julienw]]

unassigning to let others take this

Comment 41

[Steve Chung [:steveck]]

Just have some investigation and discussion with Omega, system will popup toaster and notification in current master, but we might still need to popup our own toaster for more information about message sending/recieving will be disabled because of low storage. This toaster will dismiss after few seconds but all the sending related widget will be disabled until data storage is sufficient.

Comment 42

[bhavana bajaj [:bajaj]]

(In reply to Wayne Chang [:wchang] from comment #38)
> Still setting 2.0+ given the device's inability to receive SMS and also with
> madai v.s. 2.0 dates, we'll need this by 2.0 time in order for madai to see
> this.

:wayne, this does not meet the blocking criteria defined to block a release. We have lived with it in the past so what has changed here for 2.0 ? This is a nice-to-have, and we can consider uplift of the fix depending on the risk if this is not ready by FL. 
Given we have created the feature-flags recently, you could probably use those to set the target release.

Comment 45

[Julien Wajsberg [:julienw]]

See latest spec at https://bugzilla.mozilla.org/show_bug.cgi?id=891344

Comment 46

[Julien Wajsberg [:julienw]]

Reseting assignee until we take this next sprint.

Comment 47

[Julien Wajsberg [:julienw]]

See latest spec at https://bugzilla.mozilla.org/show_bug.cgi?id=1167167

Comment 48

[Steve Chung [:steveck]]

cc Morpheus since he is message UX owner now.

Hi Candice, may I know the importance of this feature with feature-b2g 2.5 and minus blocking-b2g flag? It'll affect whether we'll put this in our planning because message app also has lots of NGA tasks ongoing.

I'm not sure why this 2.5 feature decision didn't not involve any engineer/UX. To fulfil this new user story, Except the effort estimation from gaia side, we'll also need:
  - Platform team's support: the current deviceStorage API could not meet this 5MB/10MB different level of the low storage handling.
  - UX/Visual team's review: This feature requires new UI component and control flow in the message app, they need to think carefully to prevent any unexpected edge case in low storage scenario.

These are necessary and not trivial efforts that need to be considered in estimation, so just a head up for people who might be involved in(if we really need this feature in 2.5).

Comment 49

[Julien Wajsberg [:julienw]]

Hey Steve,

I was actually involved in this UX for some weeks. Let me clarify some things:
* the 5/10MB levels are not for 2.5; for 2.5 we keep the current gecko behavior (minus a minor change to get a "change" event as soon as we register the event, if necessary, that Gabriele is working on right now)
* UX/Visual team: I raised this already. I agree all flows need to be looked to.

Comment 50

[Steve Chung [:steveck]]

(In reply to Julien Wajsberg [:julienw] (PTO Sept 2nd -> Sept 9th) from comment #49)
> Hey Steve,
> 
> I was actually involved in this UX for some weeks. Let me clarify some
> things:
> * the 5/10MB levels are not for 2.5; for 2.5 we keep the current gecko
> behavior (minus a minor change to get a "change" event as soon as we
> register the event, if necessary, that Gabriele is working on right now)
> * UX/Visual team: I raised this already. I agree all flows need to be looked
> to.

Thanks for the clarification, so I think we'll need another spec for 2.5 before planning?

Comment 51

[Julien Wajsberg [:julienw]]

I think Katie is coming back from holidays soon so she'll be able to come up with a new spec before next week's planning.

But I think we can plan the SMS work without the full spec, taking into account only the lower threshold defined on the spec. For example we can work on disabling our controls right now.

Comment 52

[Steve Chung [:steveck]]

Hi Kaite, seems we'll have different spec for 2.5 than original one based on the comment 49. Do you have schedule for 2.5 spec? Please ping us if you need more information from engineering side, thanks!

Comment 53

[katieC]

Hi Steve, thanks for being available. We have a meeting tomorrow am (sept 11) to review decisions and updates needed for 2.5. My goal is to then get an updated spec out for review asap. UX recommendations will align closely to Omega's comment 29.

I'll leave my NI for now, and remove it when I attach a link to a new UX spec soon.

Comment 54

[Steve Chung [:steveck]]

(In reply to katieC from comment #53)
> Hi Steve, thanks for being available. We have a meeting tomorrow am (sept
> 11) to review decisions and updates needed for 2.5. My goal is to then get
> an updated spec out for review asap. UX recommendations will align closely
> to Omega's comment 29.
> 
> I'll leave my NI for now, and remove it when I attach a link to a new UX
> spec soon.

Thanks! We definitely need this UX for 2.5 planning :)

Comment 55

[katieC]

2.5 Low Device Storage UX spec can be found here:
https://mozilla.box.com/s/bfrwwxdaz1o646h8tmmnlq61lv92sy3f

Comment 56

[Steve Chung [:steveck]]

Hi Katie,

Do we have other spec about other apps that block the sharing via message app? Because I didn't see this part in spec and we might need to block media sharing as well. And I also raise some concern about visual consistency to Morpheus and he will contact you for more details, thanks.

Comment 57

[katieC]

(In reply to Steve Chung [:steveck] from comment #56)

> Do we have other spec about other apps that block the sharing via message
> app? Because I didn't see this part in spec and we might need to block media
> sharing as well. 

No other spec that I know of. MVP for Low Storage - was to inform user that calls can be made/received, but won't be logged and SMS message can not be sent/received. I agree about looking to other apps that will be impacted by Low Storage condition - especially sharing media. NI'ing Wilfred about MVP, but I will also look into adding the scenario to the current UX spec.

Comment 58

[katieC]

Hi all,

Matej did a string review and we have an update. 
IxD and VsD Specs will be updated to reflect this change.

Please update strings from 'Low Device Storage' to 'Critically Low Storage'

Impacts:
• Settings App: Application Storage, Media Storage & App Permission
• System App: Lockscreen, System Toast & Utility Tray Notifications
• Message App: Low Storage Notice
• Dialer App: Low Storage Notice and Incoming/Outgoing Call Notifications

Comment 59

[Wilfred Mathanaraj [:WDM]]

we need to rethink all of low memeory management for a post 2.5 release. moving up to all product team visibility for future planning

Comment 60

[Oleg Zasypkin [:azasypkin]]

IIRC it's not 2.5+ feature anymore, but will likely be in v2.6?

Comment 61

[Wilfred Mathanaraj [:WDM]]

[Tracking Requested - why for this release]: this is not blocking 2.6 but if this can be addressed time permit. We shoud look at this post 2.6. hence backlog and P2.

Comment 62

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 63

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(