Currently, in the add-ons manager list view, the date that each add-on was last updated is visible on each add-on's entry. The design has been modified to remove this date, for a few reasons. 1. The intended purpose of the list view is to give a brief overview of the state of add-ons and to provide only the minimal, most used functionality. To this end, we're trying to simplify the information displayed in list view and show only the information most useful to give an overview of installed add-ons. By removing the last updated date, we not only provide more space per line, but eliminate the need for a sorting bar at the top of the UI. 2. Sorting by last updated date when updates are automatic does not provide useful functionality for most users. It allows users to see which add-ons have been updated most recently, but does not give any details about that update nor provide tools to interpret the information. Though some developers may use the last updated date as a diagnostic tool to identify which add-on updates may be causing recent problems in Firefox, the date makes a very poor diagnostic tool. One reason is that the date does not give any information about the size nor scope of the update, and thus can only be used for diagnosis by disabling one add-on at a time. In many cases, a problem in Firefox caused by an add-on would in many cases be instantly identifiable as being caused by a particular add-on (eg broken toolbar). Even if the update were not easily identifiable as a particular add-on, it could be caused by any number of reasons, and the chances of it being a recent add-on update would be only so large. Even if we did give fuller and more useful diagnostic information with the updated date, this is far removed from other diagnostic tools. It may be more helpful to provide information about add-on updates for problem diagnosis, but with other diagnostic tools in the UI. 3. The intended purpose of automatic updates is to remove updating from the list of things the user has to care about or remember. By exposing updated date in main UI, we insinuate both that updated date is important and possibly that this is a process the user should manage. 4. The reason sorting was proposed in the design in the first place was to give users the ability to sort their add-ons by performance. Sorting by performance would give a quick overview of which were the "biggest" add-ons in terms of metrics like startup time and memory. This would be particularly useful if add-ons the user does not want were large drains on Firefox's perforamnce. However, the ability to rank an add-on's performance is not going to be a part of Firefox 4.0, making the remaining sorting categories (alphabetic and updated date) much less useful.

(In reply to comment #0) > 4. The reason sorting was proposed in the design in the first place was to give [..] > of Firefox 4.0, making the remaining sorting categories (alphabetic and updated > date) much less useful. Please keep in mind that users want to flip between ascending vs. descending sorting order. So I wouldn't remove the header. Even looking into the future, when we probably have to add another sorting preference. Then we would have to re-implement everything.

(In reply to comment #1) > Please keep in mind that users want to flip between ascending vs. descending > sorting order. With a statically sorted list, switching between ascending and descending view only entails scrolling up from the bottom instead of down from the top. I think the added UI complexity isn't really warranted for this edge case. The more important sort would be to sort the enabled addons up top in a group and the disabled addons down below in another group. This has been discussed before; there a bug for this yet? (all I see is bug 562232, but that asks for an option not a permanent sort into two labeled/headered groups)

(In reply to comment #0) > 2. Sorting by last updated date when updates are automatic does not provide > useful functionality for most users. It allows users to see which add-ons have > been updated most recently, but does not give any details about that update nor > provide tools to interpret the information. Though some developers may use the > last updated date as a diagnostic tool to identify which add-on updates may be > causing recent problems in Firefox, the date makes a very poor diagnostic tool. > One reason is that the date does not give any information about the size nor > scope of the update, and thus can only be used for diagnosis by disabling one > add-on at a time. I disagree with this. If a user knows that their Firefox started behaving poorly since yesterday or a few days ago then the last update date will tell them what add-ons were updated in that range giving them a hint about what to start disabling.

In either safe mode or when extensions.checkCompatibility.4.0 is set to false the same bar is shown (bug 566194). Presumably this bar will still be displayed even if it is not present when the above conditions are not met.

I've only hidden the appropriate elements from view, is there any supporting code that also needs to be removed? I guess leaving the properties available is handy for extension developers.

Whoops, just realised there's a test that relies on #list-sorters. I could change it to test #updates-sorters or #search-sorters (ick), or change it to test the sort code but not the buttons. Suggestions?

Comment on attachment 503763 [details] [diff] [review] patch When removing elements that are never going to be visible do so in the XUL/XBL rather than just hiding them in the CSS. This patch looks like it completely hides the global warning area for the list view though which isn't what we want here. Boriss says we want to keep the last update date in the search view, you'll need to check that the searching tests actually verify it is there and correct.

(In reply to comment #7) > Comment on attachment 503763 [details] [diff] [review] > patch > > When removing elements that are never going to be visible do so in the XUL/XBL > rather than just hiding them in the CSS. This patch looks like it completely > hides the global warning area for the list view though which isn't what we want > here. I've hidden the date rather than removing it because that binding is also used for the other views which still want the date. The global warning area is only hidden when there's no warning.

Note that this would probably need to land before the last beta to give bug 624808 a chance at landing

I've repurposed browser_sorting.js to test the sorting code sans UI. Also changed browser_recentupdates.js and browser_searching.js to check the UI is visible and working.

Comment on attachment 505006 [details] [diff] [review] patch v2 Blair ought to be able to give this a pass sooner than me

As comment by myself already on bug 624808, I have to add the same comment here again: As more as I think about we should really keep the sort bar and add the "by state" sorting order. With a dozen of add-ons installed it's hard to find the one you are looking for otherwise. I feel it will be a major loss of functionality.

(In reply to comment #12) > As comment by myself already on bug 624808, I have to add the same comment here > again: > > As more as I think about we should really keep the sort bar and add the "by > state" sorting order. With a dozen of add-ons installed it's hard to find the > one you are looking for otherwise. I feel it will be a major loss of > functionality. I'm partial to doing it this way myself, we don't have the string(s) for it however. Is it too late?

(In reply to comment #12) > As comment by myself already on bug 624808, I have to add the same comment here > again: > > As more as I think about we should really keep the sort bar and add the "by > state" sorting order. With a dozen of add-ons installed it's hard to find the > one you are looking for otherwise. I feel it will be a major loss of > functionality. I'm not sure that sorting really helps you in that case unless you happen to be looking for an add-on that was updated recently. That is really the one remaining use case for the sort bar and it is basically only useful for troubleshooting situations which immediately (hopefully) makes it not for the common users. I am a little on the fence about it myself but Boriss has convinced me that this is a worthwhile improvement.

(In reply to comment #12) > As comment by myself already on bug 624808, I have to add the same comment here > again: > > As more as I think about we should really keep the sort bar and add the "by > state" sorting order. With a dozen of add-ons installed it's hard to find the > one you are looking for otherwise. I feel it will be a major loss of > functionality. I don't think that Last Updated date would necessarily help users find a particular add-on. They'd either need to 1. know when a particular add-on was updated, or 2. be manual updating add-ons. The global search bar would be a much faster way if a user knows the name of an add-on rather than it's Last Updated date, which I'm assuming would be most cases.

(In reply to comment #15) > I don't think that Last Updated date would necessarily help users find a > particular add-on. They'd either need to 1. know when a particular add-on was > updated, or 2. be manual updating add-ons. The global search bar would be a I have never told about last update date. IMO the most used sort criteria would be by name and by status (and second by name).

Dave, from your inspection, do we need a manual test?

What another pointless change.. I want to be able sort addons by Name and Last Updated at times.. and especially not have to go into each extensions view just see that last updated info....now its gone, I use a LOT more than 5 extensions unlike it seems those wanting these changes. This also effects the development AIOS with more unnecessary work because loss of functionality been removed 3 files. extensions.js extensions.xul browser_recentupdates When display:none on the sort bar /last updated details could have been just fine your Borgiss. You know if were going on this remove everything direction, why not remove the "description info ....More" totally pointless that, then bump up [Options] [Disable] [Remove] buttons so its all slimmer and we don't have this bloated extensions list! .. oh no... must have bloated looking list views with lots of empty blank space. Urrrgh

(In reply to comment #18) > Dave, from your inspection, do we need a manual test? No I think we're fine without

This is beyond 'surprise!' - you're removing the most useful info and function to 'provide more space per line' for what reason? it's empty! Who needs a plain list of exts. (which, btw, can't be even copy/pasted as the Lclick menu isn't there)? That's what people want - glance and quickly get an idea about what they have and what is happening with their addons. Why would anybody want to stare at a plain list and then go clicking around just to see when an ext. has been updated last? Why cancel sorting when it's one of the reasons people install MR Tech Toolkit? - to complete what's missing! No sense, whatsoever.

I agree. I used that feature many times. If you really want to "clear" the UI, why don't you just hide the sortings by default?

Pointless change is pointless, Status change: resolve as BROKEN This gets worse.. (disabled) extensions now all stack at the bottom of panel instead of adhering to at least some alphabetical order within the existing INSTALLED list extensions (like it always used to be!), they were easier to find and spot why the change now??...also [enable] does nothing.. I'm guessing its this nonbug that caused the regression. Do these counter issues and reasons for leaving things that work alone when you're not really improving the functionality at all, really have to be spelled out in big painted picture detail for it to be understood. Mokonda, I know, I know, design logic fail.. *features and functionality confusing* No sense monkey throw out. "Why cancel sorting when it's one of the reasons people install MR Tech Toolkit? - to complete what's missing!" Something tells me that useful extension ain't going to be coming back for LONG time what with this addon panel mess up and continued pointless cosmetic changes that aren't even wide user benefiting improvements.. like making the lists slimmer so as to decrease teh scrolling. Seeing as every last bit of actual useful information is being chucked out.. now that's an idea.

"extensions now all stack at the bottom of panel instead of adhering to at least some alphabetical order within the existing INSTALLED list extensions (like it always used to be!), " I forgot to add...disabled extensions at bottom in... NON alphabetical order.. I'm lovin' it. <sigh>

This bug is now resolved, if you want to start a discussion on why you think it is a bad idea then the most appropriate place is the newsgroups, mozilla.dev.apps.firefox probably.

Following on.. they might be in some order but there is no SORT bar to say. And that other last updated field information is no longer displayed for me to see.... so I haven't a clue what dis'order' disabled extensions are actually in. It's just not the same as enabled ones.. could be last updated? I guess I've got to just individually check them all. p.s I've come up with a new addons manager direction... see attachment above. :)

Roger that Dave... I'll head there right now.

Personally I think the best place to discus it is right here, where its been messed up.

(In reply to comment #29) > Personally I think the best place to discus it is right here, where its been > messed up. That's nice, but doing so would be a violation of bugzilla etiquette and could result in your account being disabled: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment on attachment 506893 [details] rude mocking of design Don't upload junk out of spite. Better yet, don't be spiteful. I'm getting sick and tired of a vocal minority of very rude individuals spamming bugs whenever there's even the most minor of changes they don't like. Please, stop clogging up our inboxes with rants. (though I expect instead a rude reply) I'm not going to bother defending the changes made here because they're fairly well thought out and get rid of things that nobody really needs. Yeah, there may be one or two that might care, and at least one is here complaining, but that does not mean that it wasn't the best move for the other few hundred million users. (In reply to comment #24) > I forgot to add...disabled extensions at bottom in... NON alphabetical order.. I don't see that here, but if you can reproduce that please file a new bug.

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre. Also checked safe-mode for the global warning box.