User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.2pre) Gecko/20110510 Firefox/4.0.2pre Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0.2pre) Gecko/20110510 Firefox/4.0.2pre In my opinion as a 20 hour a day, 7 days a week user, I think that the "Reload All Tabs" and "Bookmark All Tabs" are Way TOO close together. I, almost daily save All my tabs, as I update my nightly builds on 7 systems everyday and usually want to get back to where I was. I almost never, if ever "reload all tabs",, Often I reload the one I'm on, but never all.. They should be completely separate as they look so similar when going fast as I do. At the Very Least there should be a hr (separator) between them. That's it. Reproducible: Always Steps to Reproduce: 1. Right Click any Tab 2. 3. Actual Results: I hit "reload all tabs" by mistake Too Often. Expected Results: the "bookmark all tabs" save dialog should come up. I don't mind the BM all tabs not being in the Bookmarks menu, If you will make this change.. Waiting for 20 tabs to 'reload' sucks. The "reload all tabs" should not be directly on top of "bookmark all tabs". I bm all tabs daily as I use all 'nightly builds' on my 7 systems at home.
Component: Bookmarks & History → General
QA Contact: bookmarks → general
This is a valid feature request, the UI could be made less error-prone. Updating component and platform, it is probably universal.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: General → Menus
Ever confirmed: true
OS: Linux → All
QA Contact: general → menus
Hardware: x86_64 → All
Version: unspecified → Trunk
Thank You... this is still the norm without editing the menu. I Want It Changed! Aurora and Nightly have been hanging on Every restart if one tab hangs, has problems loading some **** stat or ad server on a page (the biggest offenders are google and googles youtube) and then morons that don't know what they are doing when they write a page. Anyways, with the tabs Always hanging, I right-click and what to bookmark all so I can kill firefox and start new session, but no, reloading all the tabs I just, one by one Stopped.. Please, this is an easy fix, Make it! thank you, Landis.
Guys,,, Thoroughly Sick of being in a hurry, no, doesn't matter if i'm in a hurry or not, it's Always a Pain in the A$$.. 50 tabs open, right click to 'book mark all tabs' so I can start closing some and BAM.. They all start 'reloading'.. Oh, and if I'm closing to reboot because my system is not connecting well.. How do you think that is? An Even Bigger Pain... MOVE the *#%&ing 'reload all tabs' option!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Landis.
I don't think an additional hr would save you in this case, do you have any other suggestions for what would help?
I'm actually quite skeptical to the usefulness of "Reload All Tabs". I find that there are very few use-cases for it's existence: 1) User unchecks "Don't load tabs until selected." User performs a session restore while offline or connected to a captive portal. 2) The user has opened many news/current events type websites that will have updated information if reloaded. The first case is quite edge-casey, and the second one is a bit useful but most likely isn't frequent. We could fix this bug quite easily by just removing the "Reload All Tabs" menuitem.
Created attachment 815112 [details] [diff] [review] Patch Please see comment #5 for my justification for this change.
(In reply to Jared Wein [:jaws] from comment #5) > The first case is quite edge-casey, and the second one is a bit useful but > most likely isn't frequent. Do you have data to support that? How does the usage stack up against other items in that menu?
Ilana, do you have any heatmap data for the tab context menu?
(In reply to Jared Wein [:jaws] from comment #6) > Created attachment 815112 [details] [diff] [review] > Patch > > Please see comment #5 for my justification for this change. Not sure how universal this problem is (two options being too close together), and we should get some data before we decide to remove "Reload all tabs" entirely. IMO if "Reload all tabs" is actually been used, putting it below "reload tab" makes a little bit more sense to me. But again, not sure how universal this problem is so that we need to change it and break people's existing habit.
Comment on attachment 815112 [details] [diff] [review] Patch Removing review flag until UX makes a decision. A less breaking change would be to show a confirmation dialog before reloading if there are many tabs. It would be similar to dialog for closing too many tabs. For the captive portal or offline case, the user should be able to simply restart the whole browser to reload all the tabs. As long as our startup time isn't horrible, this seems like a decent solution for that case.
If this is still open, usage of both is essentially 0. We can only capture 1 week of usage at a time, so we don't really see this used at all. If misclicking is an issue, a better solution is to rethink the design layout completely.
Comment on attachment 815112 [details] [diff] [review] Patch Reflagging for review now that we have the data that this is unused.
(In reply to Jared Wein [:jaws] from comment #12) > Comment on attachment 815112 [details] [diff] [review] > Patch > > Reflagging for review now that we have the data that this is unused. Where is that data? How do the numbers look in relation to the other context menu items?
(In reply to Dão Gottwald [:dao] from comment #13) > (In reply to Jared Wein [:jaws] from comment #12) > > Comment on attachment 815112 [details] [diff] [review] > > Patch > > > > Reflagging for review now that we have the data that this is unused. > > Where is that data? How do the numbers look in relation to the other context > menu items? I was referencing the information that Ilana provided. Ilana, can you make this data available?
Sure, I can pull this in the next few days. The caveat that we only have a week at a time still holds, however. Jared and Dao, what would the data have to look like in order for this change to go through? Frankly I think that this will be slapping a bandaid on a much larger problem with usage of the context menu, but I'm open to debating the data once I pull it.
(In reply to Ilana from comment #15) > Jared and Dao, what would the data have to look like in order for this > change to go through? Frankly I think that this will be slapping a bandaid > on a much larger problem with usage of the context menu, but I'm open to > debating the data once I pull it. Removing this item becomes an arbitrary move if we don't evaluate it in relation to the other items, since a good share of them likely aren't used a lot (and we've just recently added the rather esoteric "Close Tabs to the Right" feature). So I think we should demonstrate that this item is of lower value than the other items. This might actually be trickier than comparing raw usage numbers, because some features may be used only once in a blue moon but be really crucial to the user's work flow when used. So this will need some human judgement.
Dao, I understand that you'd like to see that the item is of lower value. What I'm asking is what numbers/patterns you would see that would indicate that it should be axed (less than 1/2 usage of others? for example). I've observed that if a cutoff point isn't determined before the data is shown, you will see "what you want to see" in the data. If your gut says that this item should be removed, go ahead and do it. I'm pretty sure that I'm going to come up with a legitimate 0, so fair warning that you'll have to make a gut call on this anyway.
Only having a week's worth of data won't help us much here, because there just isn't enough information on these items. This does basically come down to a judgement call here. I'd like to see other items in the context menu reconsidered as well, but I don't think we need to do them all at once.
(In reply to Ilana from comment #17) > Dao, I understand that you'd like to see that the item is of lower value. > What I'm asking is what numbers/patterns you would see that would indicate > that it should be axed (less than 1/2 usage of others? for example). Right. I wouldn't draw a line, because that's not my field of expertise (we have a UX team for that) and then I think it's not as simple as drawing a line somewhere. The numbers may need to be weighted. (For example, "Pin Tab" having relatively low usage numbers wouldn't make us remove it, because that context menu item is the only way to pin tabs (-> high value when used) and it's only reasonable to expect that pinning tabs is a less frequent action than reloading or closing tabs.) > I've > observed that if a cutoff point isn't determined before the data is shown, > you will see "what you want to see" in the data. If your gut says that this > item should be removed, go ahead and do it. Personally, I don't want to see any particular result. I'm fine with keeping it and I'm fine with removing it as long as we make an informed decision. > I'm pretty sure that I'm going > to come up with a legitimate 0, so fair warning that you'll have to make a > gut call on this anyway. Ok, but then it will still be interesting to see the other numbers. E.g. if there are multiple zeros, then I don't think we have the data to proceed here. In that case we should probably try to get more data and rethink this whole menu.
4 years ago
If you'd like to make an informed decision and this is a priority project, we should set up a study that looks at usage over many, many users over a long period of time, since we'd have to detect some seriously fringe behavior. Knowing that it is a very minor point, is it worth the effort? My gut, personally, says that this is a worthwhile project iff it is part of the effort to rethink the context menu entirely (see some of the research done by user Sean Bolton, for example).
This is currently very low priority and not something that we should spend a large amount of time on at the moment. I do think you are right though that this should be accompanied by a rethink/reevaluation of all of our context menu items.
(This is using analyst time on a 2-year-old, once reported bug. jaws++)
Unassigning as I haven't been working on this and I don't want to hold people up.
Assignee: jaws → nobody
Status: ASSIGNED → NEW
I rather disagree with the premise that these are so similar that it be terribly easy to pick the wrong one. Reload All Tabs Bookmark All Tabs OTOH I don't see how it would hurt to put Reload All Tabs next to Reload Tab.
You need to log in before you can comment on or make changes to this bug.