Closed Bug 1033646 Opened 5 years ago Closed 2 years ago
[Vertical Homescreen] an e
.me process should get killed if it had been installed and then removed
Build Information Device: Flame Gaia 3bfe47c58c959c42f5ffe0309b5380ea514ccd69 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/f40e767ea283 BuildID 20140702000201 Version 32.0a2 ro.build.version.incremental=109 ro.build.date=Mon Jun 16 16:51:29 CST 2014 B1TC00011220 Description Steps to Reproduce 1. go to e.me games collection 2. long tap on Tetris 3. save to homescreen 4. tap on Tetris 5. hit home 6. hit home again to get to the homescreen 7. longtap on tetris 8. select the x to delete tetris 9. long tap on home Expected Results: Tetris is not in the Task Manager Actual Results: Tetris is in the Task Manager Other Notes: 1. does not happen for packaged apps Reproduction Frequency: 100 %
Regression from 1.4. But I think this is more System issue. What do you think :kgrandon?
Yes, I don't think that the homescreen would control this, so moving to the relevant system component.
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
I am pretty sure this is not related to homescreen, so I'd like to remove blocking on bug 1015336 for now.
No longer blocks: 1015336
Note - Tetris isn't a hosted app, it's an e.me app. This is definitely a blocker though. App processes should always be killed if the app is uninstalled.
Summary: [Vertical Homescreen] a hosted app process should get killed if it had been installed and then removed. → [Vertical Homescreen] an e.me process should get killed if it had been installed and then removed
(In reply to Jason Smith [:jsmith] from comment #4) I confirm. I was not able to reproduce it with ConnectA2 (privileged) or Facebook (hosted).
Hi Candice, could you find someone for this? Thank you.
This isn't a vertical homescreen bug.
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
5 years ago
QA Wanted to recheck 1.4 again.
I'm not sure this is desirable behaviour. The wrapper windows e.me bookmarks open in are basically just like browser tabs which can navigate to any URL, there's no app manifest set in the mozapp attribute to identify them as a particular app. If I bookmark Google News from e.me to the homescreen, open Google news, tap on a news article to navigate the wrapper window to a news site, then remove the bookmark from the homescreen, I wouldn't expect my news story to get killed. You wouldn't expect a browser tab to close if you removed a bookmark in the browser. e.me "apps" in the sense that they're not "installed" they're just bookmarks which start a browser window at a particular URL.
I rechecked on today's 1.4 (Buri), 1.4 (OpenC) and 1.3 (Buri). The problem can be hit. The reason why I thought it was working in comment #1 is because of an OOM with 1.4 Buri that killed the app (reproduced with the camera app running in the background).
Confirmed on today's 1.4 Flame that issue occurs. Tetris process continues to display in card view after uninstallation. Tested on: Device: Flame Build ID: 20140707075127 Gaia: f2c118767aa26981386570e5d0bed95bab593de5 Gecko: 30ea9808e7d3 Version: 30.0 (1.4) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
Team is looking into this to confirm regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
This is not a regression. A e.me app in 1.4 will continue to be in a process even if the e.me app is removed. A marketplace hosted app (Youtube app ) will stop and get killed on deletion. (this occurs on 1.4 and master) As discussed in the system front end meeting, the difference is the hosted app versus bookmark, and the e.me app is a bookmark. Need UX input please; see comment 9.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
I think consistency here is important. Once we move bookmarks to the home screen, I think expectations may shift and the behavior should be consistent with other apps on the home screen. And so the process should be killed once the bookmark has been deleted. However, we should ensure that the delete confirmation dialog mentions the process will be closed down.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.