Closed
Bug 1010721
Opened 10 years ago
Closed 10 years ago
onDestroy is not called when Fennec is closed via the back button
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: mail, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release) Build ID: 20140314220517 Steps to reproduce: Android Jellybean 4.2.2 on Samsung Galaxy Tab3 8" SM-T310 Start Firefox Close Firefox with back-button/close-button Actual results: Firefox windows closes but keeps on running in the background. Only way to stop it is with the Android Task Manager. Expected results: Like every other app, Firefox should be closed completely when hitting the back- / close button. Or a Close command in the app itself. I know there is an add-on for it but think it's strange for a normal Close command to install an add-on.
Comment 1•10 years ago
|
||
The back button does not 'quit' the browser the way you think it does. This is not how Android operates. If you do want to use a true quit, you can try using QuitNow: https://addons.mozilla.org/en-US/android/addon/quitnow/?src=cb-dl-featured > Like every other app, Firefox should be closed completely when hitting the back- / close button. Android applications do not 'close' on device back button press, they are backgrounded like Firefox.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
I know what you mean. For example the GMail app: with the backbutton it "closes". It disappears from the Active Applications list. But there is a kind of hibernation active but that's all. Just a tiny bit of resources are consumed. All the apps I have are having this same behaviour. But when Firefox is "closed" with the backbutton, it is not visible but it's stays active in real time. Eating a lot of resources, mostly RAM, while the Firefox window is not open. It's the only app that stays listed in the Active Applications list even when the app is "closed". I know there is an add-on for it but being it the *only* app that is doing this, I thought this to be a bug because it's the only app showing this behaviour.
(In reply to Menno555 from comment #2) > Eating a lot of resources, mostly RAM, In general, a majority of your RAM should be allocated towards applications - this ensures they start up quickly when you resume them. The fact that Firefox maintains its RAM when in the background is to be expected. If the device needs more RAM for the foreground application, it will tell Firefox to free some memory, if not kill it outright. I wouldn't worry about the RAM consumption. > It's the only app that stays listed in the Active Applications list even > when the app is "closed". We run a few background tasks typically related to resource cleanup which are initialized when the browser closes (though they may not actually run until later - that's up to Android), so it's to be expected that Firefox keeps running. Android should kill these background tasks if the resources are needed by the foreground application. Other apps also run background services - in particular, I've seen them right after starting my phone - but I suppose they have a tendency to run them at less intrusive times. This issue has been raised before so we've been looking to perform some tasks at less interruptive times such as when the screen is turned off (see bug 983437). If you don't mind, I'm curious what the running Service is. If you could click on Firefox in Settings -> Apps -> Running and tell us the Service names (or take a screenshot), it'd be appreciated!
Flags: needinfo?(mail)
In the task manager Firefox is showing as active and running. In the Android Settings/Apps/Running it is not showing though. It only shows there under "Process in cache": Firefox. Background process in cache. 127 MB. I can open that and then there is only an option "Stop".
Flags: needinfo?(mail)
Clarifying question: When you mentioned the "Active Applications" list in comment 2, was that refering to your task manager's active applications list, or the android settings's active applications list? If the former, there are two possibilities that I see: 1) Firefox was running background services while the Task Manager was open, but closed by the time the Apps settings menu was opened 2) There is an inconsistency in the way the task manager represents "Active Applications" from the Android system. We also register various alarms and receivers with the system - perhaps even these could be considered an "Active Application". Which task manager are you using? Maybe I can find some details on how it represents active applications.
Flags: needinfo?(mail)
(In reply to Michael Comella (:mcomella) from comment #5) > Clarifying question: When you mentioned the "Active Applications" list in > comment 2, was that refering to your task manager's active applications > list, or the android settings's active applications list? I was referring to the Task Manager / Active Applications.
Flags: needinfo?(mail)
(In reply to Menno555 from comment #6) > I was referring to the Task Manager / Active Applications. This appears to be an application on Samsung devices - I have it on my Galaxy Tab (but not my Galaxy Nexus). There is a difference in state after closing an application via pressing back vs. the home button, where hitting back will explicitly destroy the Activity, and pressing Home lets the system decide. For example, Google Talk maintains ~8MB and remains in the Active Applications list when hitting home and maintains ~4MB and disappears from the Active Applications list after hitting back. I'm not sure why Firefox does not exhibit this behavior, even with background Services running (i.e. hitting back and home appears to have the same effect on app state). Finkle, any ideas? Is this to be expected? Note that it is possible to remove Firefox from the Samsung Task Manager's "Active Applications" list by swiping it closed from the recent applications list, which also reduces its usage from ~70MB to ~7MB.
Flags: needinfo?(mark.finkle)
Comment 8•10 years ago
|
||
(In reply to Michael Comella (:mcomella) from comment #7) > I'm not sure why Firefox does not exhibit this behavior, even with > background Services running (i.e. hitting back and home appears to have the > same effect on app state). > > Finkle, any ideas? Is this to be expected? If killing the Activity must be explicitly done by our code, then I know why it doesn't happen... we don't do it. Would we consider doing it? I don't know. A few givens: 1. Firefox takes longer to start if we need to cold start Gecko libraries. Would we need to reload the Gecko libraries when returning to Firefox? 2. Firefox responds to the system low-memory notifications by shedding as much memory as we can. Why bother trying to free up memory if no app is going to use it? If some app does need the memory, Android tells us and we shed memory.
Flags: needinfo?(mark.finkle)
Comment 9•10 years ago
|
||
3. We occasionally use Service.startForeground to keep some background processes alive if Firefox goes into the background. Could that be happening sometimes? http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/NotificationService.java#30
(In reply to Mark Finkle (:mfinkle) from comment #8) > (In reply to Michael Comella (:mcomella) from comment #7) > > > I'm not sure why Firefox does not exhibit this behavior, even with > > background Services running (i.e. hitting back and home appears to have the > > same effect on app state). Sorry, `s/with/without/` > > Finkle, any ideas? Is this to be expected? > > If killing the Activity must be explicitly done by our code, then I know why > it doesn't happen... we don't do it. I just checked and we don't have to do it explicitly, Android just calls the appropriate lifecycle callbacks. In a new project, hitting home calls onPause -> onStop, and hitting back calls onPause -> onStop -> onDestroy. In Fennec, we never get onDestroy when hitting back. Perhaps there some configuration we set that prevents this from happening? (In reply to Mark Finkle (:mfinkle) from comment #9) > 3. We occasionally use Service.startForeground to keep some background > processes alive if Firefox goes into the background. Could that be happening > sometimes? This does happen, but appears to be independent of the issue above.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Firefox keeps running in background when closed → onDestroy is not called when Fennec is closed via the back button
Comment 11•10 years ago
|
||
(In reply to Michael Comella (:mcomella) from comment #10) > I just checked and we don't have to do it explicitly, Android just calls the > appropriate lifecycle callbacks. In a new project, hitting home calls > onPause -> onStop, and hitting back calls onPause -> onStop -> onDestroy. In > Fennec, we never get onDestroy when hitting back. > > Perhaps there some configuration we set that prevents this from happening? By default, onBackPressed calls finish, which destroys the activity. We override onBackPressed to avoid this.
(In reply to Brian Nicholson (:bnicholson) from comment #11) > By default, onBackPressed calls finish, which destroys the activity. We > override onBackPressed to avoid this. Then it sounds like this is working as intended.
Status: NEW → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → INVALID
See Also: → 1045589
Comment 13•10 years ago
|
||
"We override onBackPressed to avoid this."..."Then it sounds like this is working as intended." Just because it is working as intended, it doesnt necessarily mean that the *intended* is correct. Personally I still dont understand why it has to remain active as an ACTIVE APPLICATION just to preserve some 'load time'. Users know their device and know the consequences from starting apps from fresh (regarding speed, and consequential battery performance). And they also have the control of THEIR devices. And if they choose to close outright their browser, knowing that the next time they launch it it will take that extra time to start then that is the users prerogative to do. Is it right that firefox developers dictate to the user how to preserve their system? (treating users as fools). Im sure, that like other applications, a level of the Firefox system can go to a background process just like all other apps ready for 'quick launch' from the MRU application list or its own launcher icon. I personally dont care about the RAM, as android does take care of that. But the difference is that an active foreground process will be using more CPU than a dormant background process and that affects battery performance. And forcing the user to 'exit firefox, swipe to go to ACTIVE APPLICATIONS, find firefox and SWIPE to kill' affects a users performance....and his patience. Therefore, I still dont understand why this application behaves like this, when many other standard apps 'close', disappear from ACTIVE APPLICATIONS yet maintain a presence as a cached background process for a 'quick start' just fine. (As you say, you deliberately choose to stop it behaving like these other apps - otherwise it would be just fine. Im sure).
(In reply to jimimaseye from comment #13) > Just because it is working as intended, it doesnt necessarily mean that the > *intended* is correct. Without documentation, it's hard to say what is correct beyond convention and, while I can't speak for the team, I'd argue that this Android convention isn't a very strong one - it just happens to be a convenient default. For our use case, it's not very convenient (see below). I too remember seeing this "back button closes the application" behavior in the official documentation (maybe pre-HC era?) but I can no longer find it - perhaps because it's no longer always the desired behavior. > But the difference is > that an active foreground process will be using more CPU than a dormant > background process and that affects battery performance. And forcing the > user to 'exit firefox, swipe to go to ACTIVE APPLICATIONS, After pressing back, Firfeox only appears in the "Active Applications" while using the Samsung Application Manager. On other devices (such as my Nexus 4), it appears as a "cached process". We are overridding the default behavior to maintain this "cached process" state no matter which button is pressed to leave the application and do not intend to use CPU or drain battery (if you see these issues, please file a bug!). For the majority of users, there is likely no concept of closing the browser completely, or the differences between closing an application via the back button or the home button, so it's not worth hurting their user experience by, if they happen to hit the wrong button, forcing them to wait for the platform to load (particularly on slower devices) to satisfy an arguable convention. For the few that do desire to close the browser completely, an alternative such as QuitNow [1] is available. [1]: https://addons.mozilla.org/en-us/android/addon/quitnow/
Comment 15•10 years ago
|
||
Ok Michael. Thanks you for your reply. Very succinct and clear, and more importantly, not bullish (referring to certain attitude I read from 'contributors' on the other bug regarding this issue.) You explain it well and I am ok with it. QuitNow will remain.....
Assignee | ||
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•