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.

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

(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.

One question: what does "MT" mean?

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

It is necessary for Madai project. Set 1.4+.

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

Sounds good :)

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/

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

Having a look as soon as bug 832140 gets ready.

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

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.

I surely hope all shipping devices have this support :/

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

what's the project?

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?

yes, kernel always enables the function.

1.4? do not believe this is required for 1.4+ for Maida ni? Wayne and feature should not be plused

triage: add this to backlog

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

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

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

Hi Joe, Yes, Gecko part has been done in bug 974820. Regards, Bevis Tseng

Julien, please reassign if needed

We need UX for this.

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

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

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

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.

(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

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...

(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.

(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) 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.

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.

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

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.

unassigning to let others take this

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.

(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.

Reseting assignee until we take this next sprint.

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

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).

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.

(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?

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.

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!

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.

(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 :)

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

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.

(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.

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

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

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

[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.

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

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