Closed Bug 1027626 Opened 5 years ago Closed 5 years ago
Homescreen remains in background
Device: Flame Version: v1.4 Build: https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g30_v1_4-flame-eng/2014/06/2014-06-16-00-02-02/ Ram: 256 (https://developer.mozilla.org/en/Firefox_OS/Developer_phone_guide/Flame#RAM_adjustment) STR: 0. (have ~30 games on the homescreen) 1. Open an(other) application and press the home button to go back to the home screen. 2. Repeat 1. Expected: - Applications are going to the background, and are maybe killed. Seen: - Pressing the home-button does not go back to the home-screen. - An application remains useable on foreground / Or an application remains visible, but touch events are transmitted to the homescreen. - Pressing the home-button for a long time bring the card view, but the foreground application might not be listed among them. (found while hand-fuzzing to reproduce Bug 1016512)
I'm assuming qawanted is here to see if someone else can reproduce.
After flashing the phone with the same image. I managed to reproduce this bug in a minute. The logcat which contains the following manipulation: - went throught the FPU, - apply the STR (without step 0.) - reproduce the same issue with the email app staying as a foreground application.
(In reply to Jason Smith [:jsmith] from comment #1) > I'm assuming qawanted is here to see if someone else can reproduce. Yes, to confirm that this is indeed an issue on v1.4 and to get someone to fix it, as I constantly hit this issue while looking for Bug 1016512.
(In reply to Nicolas B. Pierron [:nbp] from comment #3) > Yes, to confirm that this is indeed an issue on v1.4 and to get someone to > fix it, as I constantly hit this issue while looking for Bug 1016512. I also noticed the same error messages in the logcat of Bug 1016512. Maybe this is a duplicate, in the mean time I will flag it as a blocker.
QA-Wanted: We can't test this with 256 MB Flame due to Bug 1008050 blocking us; let's try to test this on 1.4 Buri
I was able to reproduce this on 1.4 Buri
QA Contact: jmercado
Environmental Variables for the above comment. I'm going through other Buri builds to see if this issue reproduces. Device: Buri 1.4 BuildID: 20140623045741 Gaia: 3419a1f68aaf64a0688685bce42d4173b6125597 Gecko: ccf2fada2574 Version: 30.0 (1.4) Firmware Version: v1.2device.cfg
This issue does not occur on the latest 1.3 Buri, 2.0 Buri, or 2.1 Buri builds Environmental Variables: Device: Buri 1.3 BuildID: 20140619045734 Gaia: 5f4211ac94cc158a07269d0a0beca3c7937d78cc Gecko: ace309b4ec92 Version: 28.0 (1.3) Firmware Version: v1.2device.cfg Environmental Variables: Device: Buri 2.0 BuildID: 20140623112942 Gaia: 112b26d38f9ef91ca00d435055f5d28267423e53 Gecko: 2a6029bf443f Version: 32.0a2 (2.0) Firmware Version: v1.2device.cfg Device: Buri Master BuildID: 20140623075647 Gaia: 41cc1de26e4edbe12add0009cdc0bd292f2e94fe Gecko: 31de1a84b27f Version: 33.0a1 (Master) Firmware Version: v1.2device.cfg Homescreen was always reached as expected.
QA Whiteboard: [QAnalyst-Triage?]
regression from 1.4 to 1.3, holding off on regression-window keyword until it is determined if this is a blocker or not
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
QA Whiteboard: [QAnalyst-Triage+]
blocking on it for 1.4
blocking-b2g: 1.4? → 1.4+
Wayne, do we need this in Dolphin project? If we don't, I suggest to remove this bug from 1.4+ list. Thanks.
Not specifically requested by partner but I would like to see this fixed as a user given the observed problem and user impact.
Hi Tim, mind taking a look and assign? thanks.
Spoke offline about this - getting a window here is going to be a royal pain, since reproducing this takes up to 30 min to complete. On that regard, striking the window request.
Alive, do you think this is something we can debug or this need to be handled by the performance team? Seems to be OOM-handling related.
Flags: needinfo?(timdream) → needinfo?(alive)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #15) > Alive, do you think this is something we can debug or this need to be > handled by the performance team? Seems to be OOM-handling related. This one looks like dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=1019419 But I cannot repro on flame :( The fix in bug 1019419 is a workaround to kill all active window if there is when user press home button. It's a workaround but valid. If this cannot be reproduced in 2.0/2.1 I think we should not dig too deep here.
bug 1019419:both the homescreen and the foreground app are alive and 'active'. bug 1031225:the foreground app is 'active' but not alive, no PID when seeing it from |adb shell b2g-ps|. I'm not sure if the foreground app is still alive or not when this issue occurs.If the foreground app is still alive,then maybe it's a dupe of bug 1019419, and the workaround is valid.But if the foreground app is not alive, then maybe it's a dupe of bug 1031225, and no patch for the issue now.FYI.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Remove blocker: If this is dupe of bug 1019419 -> it's not a blocker anymore. If this is dupe of bug 1031225 -> has wip patch and running monkey test. Re-nom if above bugs are fixed but problem still exists.
blocking-b2g: 1.4+ → backlog
Taking since I'm working on this.
Assignee: tzhuang → kgrandon
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1047645
You need to log in before you can comment on or make changes to this bug.