1151748 - [Flame][Message]Relaunch Message app, device enters "New message" screen, it auto exits gallery select screen/ camera view finder screen/ select contact screen.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Shine(Leave from Mozilla)]

Attachment: logcat_0406.txt

[1.Description]:
According to Bug 1146256 in Comment 18, this bug is filed.
[Flame][v3.0][Message] Select Gallery/Video/Communications to add as attachment, press Home button and relaunch Message app, device enter "New message" screen, it does not enter gallery select screen/ camera view finder screen/ select contact screen.
See attachment: logcat_0406.txt & VIDEO1294_Compress.MP4
Found at: 04:06

[2.Testing Steps]: 
1. Launch Message app.
2. New create a message and attachment icon.
3. Select Video/Gallery/Camera/Communications on action menu.
4. Press Home button.
5. Relaunch Message app.

[3.Expected Result]: 
5. Device should enter gallery select screen/ camera view finder screen/ select contact screen.

[4.Actual Result]: 
5. Device enters "New message" screen, it auto exit gallery select screen/ camera view finder screen/ select contact screen.

[5.Reproduction build]: 
Device: Flame 2.2 (Unaffected)
Build ID               20150406002503
Gaia Revision          a6351e1197d54f8624523c2db9ba1418f2aa046f
Gaia Date              2015-04-03 22:06:41
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c3335a5d3063
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150406.040047
Firmware Date          Mon Apr  6 04:00:58 EDT 2015
Bootloader             L1TC000118D0

Flame 3.0 (Affected)
Build ID               20150406160205
Gaia Revision          834385f4c834238a4306bf87cc4be41615d91ff0
Gaia Date              2015-04-06 19:41:47
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/a530b5c3b713
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150406.194015
Firmware Date          Mon Apr  6 19:40:27 EDT 2015
Bootloader             L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test

[8.Note]:
Sometimes, select video/music on action menu to add attachment, press Home button and relaunch Message app, device enter "New message" screen too. but this occurrence rate is lower than selecting Gallery/Camera/Communications.

Comment 1

[Shine(Leave from Mozilla)]

Attachment: VIDEO1294_Compress.MP4

Comment 2

[Julien Wajsberg [:julienw]]

QA, here are some more questions for you:

* do you see the same issues when the Device has more memory ?
* is it 100% reproducible for Gallery/Camera/Communications ?
* can you check whether these apps were previously running? If yes, can you try to forcibly close them using the Task Manager before starting the "pick attachment" action?

Thanks !

Comment 3

[Brogan Zumwalt [Inactive]]

Only able to get issue to reproduce 100% when opening Camera from Messages app on Flame 3.0 with 319mb memory. On Flame 3.0 with 512mb memory I was unable to reproduce issue at all.

When user opens Gallery or Video from messages to attach a file, pressing home button then tapping messages app icon on homescreen returns user to Gallery or Video page as expected.

If user opens Camera from Messages to attach a file, pressing home button then tapping messages app icon on homescreen returns user to new message thread. Had this issue occur once when performing these actions when opening communications app from Messages, but this did not reproduce after 10 more attempts.

Overall tried opening Gallery, Video, Camera, and Communications from Messages app then performing rest of STR 15 times each on 319mb memory. On 512mb memory I attempted STR for same 6 times each.

Ensured that no apps besides Messages was running before performing pick attachment.


Device: Flame 3.0 Master
Build ID: 20150407010204
Gaia: c710bac533b76635161315bf907d004e000549cb
Gecko: ab0490972e1e
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Comment 4

[Julien Wajsberg [:julienw]]

Alive, I think this is one for you, at least to try to explain what's happening.

Thanks!

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

From the IRC discussion w/ Julien, I think this is expected - message app and the pick acitivity are both killed when the user goes to homescreen. We will relaunch the message app when it is killed at background, but it's impossible to restore the pick activity because gecko forgets the web activity when we relaunch the message app.

Julien said it works in v2.1 so I guess:
1. Bug 892371 changes something about this in platform.
2. Gallery activity or homescreen consumes more memory than v2.1.

In either guess system app has nothing to do :/

Comment 6

[Julien Wajsberg [:julienw]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #5)
> 
> Julien said it works in v2.1 so I guess:

No, actually, I don't know :)

QA: can you do a branch check?

And then a regression window would be nice !

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

Okay, from the log in https://bug1151748.bugzilla.mozilla.org/attachment.cgi?id=8588956
it says: only the ActivityWindow(Music) is killed each time we go back to homescreen.

I am not sure but is it possible that bug 892371 change introduces this? Or maybe this is expected and we are just doing the right things (kill the activity only is better than killing both)

Comment 8

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7)
> I am not sure but is it possible that bug 892371 change introduces this? Or
> maybe this is expected and we are just doing the right things (kill the
> activity only is better than killing both)

That shouldn't have any impact there as the changes only affected cases where we have two chained activities in the foreground (so three processes in total). Here when the user presses the home button both processes (SMS and gallery/video/etc...) will be sent to the background. Depending on the order in which they're sent one should be more likely to be killed than the other.

The question here is: how do we want to improve this behavior? If there's not enough memory left sending a process to the background will most likely kill it (because its priority drops below the homescreen's) even though there was enough memory to keep it alive as long as it was in the foreground.

I might think of ways to prevent this though it's not easy due to how the LMK works. More in general shouldn't we consider restarting an activity when it (and possibly its caller) have been killed this way?

Comment 9

[Julien Wajsberg [:julienw]]

Let's see if we can have a regression window !

IMO in case of LMK the current behavior looks the best but maybe we should show somme better feedback to the user, like: "due to low memory the app XXX was closed". I'm sure UX can find a better text.

Comment 10

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Julien Wajsberg [:julienw] (PTO April 6th) from comment #6)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #5)
> QA: can you do a branch check?
> 
> And then a regression window would be nice !

Findings on comment 3 is still true on latest. The branch check is done using the following STR:

0) No apps are running
1) Open Messages and tap on pencil icon
2) Tap on paper clip icon > Camera
3) Press Home button while in Camera
4) Return to Messages

Expected: Camera is displayed

Actual: New Messages is displayed
----

This issue occurs on 3.0, repro rate is 7 out of 7 attempts.

Device: Flame 3.0 Master (full flashed 319MB KK)
BuildID: 20150410010202
Gaia: e768af6558957ddb0f6a9ce579ea41c3e3d0b203
Gecko: fec90cbfbaad
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

----

This issue does NOT occur on Flame 2.2. Repro rate is 0 out of 10 attempts.

Device: Flame 2.2
BuildID: 20150410002502
Gaia: df0e04acad7c8c993f6ffe07b0ccb0ec20ee50bb
Gecko: 091b1cc1240b
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

---

Attempting to get the regression window now.

Comment 11

[Pi Wei Cheng [:piwei] (inactive)]

I found that shallow flashing makes the issue occur, even on v2.2.

For example, this build: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-b2g37_v2_2-flame-kk-eng/20150410083640/

Full flashing does NOT reproduce the issue. Bug repro rate 0 out of 10.
Shallow flashing DOES reproduce the issue. Bug Repro rate 1 out of 1.

We always do regression windows in shallow flash because we can only swap Gecko/Gaia using shallow flashing. I've tried shallow flashing on top of the full-flashed-Gonk and issue still occurs.

Removing window-wanted for now. I think we can still try to find last working/first broken with full flash on master, or last broken/first working with full flash on v2.2, but I just won't be able to tell whether it's a Gecko or Gaia that caused or fixed it and therefore won't be able to bisect further to inbound. Feel free to tag window-wanted again if this is something that is desired.

Comment 12

[Julien Wajsberg [:julienw]]

Pi Wei: could you check if there is a difference between full flashing v3.0 / shallow flashing v3.0 ?

Also, which is the base build you're shallow flashing on top of? Is it the base v18D build?

Comment 13

[Pi Wei Cheng [:piwei] (inactive)]

Both shallow flashing and full flashing v3.0 reproduce the issue.

We shallow flash on top of v18D-1 base image.

Comment 14

[Julien Wajsberg [:julienw]]

A regressionwindow would be nice, even if you can't find out whether gecko or gaia is the culprit.

Thanks !

Comment 15

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: attempted unsuccessful window results

Unable to find a regression window for this bug. On central during January - early February when I tried the repro steps I ran into bug 1120541. As soon as bug 1120541 was fixed, the bug started to reproduce.

On v2.2 b2g37 branch the bug does NOT repro on all the builds I've tried on.

Attached text file includes all the builds I've tried and their results.

Comment 16

[Julien Wajsberg [:julienw]]

Pi Wei, to carry on even with bug 1120541 I suggest to use a conversation instead of the "new message" panel.

Comment 17

[Pi Wei Cheng [:piwei] (inactive)]

That workaround does not work. See video:

https://www.youtube.com/watch?v=pYGXbTN7ie4

Comment 18

[Julien Wajsberg [:julienw]]

OK, I don't know what happens with this version...

Let's focus with what we should do from an UX point of view. Should we ask UX about my proposal in comment 9? Is it also technically possible?

Comment 19

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Julien Wajsberg [:julienw] (PTO April 6th) from comment #18)
> OK, I don't know what happens with this version...
> 
> Let's focus with what we should do from an UX point of view. Should we ask
> UX about my proposal in comment 9? Is it also technically possible?

The question is gaia does not know the activity is killed by a crash or an OOM..
Both of them comes with mozbrowsererror + detail.type = fatal.

So this is a question for gecko dev:
Fabrice, Gabriele, could we know the difference?

And another question is for UX: if we can't, could we just say: "the opened acitivty just closed due to crash or memory issue."?

Comment 20

[[:fabrice] Fabrice Desré]

crashes are triggering the crash reporter while OOM do not, so I'm pretty sure we can make the difference, yes.

Comment 21

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Fabrice Desré [:fabrice] from comment #20)
> crashes are triggering the crash reporter while OOM do not, so I'm pretty
> sure we can make the difference, yes.

Shall we file a bug for that? Sounds like a useful feature.

Comment 22

[BMO Automation]

Firefox OS is not being worked on