1037661 - [B2G][Flame][Messaging] Tapping home from a MMS results in the message being discarded

Status: RESOLVED WORKSFORME

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

Description

[Rachel Pribble [:rpribble]]

Attachment: Logcat.txt

Description:
If home is pressed after attaching images to a message, the message will be lost when the user reenters the SMS app. They will be returned to the main message thread list, and the MMS will not appear as a saved draft. If the same steps are followed with a SMS, the message will be saved as a draft or will still be available on the screen when the user reenters the messaging app.

Repro Steps:
1) Update a Flame to BuildID: 20140707000200
2) Messaging app > new message > attach an image from the gallery
3) Tap the home button
4) Reenter the messaging app

Actual:
A MMS will not be saved as a draft if the user taps home from creating it.

Expected:
A MMS is saved as a draft or still available on the screen if the user goes home then reenters the messaging app.

Environmental Variables:
Device: Flame 2.0 MOZ ril
BuildID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Notes: 


Repro frequency: 100%
See attached: Video (http://youtu.be/2ASKfd3letM), logcat

-----------------------------------------------

This issue also occurs on the Flame v2.1 (273MB), Flame base image v122, and Flame base image v121-2.

Environmental Variables:
Device: Flame Master (273MB)
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Environmental Variables:
Device: Flame 1.3 MOZ ril
Build ID: 20140616171114
Gaia: e1b7152715072d27e0880cdc6b637f82fa42bf4e
Gecko: e181a36ebafaa24e5390db9f597313406edfc794
Version: 28.0 (1.3)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

A MMS will not be saved as a draft if the user taps home from creating it.

Note: On both the Flame base v122 and Flame base v121-2, the messaging app will OOM close if an image is attached to a message.

----------------------------------------------

This issue does not occur on the Buri v2.1, Buri v1.4, Buri v2.0, Flame v2.0 (512MB), Flame v1.4, Open_C v2.1, Open_C v2.0, and Open_C v1.4.

Environmental Variables:
Device: Buri Master
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Environmental Variables:
Device: Buri 1.4 MOZ ril
Build ID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Environmental Variables:
Device: Buri 2.0 MOZ ril
Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Flame 2.0 (512MB) MOZ ril
BuildID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Flame 1.4 MOZ ril
Build ID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Environmental Variables:
Device: Open_C Master
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Environmental Variables:
Device: Open_C 2.0 MOZ ril
Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Open_C 1.4 MOZ ril
Build ID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

An MMS will allow the image to be attached normally, and will still be available on the screen if the user homes out then return to the app.

Comment 1

[Joshua Mitchell (Inactive)]

nomming on 2.0 based on data loss; if the user writes a message in the MMS it will be lost; a very  frustrating prospect

Comment 2

[Steve Chung [:steveck]]

I could not reproduce it with the latest build(build ID: 20140713160201) with 273MB limitation. Message app did face OOM issue when moving to background, but it still works fine if app keeps in foreground. Even the app is killed while in background, message app will save the content to draft while switching.  This mechanism should be work and verified because we also apply this mechanism in tarako. The problem might be the app is crashed before entering the background, but I can not reproduce this case either.

Hi Rachel, you said messaging app will OOM close if an image is attached to a message, Could you comfirm the OOM killed always happen(no matter the size of image) right after attaching image without switching to background? Because I could not see any crash in foreground from your video.

And another question for release menagement: Is it reasonable to raise these low memory issues at the end of the cycle? We've done tons of specific trick for tarako, but we're not sure if these workaround are still available for 2.0... It seems a tarako mightmare again if we really need to fix these issue at this moment.

Comment 3

[Harvey]

I am unable to reproduce this bug on either flame 2.1 or 2.0

Environmental Variables:
Device: Flame Master
Build ID: 20140714061512
Gaia: 88e0a972280bb35847c010b8c3f1481fa80f3847
Gecko: 340b19c14d3d
Version: 33.0a1 (Master)
Firmware Version: v122

Environmental Variables:
Device: Flame 2.0
Build ID: 20140714071406
Gaia: 726ca25ef1dbb83d8ed8a902b46fb340a3f95927
Gecko: 002aee8237a3
Version: 32.0a2 (2.0)
Firmware Version: v122

Comment 4

[Joshua Mitchell (Inactive)]

The original reporter is out today, I'm considering the WFM right now but will wait until she has a chance to repro and/or answer the questions directed at her.

Comment 5

[Steve Chung [:steveck]]

I can reproduce it now, but it's quite difficult to represent this at the beginning of use. The reproduce frequency shouldn't be as high as 100%, but the rate might increase after using for a period of time. It would be great if system could provide pre-kill event or even complete app life cycle management for oom handling, otherwise we could not guarantee no data loss because there's no proper timing for saving the draft.

Comment 6

[Julien Wajsberg [:julienw]]

Steve, is it possible that the draft save triggers OOM itself?

Rachel, can you please share the picture you're using?

Bhavana, is it reasonnable to call this a regression and make it a 2.0 blocker given this does not reproduce on Buri and Open C, on any version, and we haven't tried the same Flame setup on previous versions? I'm removing the "regression" keyword and respin the 2.0 flag.

IMO this is not a regression because this is the first time we use so less memory with a so big screen.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment #6)
> Steve, is it possible that the draft save triggers OOM itself?
> 
> Rachel, can you please share the picture you're using?
> 
> Bhavana, is it reasonnable to call this a regression and make it a 2.0
> blocker given this does not reproduce on Buri and Open C, on any version,
> and we haven't tried the same Flame setup on previous versions? I'm removing
> the "regression" keyword and respin the 2.0 flag.

This is wrong. We did support testing of Flame in 1.4 later in the release cycle, so fixing the flag here.

> 
> IMO this is not a regression because this is the first time we use so less
> memory with a so big screen.

Comment 8

[Rachel Pribble [:rpribble]]

Attachment: IMG_0001.jpg

Attaching one of the images I am using to encounter this issue on today's build, although I am seeing this issue regardless of what image is used. I tried cropping the image down to a smaller size and still see the issue, regardless of image size. I'm unsure of what is being asked in regard to foreground and background?

Comment 9

[Julien Wajsberg [:julienw]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #7)
> (In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment
> #6)
> > Steve, is it possible that the draft save triggers OOM itself?
> > 
> > Rachel, can you please share the picture you're using?
> > 
> > Bhavana, is it reasonnable to call this a regression and make it a 2.0
> > blocker given this does not reproduce on Buri and Open C, on any version,
> > and we haven't tried the same Flame setup on previous versions? I'm removing
> > the "regression" keyword and respin the 2.0 flag.
> 
> This is wrong. We did support testing of Flame in 1.4 later in the release
> cycle, so fixing the flag here.

I don't see evidence of the STR being tested in a Flame v1.4 with the same amount of memory (273MB).

Rachel, can you please confirm that you tested this?

Comment 10

[Rachel Pribble [:rpribble]]

The Flame v1.4 from the initial bug results is set to 273MB, the memory settings in parentheses was just forgotten. Should have read as follows:

Environmental Variables:
Device: Flame 1.4 MOZ ril (273MB)
Build ID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

The MMS will be saved as a draft if the user taps home during creation then returns to the SMS app.

Comment 11

[Rachel Pribble [:rpribble]]

After further investigation, the issue seems to occur if the user attaches an image then taps home before the app has finished resizing the image. The message will then be lost.

New repro steps:
1) Update a Flame to BuildID: 20140716040207
2) Messaging app > Create message > Attachment > Gallery
3) Select an image
4) Tap 'Done', then tap home quickly while the app is still resizing the image
5) Reenter the messaging app

Actual:
A MMS will not be saved as a draft if the user taps home from creating it. Information will be lost.

Expected:
A MMS is saved as a draft or still available on the screen if the user goes home then reenters the messaging app.

Repro rate following updated steps: 8/10

Comment 12

[Salvador de la Puente González [:salva]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #7)
> (In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment
> #6)
> > Steve, is it possible that the draft save triggers OOM itself?
> > 
> > Rachel, can you please share the picture you're using?
> > 
> > Bhavana, is it reasonnable to call this a regression and make it a 2.0
> > blocker given this does not reproduce on Buri and Open C, on any version,
> > and we haven't tried the same Flame setup on previous versions? I'm removing
> > the "regression" keyword and respin the 2.0 flag.
> 
> This is wrong. We did support testing of Flame in 1.4 later in the release
> cycle, so fixing the flag here.
> 
> > 
> > IMO this is not a regression because this is the first time we use so less
> > memory with a so big screen.

Jason, to use the 'regression' keyword here is dangerous and misleading. Is misleading because it suggests that some patch introduced in a bounded period of time caused a misbehavior. So there were a correct behavior under the same boundary conditions, which is not true as the hardware conditions has changed.

Furthermore, the OOM killer nature makes really difficult to blame an application in particular. It depends on the background services (Usage application, Find my Device, Settings, Push, Smart Collections...) at the testing moment.

According to what is said in comment 2 and taking a look into the code, the app should be saving the MMS as draft when going to background and (please, Julien, correct me if I'm wrong) there is no trivial way of get rid of this issue at all. We could minimize the chance for the OOM killer to terminate the app during saving a draft but nothing more.

Per comment 6, the testing procedure of Julien is a very pragmatic perspective we could use to determine if this will be a real end-user issue under **real scenarios**. Jason, could you please reconsider the 2.0+ flag or, at least, the regression flag?

Comment 13

[Salvador de la Puente González [:salva]]

Assigning to me to have this under watching.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Salvador de la Puente González [:salva] from comment #12)
> (In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #7)
> > (In reply to Julien Wajsberg [:julienw] (PTO Monday 14th July) from comment
> > #6)
> > > Steve, is it possible that the draft save triggers OOM itself?
> > > 
> > > Rachel, can you please share the picture you're using?
> > > 
> > > Bhavana, is it reasonnable to call this a regression and make it a 2.0
> > > blocker given this does not reproduce on Buri and Open C, on any version,
> > > and we haven't tried the same Flame setup on previous versions? I'm removing
> > > the "regression" keyword and respin the 2.0 flag.
> > 
> > This is wrong. We did support testing of Flame in 1.4 later in the release
> > cycle, so fixing the flag here.
> > 
> > > 
> > > IMO this is not a regression because this is the first time we use so less
> > > memory with a so big screen.
> 
> Jason, to use the 'regression' keyword here is dangerous and misleading. Is
> misleading because it suggests that some patch introduced in a bounded
> period of time caused a misbehavior. So there were a correct behavior under
> the same boundary conditions, which is not true as the hardware conditions
> has changed.

It is a regression. The tester confirmed this is working on 1.4, but busted on 2.0.

> 
> Furthermore, the OOM killer nature makes really difficult to blame an
> application in particular. It depends on the background services (Usage
> application, Find my Device, Settings, Push, Smart Collections...) at the
> testing moment.

If the OOM killer is more active in a STR in one release vs. the one before, then this points to a memory regression. We should be investigating what caused the memory increase.

> 
> According to what is said in comment 2 and taking a look into the code, the
> app should be saving the MMS as draft when going to background and (please,
> Julien, correct me if I'm wrong) there is no trivial way of get rid of this
> issue at all. We could minimize the chance for the OOM killer to terminate
> the app during saving a draft but nothing more.

Fixing the memory usage between 1.4 vs. 2.0 is probably the way to go here, as that's likely the cause.

> 
> Per comment 6, the testing procedure of Julien is a very pragmatic
> perspective we could use to determine if this will be a real end-user issue
> under **real scenarios**. Jason, could you please reconsider the 2.0+ flag
> or, at least, the regression flag?

This is a real user scenario. The STR used above represents an accurate STR that a user could do with a low memory device.

Comment 15

[Julien Wajsberg [:julienw]]

FYI Steve started working on a patch (I'd a pity he didn't share it) which basically reproduces what we did for the Tarako: save the draft when we have a change.

However, I don't think we want to save the draft before we resize the image. At least we'll need to try this and see how it performs, especially on such memory constraint.

FWIW I see very strange things happening around the Gallery on the Buri too.

As Salva said, maybe the issue is that the Homescreen takes too much memory and kill the app when we press home.

Comment 16

[Salvador de la Puente González [:salva]]

(In reply to Julien Wajsberg [:julienw] from comment #15)
> FYI Steve started working on a patch (I'd a pity he didn't share it) which
> basically reproduces what we did for the Tarako: save the draft when we have
> a change.

Please Steve, steal the bug when you're ready. Thank you.

Comment 17

[Julien Wajsberg [:julienw]]

(In reply to Rachel Pribble ([e-mail]) from comment #11)
> After further investigation, the issue seems to occur if the user attaches
> an image then taps home before the app has finished resizing the image. The
> message will then be lost.
> 
> New repro steps:
> 1) Update a Flame to BuildID: 20140716040207
> 2) Messaging app > Create message > Attachment > Gallery
> 3) Select an image
> 4) Tap 'Done', then tap home quickly while the app is still resizing the
> image
> 5) Reenter the messaging app
> 
> Actual:
> A MMS will not be saved as a draft if the user taps home from creating it.
> Information will be lost.
> 
> Expected:
> A MMS is saved as a draft or still available on the screen if the user goes
> home then reenters the messaging app.
> 
> Repro rate following updated steps: 8/10


Given the new repro steps, I'm renominating. I would not prevent the release for this.

Comment 18

[Preeti Raghunath(:Preeti)]

Based on the video 2.0+ for bad UX.

Comment 19

[Julien Wajsberg [:julienw]]

Sorry for being stubborn here.

I'd like that we try this STR again now that we switched the homescreen back to 4 columns to save memory. I'm quite sure this bug happens because of the memory taken by the new homescreen.

Any work we'll do here in SMS (and we committed to do it in this sprint) will be risky and that's why I'd rather not take it in 2.0 if we can avoid it.

Comment 20

[Julien Wajsberg [:julienw]]

As a data point, I don't see the issue on Buri with latest build.

Comment 21

[Julien Wajsberg [:julienw]]

(I mean, latest v2.0 build)

Comment 22

[Steve Chung [:steveck]]

Since this memory limitation cause app be killed once it switch to background and no proper event from system to handle the app life cycle, there is no correct way to fixed if we ignore the memory consumption from system-wise. The possible workaround in message app is saving the composing message to draft continuously, but this behavior is more likely a feature, and we need some feedback from UX for this changes.

Hi Jenny, if we makes save the draft auto while composing, do you think we still need option menu for save/discard if user exit the compose page? Or you still prefer to keep it and only save to draft before image attached?

Comment 23

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue still occurs on the latest 2.0 Flame build.  Following the steps in comment 11 resulted in the message not being saved.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140723062208
Gaia: ed998af8528c8b1bbd3aee6975ee9a1bdec1d429
Gecko: c74478151c2f
Version: 32.0 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 24

[Julien Wajsberg [:julienw]]

Jayme, I just want to make sure that the homescreen you see on your device has 4 columns of icons (instead of 3 before). Can you please confirm?

Comment 25

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I reinstalled the build to verify that 3 columns is the default.  I cannot reproduce the issue when I changed to 4 columns in the settings menu.

Comment 26

[Jenny Lee]

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

> Hi Jenny, if we makes save the draft auto while composing, do you think we
> still need option menu for save/discard if user exit the compose page? Or
> you still prefer to keep it and only save to draft before image attached?

Hello Steve, 
I like the idea of always saving as a workaround. As you mentioned our current behavior is not showing the save(replace)/discard option menu when we detect the current draft is saved. I think this makes sense, however, user wouldn't know if the edited message is saved or not, so if we're not showing the option menu, we should still display the "message saved as draft" toast/banner.  
Also I prefer to do auto on all cases, not just for attaching pictures. Thanks!

Comment 27

[Julien Wajsberg [:julienw]]

Thanks Jayme,
so this brings some weight to my argument :)

Hey Kevin, isn't 4 columns the default now? Does it depend on the device? Or maybe it was not uplifted to v2.0 yet?

Comment 28

[Kevin Grandon :kgrandon]

(In reply to Julien Wajsberg [:julienw] from comment #27)
> Thanks Jayme,
> so this brings some weight to my argument :)
> 
> Hey Kevin, isn't 4 columns the default now? Does it depend on the device? Or
> maybe it was not uplifted to v2.0 yet?

For devices with < 512 mb of memory we now show 4 columns, if your device has more than that we show 3 columns. Is there some correlation with columns and this bug?

Comment 29

[Kevin Grandon :kgrandon]

(In reply to Jayme Mercado [:JMercado] from comment #25)
> I reinstalled the build to verify that 3 columns is the default.  I cannot
> reproduce the issue when I changed to 4 columns in the settings menu.

A 256 mb flame should not have this setting. Can you confirm if you just installed gaia? Our optimizations don't take effect on 2.0 for a direct install or OTA unfortunately. You'll need to perform a full flash or reset-gaia.

Comment 30

[Lawrence Mandel [:lmandel] (use needinfo)]

Flagging for backlog based on comment 25. 4 columns is the default for 2.0.

Comment 31

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

(In reply to Kevin Grandon :kgrandon from comment #29)
> (In reply to Jayme Mercado [:JMercado] from comment #25)
> > I reinstalled the build to verify that 3 columns is the default.  I cannot
> > reproduce the issue when I changed to 4 columns in the settings menu.
> 
> A 256 mb flame should not have this setting. Can you confirm if you just
> installed gaia? Our optimizations don't take effect on 2.0 for a direct
> install or OTA unfortunately. You'll need to perform a full flash or
> reset-gaia.

Kevin: When flashing at low memory (273 mb or now 319 mb) this build does default to 4 columns.  As the flash takes 2-3 times longer on low memory I have been reverting to higher memory (512 mb) in order to cut the time down and then reverting to low memory.  I had not realized that the homescreen configuration was dependent on memory and will leave the memory settings low when flashing from now on.

Comment 32

[Steve Chung [:steveck]]

Hi Jayme, since the current low memory target is 319MB now, could you please verify again if this data lost issue still exist?

Comment 33

[Steve Chung [:steveck]]

BTW, if this issue still occur on 319MB with optimized homescreen, message app will propose to pre-save the image before resizing(UX didn't approve draft auto save feature for message app), otherwise we will close this bug instead.

Comment 34

[Jason Smith [:jsmith]]

QA Wanted for comment 32.

Comment 35

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue no longer occurs on the latest 2.0 and 2.1 flame builds when running 319 MB. 
Results: The message is not discarded when returning to the homescreen while the image resizes.

Environmental Variables:
Device: Flame Master
BuildID: 20140729063151
Gaia: 449d632c69b1a4bd5101d07d18f76799d3fd5f38
Gecko: 2fc48871c459
Version: 34.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0
BuildID: 20140729050146
Gaia: cfc4d71c36c6e9f6731f2060427f80e2996bc066
Gecko: 3c91cce0d473
Version: 32.0 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 36

[Joshua Mitchell (Inactive)]

issue no longer repros in 319 mem, unblocking but leaving open for perf investigation

Comment 37

[Steve Chung [:steveck]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #36)
> issue no longer repros in 319 mem, unblocking but leaving open for perf
> investigation

Since it's memory issue and I didn't see any perf related concern here, close as WORKSFORME first. Please reopen it if you still face any OOM with data lost on low memory testing.