Closed Bug 800071 Opened 12 years ago Closed 12 years ago

Hide the quit menu item on ICS and greater versions

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox20 verified, relnote-firefox 20+)

Status:
VERIFIED FIXED
Milestone:
Firefox 20
Tracking Flags:
Tracking Status
firefox20 --- verified
relnote-firefox --- 20+

People

(Reporter: ibarlow, Unassigned)

References

Details

Attachments

(1 file)

Hide quit menu item on ICS+
1.33 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
The Quit function seems to be a feature left over from a time when XUL Fennec burned more memory and Android's memory management was poorer than it is now. We've since improved our browser and Google has improved Android, but "Quit" is still very visible… I question its usefulness, particularly at a time where we are exploring adding both "New private tab" and "New tab" in to that menu. (mockup http://cl.ly/image/1m3E1V3O2A1X/o) Let's move it into about:config, pref'd off by default. People who still use it can turn it on if they like.
Just to clarify, we want to hide the menu item, but create a Gecko preference to turn it back on if we want it. Updating the summary.
Summary: Move "Quit" to about:config → Add a preference to hide the quit menu item
This was one of the number one complaints on early versions of Firefox for Android (XUL) versions 4 through 7. I suspect removing it will draw some ire. Bug 659670 though not a lot of data there.
Note that in Jelly Bean it's relatively easy to close an app by swiping it off the app switcher. It might be worth leaving the Quit menu item on pre-Jelly-Bean devices but getting rid of it on Jelly Bean.
(In reply to Kartikaya Gupta (:kats) from comment #3) > Note that in Jelly Bean it's relatively easy to close an app by swiping it > off the app switcher. It might be worth leaving the Quit menu item on > pre-Jelly-Bean devices but getting rid of it on Jelly Bean. That sounds like a good plan, let's do that -- I might suggest extending that as far back as Honeycomb, since I believe everything from there on has a swipe-to-close app switcher.
(In reply to Ian Barlow (:ibarlow) from comment #4) > That sounds like a good plan, let's do that -- I might suggest extending > that as far back as Honeycomb, since I believe everything from there on has > a swipe-to-close app switcher. I can't swipe-to-close on my Galaxy Tab 10.1 with Honeycomb. It might work on ICS though; I only found out about after upgrading to JB.
Oops you're right actually. It was ICS that first introduced it.
Not all ICS phones have an app switcher button either, but I think anything that doesn't have a hardware menu button does.
(In reply to Kartikaya Gupta (:kats) from comment #3) > Note that in Jelly Bean it's relatively easy to close an app by swiping it > off the app switcher. It might be worth leaving the Quit menu item on > pre-Jelly-Bean devices but getting rid of it on Jelly Bean. So the current plan is to keep the menu for honeycomb and lower versions. We'll hide the menu for ICs and greater. We will not use a preference at all. Mainly because we have the "quit" case covered in all versions, and preferences are not version based. They are on or off, for all versions.
Summary: Add a preference to hide the quit menu item → Hide the quit menu item on ICS and greater versions
OS: Mac OS X → Android
Hardware: x86 → ARM
Any progress here? Would be great to hide the Quit button on ICS+ phones, especially now that we have New Tab and New Private tab pushing stuff down in the menu.
Is this bug just about this tiny change? Or am I missing something?
Attachment #690360 - Flags: review?(mark.finkle)
I have a feeling that this will make a lot of people complain. We should keep an eye on the input feedback once this hits beta.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #12) > I have a feeling that this will make a lot of people complain. We should > keep an eye on the input feedback once this hits beta. Just as a reference, the Android team explicitly advises against Exit buttons btw: http://blog.radioactiveyak.com/2010/05/when-to-include-exit-button-in-android.html
From that post: > In my experience what they really want is: > > An unambiguous way to guarantee that an app will stop consuming resources > (battery, CPU cycles, data transfer, etc). I completely agree with this. However the rest of the blog post says things like this: > In most cases the exit button simply calls Activity.finish. This is exactly > equivalent to hitting the back button. Which is not even a little bit true in our case, because we overload the back button to do a whole long list of things, none of which is Activity.finish. If we remove the exit button, then the there is no way for the user, from within Fennec, to easily stop it from consuming resources. They would have to use a task killer or the app switcher or something else.
As an aside, I had somebody try using my B2G phone yesterday. Even there, the first question he had after playing with an app was: "how do i exit this app?" The home button there leaves the app visible on the app switcher, and he wanted to exit it completely. There was no way to do it and it was clearly frustrating, even though it wasn't even his phone and I didn't care. I think for some people there's some deep psychological need to "clean up" after being done with something and not being able to do that just builds up a lot of frustration. (I know I'm definitely one of those people.) That being said I'm happy to let this patch land as long as we monitor feedback and make a data-driven decision on whether or not to leave it in.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14) > If we remove the exit button, then the there is no way for the user, from > within Fennec, to easily stop it from consuming resources. They would have > to use a task killer or the app switcher or something else. I think the main point here is that the app switcher in ICS+ makes it very simple to kill apps and having a top level menu item just for that seems unnecessary.
It may be unnecessary from a purely functional, rational standpoint. Users are anything but.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #15) > As an aside, I had somebody try using my B2G phone yesterday. Even there, > the first question he had after playing with an app was: "how do i exit this > app?" The home button there leaves the app visible on the app switcher, and > he wanted to exit it completely. There was no way to do it and it was > clearly frustrating, even though it wasn't even his phone and I didn't care. > I think for some people there's some deep psychological need to "clean up" > after being done with something and not being able to do that just builds up > a lot of frustration. (I know I'm definitely one of those people.) In B2G, you can actually swipe the app upwards in the app switcher to kill it, similarly to how you can swipe it to the side in the ICS+ app switcher on Android. I feel like people who are really insistent on quitting apps should just learn how to kill apps from the app switcher.
(In reply to Lucas Rocha (:lucasr) from comment #16) > I think the main point here is that the app switcher in ICS+ makes it very > simple to kill apps and having a top level menu item just for that seems > unnecessary. Exactly right.
(In reply to Margaret Leibovic [:margaret] from comment #18) > In B2G, you can actually swipe the app upwards in the app switcher to kill > it, similarly to how you can swipe it to the side in the ICS+ app switcher > on Android. Thanks for the tip. I did try that yesterday but I guess it didn't recognize my swipe as such. It works fine now though. > I feel like people who are really insistent on quitting apps should just > learn how to kill apps from the app switcher. I agree completely. Doesn't change the fact that most people won't.
Normally, quitting Firefox fires a bunch of messages that do cleanup before it's actually closed. Closing Fennec from Android's recent apps list will kill us cold, preventing clean quits. Obviously, we have this problem even without this patch, but are we robust enough to advertise this as the primary method for exiting Fennec?
(In reply to Brian Nicholson (:bnicholson) from comment #21) > Normally, quitting Firefox fires a bunch of messages that do cleanup before > it's actually closed. Closing Fennec from Android's recent apps list will > kill us cold, preventing clean quits. Obviously, we have this problem even > without this patch, but are we robust enough to advertise this as the > primary method for exiting Fennec? Actually, I think I was wrong here. Adding some logging, it looks like we call onDestroy() when we're closed from the recent apps list. I had assumed the behavior would be the same as when the "Force stop" button is clicked on the App info screen (which does not execute onDestroy()).
Comment on attachment 690360 [details] [diff] [review] Hide quit menu item on ICS+ Looks safe, and an add-on could add back the menu. Just needs to send out the "Browser:Quit" notification.
Attachment #690360 - Flags: review?(mark.finkle) → review+
https://hg.mozilla.org/mozilla-central/rev/478cdc0fc59f
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
:xti, can you update the smoke-test test-case to make note that it should be ran on ICS/JB+ only
Flags: in-moztrap?(nicolae.cristian)
(In reply to Aaron Train [:aaronmt] from comment #26) > :xti, can you update the smoke-test test-case to make note that it should be > ran on ICS/JB+ only (shouldn't)
(In reply to Aaron Train [:aaronmt] from comment #27) > (In reply to Aaron Train [:aaronmt] from comment #26) > > :xti, can you update the smoke-test test-case to make note that it should be > > ran on ICS/JB+ only > > (shouldn't) Sure. I disabled both tests for tablets and phones the 4.0 and 4.1 environment for Firefox 20. https://moztrap.mozilla.org/manage/case/1031/ The Quit Fennec option was removed from Firefox Menu on the latest Nightly. Closing bug as verified fixed on: Firefox 20.0a1 (2012-12-13) Device: Galaxy S2 OS: Android 4.0.3
Status: RESOLVED → VERIFIED
status-firefox20: --- → verified
Are we confident that Firefox won't drain resources when it's running in the background? I realize that you did this knowing that ICS makes it easy to quit apps without the menu item, but I for one only learnt about it in this bug.
Depends on what you have open. We're careful to throw away memory we don't need and to throttle all timers and things in the background. We've been trying not to gimp pages entirely though, so that (for instance) email apps can still run some times and show notifications, or a radio station can continue to play audio. Those pages have the page visibility api that they can also use to do throttle back their own activity as well.
This commit is problematic when it comes to users wanting to benefit from work done in bug 619521. This bug adds the possibility of adding fonts via add-ons for firefox to use to render international scripts with missing system fonts on Android. The current mechanism to make use of this feature: - Install an add-on - Manually restart Firefox for it to take into account the new font installed via add-on On the long run, the best behavior should be for firefox to not require a restart for the added fonts to be used. But in the meantime, the Quit menu is needed. Thoughts?
(In reply to Mathieu Pellerin from comment #31) > This commit is problematic when it comes to users wanting to benefit from > work done in bug 619521. This bug adds the possibility of adding fonts via > add-ons for firefox to use to render international scripts with missing > system fonts on Android. The current mechanism to make use of this feature: > - Install an add-on > - Manually restart Firefox for it to take into account the new font > installed via add-on > > On the long run, the best behavior should be for firefox to not require a > restart for the added fonts to be used. But in the meantime, the Quit menu > is needed. Thoughts? Unless the add-on is a restartless one, we display a doorhanger prompting the user to restart. I don't know if there's something different about these font add-ons you're describing, but if they also require users to restart to take effect, we should have them do the same thing.
Flags: in-moztrap?(nicolae.cristian) → in-moztrap+
kats asked me to file a bug, so I'm marking this as blocking the product announcements service (Bug 793053). If Fennec re-acquires a Quit menu item, I encourage y'all to make sure that it only ends the current browser activity. (I don't mind if one exists, only that it's safe.) Killing the process will terminate background services, which might painfully interrupt a sync, or -- worse -- terminate the product announcements service in such a way that it won't be restarted. Eventually it'll also kill FHR, and whatever other services we end up accruing. Generally, Android should be allowed to handle process start and end; manage your activities only. Testing condition: trigger a long-running sync, and enable the product announcements test addon to ensure that fetching occurs every 15 seconds. "Quit". Announcements fetches should continue to run every 15 seconds; Sync should continue uninterrupted. If they don't, I'd call that a bug. Phrased differently: if the user wants to kill all background services as well as the foreground UI, they can use the task killer. I encourage someone who's not on PTO to file the appropriate bugs :D
Blocks: 793053
I'm sorry but I completely disagree! Why risk a rating decrease when keeping the Quit option doesn't produce any issue at all? I use a Samsung Galaxy S2 phone with Android 4.0.3 and I hate to see the Quit option gone in Nightly! I don't have the app switcher, I don't want to use the task killer: I have to do too much tapping, it's not useful at all!
(In reply to Gabriela from comment #35) > I'm sorry but I completely disagree! Why risk a rating decrease when keeping > the Quit option doesn't produce any issue at all? > I use a Samsung Galaxy S2 phone with Android 4.0.3 and I hate to see the > Quit option gone in Nightly! I don't have the app switcher, I don't want to > use the task killer: I have to do too much tapping, it's not useful at all! You can get the quit menuitem back with this add-on: https://addons.mozilla.org/en-US/android/addon/quitnow/
(In reply to Margaret Leibovic [:margaret] from comment #36) > You can get the quit menuitem back with this add-on: > https://addons.mozilla.org/en-US/android/addon/quitnow/ Many thanks Margaret, I really appreciate the information! It's just that.... why should I have to add an add-on when the Quit option can be within the browser as a lot of Android apps have?
(In reply to Gabriela from comment #37) > Many thanks Margaret, I really appreciate the information! It's just > that.... why should I have to add an add-on when the Quit option can be > within the browser as a lot of Android apps have? The short answer is in Comment 13: most Android apps *should not* have quit buttons. If they jumped off a cliff, we would be foolish to follow. The long answer is that deciding to include a quit button is more complex than it first appears (see Comment 33: Fennec includes a number of background operations that need to keep running), and so even if we had a menu item labeled "Quit", it probably didn't work correctly, and the issue should be re-addressed more fully. An add-on is the perfect solution for "most people shouldn't do this, but some people want to" situations.
(In reply to Richard Newman [:rnewman] from comment #38) > The short answer is in Comment 13: most Android apps *should not* have quit > buttons. If they jumped off a cliff, we would be foolish to follow. > > The long answer is that deciding to include a quit button is more complex > than it first appears (see Comment 33: Fennec includes a number of > background operations that need to keep running), and so even if we had a > menu item labeled "Quit", it probably didn't work correctly, and the issue > should be re-addressed more fully. > > An add-on is the perfect solution for "most people shouldn't do this, but > some people want to" situations. Many thanks for your explanation Richard, I really appreciate it!
There's lots of negative feedback about the missing quit button. If we're not adding it back, we should at least explain the reasoning behind it.
relnote-firefox: --- → ?
^ These notes should be sure to reference the QuitNow add-on as well
I am lost. From the discussion in the bug 826066 (and others related), I was pretty sure that Mozilla was ready to add back the Quit button by default. The patch was even ready. Now all the bug reports which have been submitted since the Fedora 20 release are just marked as "resolved duplicate" of the commit which introduced the ***bug***. Does this mean that you throw away all the user complaints (see Mozilla Feedback, comments on Play Store, the amount of duplicate reports here, etc)? I must be mistaking...
(In reply to bahamut00 from comment #43) > I am lost. From the discussion in the bug 826066 (and others related), I was > pretty sure that Mozilla was ready to add back the Quit button by default. > The patch was even ready. > There's an add-on people can install if they want this functionality, and it was release-noted: https://addons.mozilla.org/en-US/android/addon/quitnow/
(In reply to bahamut00 from comment #43) > Does this mean that you throw away all the user > complaints (see Mozilla Feedback, comments on Play Store, the amount of > duplicate reports here, etc)? Basically, yes.
(In reply to lsblakk@mozilla.com from comment #44) > (In reply to bahamut00 from comment #43) > > I am lost. From the discussion in the bug 826066 (and others related), I was > > pretty sure that Mozilla was ready to add back the Quit button by default. > > The patch was even ready. > > > > There's an add-on people can install if they want this functionality, and it > was release-noted: https://addons.mozilla.org/en-US/android/addon/quitnow/ I know there is an add-on. Please read my initial bug report about this (bug 857477). Have you considered instead to let the Quit menu by default and provide an extension which hides the it? This will satisfy the Android extremists and the default will remain what the vast majority needs ("need", not only "want"). Android makes just an enormous mistake when advising browsing apps (internet browser, file browser, etc) to suggest their user to rewind all their browing session. I don't speak even about privacy problems, and the ***very*** bad feeling of the end user when he realizes an app which he has "left" is still running and doing things in background without its consent (buggy/lying/spying app/OS). Very disappointed that a few people are making choices for millions of others without listening to them.
Dear Kartikaya (or any other Firefox developper), can you please unmark the bugs 826066, 857477, and 857592 as "resolved duplicate" of the current ticket? They are not duplicate of this latter, and they have not been resolved. Saying so is just schizophrenic, and is dishonest for the people who took time to report what they think to be a bug in order to make Firefox better. If your team still persist in thinking that the current behavior is a feature and not a bug, then there are other statuses like "WONTFIX" or "NOTABUG" which fit better the situation. Thanks.
I duped them all to bug 820844 which is a WONTFIX.
Your strongest argument in favor of removing the Quit button was that "it is easy to close it with the app-switcher". It took me 6 months to discover it. Today. I would never have discovered it if I had not read again and again the above messages and wondered each time what you were talking about. There is no shortcut to this app switcher on my device (Android 4.1.2 under Samsung Galaxy SIII Mini); it can be opened with a long press on the Home button. It is well hidden and not in the interactive tutorial, I am almost sure that not the half of the average android users know it. Furthermore this switcher is ambiguous ("recent" apps or "running" apps?) and it is not obvious at all that swiping them closes them. My conclusion: the app switcher should be discarded from the arguments in favor of removing the Quit button.
(In reply to bahamut00 from comment #49) > Your strongest argument in favor of removing the Quit button was that "it is > easy to close it with the app-switcher". It took me 6 months to discover it. > Today. I would never have discovered it if I had not read again and again > the above messages and wondered each time what you were talking about. There > is no shortcut to this app switcher on my device (Android 4.1.2 under > Samsung Galaxy SIII Mini); it can be opened with a long press on the Home > button. It is well hidden and not in the interactive tutorial, I am almost > sure that not the half of the average android users know it. Furthermore > this switcher is ambiguous ("recent" apps or "running" apps?) and it is not > obvious at all that swiping them closes them. My conclusion: the app > switcher should be discarded from the arguments in favor of removing the > Quit button. I completely agree with you!!! I have a Samsung Galaxy S II phone running Android 4.0.3 and it's just the same. I never understood the logic of hiding the Quit button and face the negative feedback received anyway.
For your information, swiping out an app from the app switcher does not mean it is definitely closed. I just received a notification from an app while I had swiped out everything from the app switcher (namely Angry Birds, which I assume to be correctly programmed). In other words: it seems that Android does NOT guarantee that using the app switcher closes an application. Please consider this again.
(In reply to bahamut00 from comment #51) > In other words: it seems that Android does NOT guarantee that using the app > switcher closes an application. Please consider this again. The app switcher will close activities, not necessarily services or other notification sources.
(In reply to bahamut00 from comment #49) > Your strongest argument in favor of removing the Quit button was that "it is > easy to close it with the app-switcher". Actually I believe the argument is that we should be adhering to Android application implementation guidelines (http://www.youtube.com/watch?v=631T7B8HOv4)
I know this video. It provides only general guidelines, no restrictions. Developpers watch it, not users. My point in my comment was that the app-switcher and/or the swip-out feature is not known by the average Android user.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: