Closed Bug 1127102 Opened 9 years ago Closed 9 years ago

[E-Mail] Returning to home closes app; can kill other open apps on open

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-master affected)

RESOLVED WORKSFORME
Tracking Status
b2g-master --- affected

People

(Reporter: onelson, Unassigned)

References

()

Details

(Whiteboard: [3.0-Daily-Testing])

Attachments

(1 file)

Description:
The user can potentially reach a state with their E-Mail application where on open it can kill other open applications; this can be observed by viewing all other cards in Card View by holding down the home button. When the E-Mail app is minimized and returned to home, the user will observe that the app actually closes. 
Unable to determine actual repro steps, will list what the believed repro is thought to be. 

PreReq:
* No E-Mail app is signed in
* Steps 2-3 can be skipped if you have a video that can be shared to E-Mail
Repro Steps:
1) Update a Flame to 20150128010234
2) Open 'Messages' app.
3) Add an attachment from Camera: record a video.
4) Tap Home and open 'Videos' app.
5) Tap recorded video from step 3 and share with E-Mail.
6) Share Activty will request user to sign in to an E-Mail app to continue.
7) Sign into E-Mail account.
8) Send file.
9) Return to E-Mail App.
10) Observe Breaking Behaviors below.

Actual:
1) Opening E-Mail app may close other open apps (hold home to see card view and other apps close.
2) Tapping home while in E-Mail app to minimize the app, will close the app.

Expected:
E-Mail account is signed in and app doesn't close abnormally.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150128010234
Gaia: 1d53fb07984298253aad64bfa4236b7167ee3d4d
Gecko: b2b10231606b
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0


Repro frequency: 1/7
See attached: 
video- http://youtu.be/yY_wk_Wt5eM
logcat
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [3.0-Daily-Testing]
Flags: needinfo?(pbylenga)
Adding qawanted for branch checks and to see if we can find better STRs.
QA Whiteboard: [QAnalyst-Triage?]
Keywords: qawanted
The closure of background apps is expected based on memory usage on the device.

The two potentially memory-intensive things that can happen are:

1) Attaching the video.  We base64 encode it in chunks and write them back to disk.  We do our best to make everything garbage-collectible, but we don't actually control when the GC runs.  It's possible for GC behaviour to have regressed over time.

2) Sending the message.  We're actually fairly clever about performing chunked reads and using flow control.  We take much smaller bites here, but our rate of garbage generation is a function of network throughput, so it's conceivable we could generate a lot of garbage.  It's also possible, although not exceedingly likely, that the platform could have regressed in the Blob accesses we're doing and be loading more up.


The logcat doesn't include the attaching or sending process, so there's relatively little to go on for guessing purposes.  However, the most useful thing that can be provided in a situation like this is a screenshot from either the WebIDE's "View... Runtime" UI or from its origin tool that's still separately available, https://github.com/digitarald/firewatch.

NB: I've filed bug 1127152 on being able to export the memory logs from the Runtime Monitor so we can do better than screenshots in the future.
Unable to reproduce this bug after one hour of trying the original STR plus some app switching via task manager after STR. I kept hitting bug 1120541, but NOT this bug.

Tested on reported build
Device: Flame (319MB, full flash)
BuildID: 20150128010234
Gaia: 1d53fb07984298253aad64bfa4236b7167ee3d4d
Gecko: b2b10231606b
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Leaving stepswanted tag for others to attempt.
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
Attempted repro for one with no luck.  Leaving the tag for someone else to try.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150129010239
Gaia: 9d2378a9ef092ab1fc15c3a9f7fc4171aab59d57
Gecko: 6bfc0e1c4b29
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Flags: needinfo?(ktucker)
I also was not able to reproduce this bug. I tried various share activities with attaching media files and opening multiple apps. No solid STRs is found.

Device: Flame Master (319mb, full flash)
Build ID: 20150130010210
Gaia: 8238eeacc7030b2cdbf7ab4eba2f36779b702599
Gecko: 29b05d283b00
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage?]
3 testers were unable to reproduce this issue so closing worksforme. Please feel free to reopen if the issue occurs again.
Status: NEW → RESOLVED
Closed: 9 years ago
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: steps-wanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: