1131095 - [email][flame][319M?] Email seems to be immediately OOM-killed on switch to home screen, preventing draft saving.

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[No-Jun Park [:njpark]]

STR:
Open Email app, tap compose button
type text into the email 
Press home button to exit the app, then press Email app icon again

Actual:
The draft is not saved, goes back to the mail list view
Expected:
Goes back to the compose email view

This only reproduces in 3.0, not reproducible in 2.2

Version Info:
Gaia-Rev        0d7b35f23402c4cb29bca6b98280fec48a196dec
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/3436787a82d0
Build-ID        20150209010211
Version         38.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150209.045655
FW-Date         Mon Feb  9 04:57:06 EST 2015
Bootloader      L1TC000118D0

Comment 1

[No-Jun Park [:njpark]]

[Blocking Requested - why for this release]:
User will lose typed email content if user exits the email app to do other tasks

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

logcat, please (https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo)

Comment 3

[No-Jun Park [:njpark]]

Attachment: lostdraft.log

Logcat attached

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

From the log, it looks like the issue is that the test steps being performed are just happening too quickly while the app is still starting up.  The log indicates that the composer card is pushed before the back-end is loaded.  Because the "composer" instance is instantiated as the result of multiple async processes and _saveNeeded bails if (!this.composer) and I don't see the visibility change logging in the log (but do see it when I run locally), I think the home screen is being switched to before the composer is fully initialized.

I've locally just tested the draft logic on my trunk builds and things work correctly, so I'm assuming this is a correct analysis.

I think this does indicate there's a window of vulnerability at app startup, but assuming proper operation of the app, I think the question is whether we believe what the user could type in (at most) a few seconds is a huge loss.  I feel like this is likely to be something that would not arise outside (very efficient! :) QA testing and that it's not worth addressing, especially since the most likely fix would be to refuse to show the compose card until the composer is instantiated, and that would result in worse UX.  needinfo-ing :jrburke for his call.

:njpark, if I'm wrong in the time-scale, please let me know, ideally attaching a video to help us better understand the situation.  I expect we're just looking at IndexedDB or other load-time regressions on trunk that make it possible for a very adept human to win the race.

Comment 5

[No-Jun Park [:njpark]]

(In reply to Andrew Sutherland [:asuth] from comment #4)
> 
> :njpark, if I'm wrong in the time-scale, please let me know, ideally
> attaching a video to help us better understand the situation.  I expect
> we're just looking at IndexedDB or other load-time regressions on trunk that
> make it possible for a very adept human to win the race.

Hi Andrew, after reading your comments, I retested it, and it appears that if I type only a couple words, wait 1~2 seconds, exit and come back to the email app, it does preserve the draft.  However, if I type several rows of text instead of only a few keystrokes, it does not save the drafts no matter how much I waited before I went back to the homescreen.  It seems that the amount of text being entered does matter as well.  I think this might be more common to come across so we should nom it back for 3.0?

I attached below link for the video:
https://www.youtube.com/watch?v=zphA7S_PW5Q&feature=youtu.be

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Yes, the example in the video seems like a realistic test.  Based on what I'm seeing in the video, it looks like the email app is being immediately killed.  It's hard to tell for sure without a logcat that parallels the video, though.  (In general it's great to get a logcat from every reproduction we're talking about.  Unfortunately there's been a regression in the OomLogger and it looks like your device is not configured to do the super verbose window manager logging that I've been seeing from other logcats.  The window manager stuff makes it clear what's happening, so it would be great to figure out how to get that in the logcat.)

I'm back to testing on my flame with 1GB.  I'm assuming you're testing with 319M?  That could easily explain this.  In such a case, we may need to adjust the amount of memory we run 3.0 devices with and/or discuss with platform people if the available memory has substantially changed.  Email is nearly identical on v2.2 and v3.0, so platform really is the main thing to accuse of regressing.

So yeah, re-requesting blocking 3.0.

Comment 7

[James Burke [:jrburke]]

I agree that we would not want to delay showing the compose UI until the composer object was ready, that would be worse UX, would feel unresponsive.

As to the issue, I am testing with a 319MB RAM constrained Flame device, and I can see the same behavior as :njpark: if typing a few lines of text, then email gets OOM'ed before it has a chance to save. I can get smaller sets of compose changes in and have it survive enough to get an autosave. However, in those cases the app is still running in the background and immediately shows the compose card as before when switching back to the email app.

I also suspect a general platform issue because I feel like the platform is OOMing apps more aggressively than usual. For instance, I am usually able to swap between Email and Settings apps back and forth without OOM kills (usually done when I test locale changes). Lately, I would say since the later part of last week, that seems to have changed to this more aggressive OOM behavior.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

There may be some interaction with whether we perform a sync or not, too.  Specifically, we won't refresh the inbox if it's been refreshed in the last 10 minutes (and we managed to persist that to disk).  Running a sync will inherently use more memory and can result in greater IndexedDB transaction size which can in turn lead to greater main process memory use which could be a contributing factor.

It'd be interesting to see a graph of the WebIDE (or firewatch) from the different cases.  Although it might be most pragmatic for us to just mail dev-gaia and complain :)

Comment 9

[No-Jun Park [:njpark]]

Just noticed that this is not reproducible anymore on today's master.  I think something else fixed this?  I'll keep an eye on it for the next few days, and close it if the bug is gone for good.

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Nothing in email has notably changed that I'm aware of.  Comment 8 about the 10 minute refresh interval still stands.