I reproduced this multiple time on the test driver phone (1.1.0, with 256 MB): STR (almost identical to Bug 874256): 1. Start with all apps closed 2. Begin rapidly opening apps from the dock. Do not allow the apps to actually finish painting. I opened: Browser, Contacts, SMS, Dialer and Maps 3. Long Press to open card view. 3'. Wait for a while, until one of the app gets killed. 4. Try to open a killed app. Actual: Nothing happens. Expected: The App should be started again.

If this is not reproduced in 1.0.1 we should move this to leo triage. Could this be a duplicated of bug 872912?

(In reply to Daniel Coloma:dcoloma from comment #1) > If this is not reproduced in 1.0.1 we should move this to leo triage. Could > this be a duplicated of bug 872912? Yeah, this sounds like a dupe of bug 872912.

(In reply to Jason Smith [:jsmith] from comment #2) > (In reply to Daniel Coloma:dcoloma from comment #1) > > If this is not reproduced in 1.0.1 we should move this to leo triage. Could > > this be a duplicated of bug 872912? > > Yeah, this sounds like a dupe of bug 872912. > > *** This bug has been marked as a duplicate of bug 872912 *** Can you explain why you think this is a duplicate? I don't think this is a duplicate of Bug 872912, as the touch screen is responding. As described, in this bug the killed applications (not by the user, but by the kernel) cannot be resumed from the task switcher. You can swipe to another card and resume a running applications.

An easier way to reproduce is to follow the following procedure: - Connect the phone to a computer - Start multiple applications - Go to the task switcher - Run "adb shell b2g-ps" - Run "adb shell kill -15 PID" (where PID is one of the PID of the application listed above) - Try to resume the killed application within the task switcher => Fail This does not seems to the same way with the Browser application, but you get a web-page which mention "Firefox can't find file at app://browser.gaiamobile.org/null." This reproduce 100% of the time on a Unagi flashed with a 2.0.0.0 with 512 MB of RAM available. I bet this bug is likely to be present in 1.0.1 too. Can you try to reproduce it with this new method?

I tested it on an Inari with a 1.0.1 at jason desk, and was able to reproduce with the steps describe in comment 4. As mention to Jason, this bug might also happen without using adb, when an application is killed by the kernel while running in the background. I can also reproduce it with the following STR: - Start the membuster application, and bust the system memory - Open the task switcher - Wait for a while (until the membuster application got killed by the kernel) - Try to open the Membuster application from the task switcher. Seen: - Nothing happen when tapping on the Membuster card of the task switcher. Expected: - Restart the Membuster application when tapping on the Membuster card, if the application is dead.

Jason, you saw this, what do you think about this being tef+? I mean, how frequent is this to happen and what is user impact.

(In reply to Daniel Coloma:dcoloma from comment #6) > Jason, you saw this, what do you think about this being tef+? I mean, how > frequent is this to happen and what is user impact. I would not block on this. The use case this could happen is if the app was killed while the task switcher was open allowing the user to return to the app. That's an edge case. Worst thing that happens here is that if a user did hit this on the chance they did, exiting and returning to the card view would fix the problem.

I think I saw this in bug 877049. In my case, exiting and returning to the card view did not fix the problem. I had to restart the phone.

Firefox OS is not being worked on