I have eight extensions installed and even this small number causes me to take a few seconds to scan the extension list for the one I want.

*** Bug 255876 has been marked as a duplicate of this bug. ***

Unfortunately no time to get to this. I'm thinking of some EM UI improvements for right after 1.0.

*** Bug 260789 has been marked as a duplicate of this bug. ***

The Extension Manager Buttons (EMButtons) extension for Firefox has an option to sort the list. http://moonwolf.mozdev.org/

There are indeed extensions to do this, but frankly, I think an extension is overkill for such basic stuff. Thanks for pointing it out though.

(In reply to comment #2) > Unfortunately no time to get to this. I'm thinking of some EM UI improvements > for right after 1.0. There really really should be a blocking 1.1 choice so these don't just go into limbo-land.

(In reply to comment #2) > Unfortunately no time to get to this. I'm thinking of some EM UI improvements > for right after 1.0. needs aviary landing keyword

1) Is it true that the order in the default listing reflects the order extensions are offered events etc for handling and therefore affects FF behaviour? I have seen several mentions of using 'move up'/'move down' as atempted problem solutions. 2) Having the listing available in order of installation can help in isolating rogue extensions, conflicts etc. 3) In light of above, perhaps the 'sorted display' facility should at least toggle between alpha sorted and the current '?functional/chronological?' ordering.

The extension Slim Extension List (http://v2studio.com/k/moz/) fixes this (it also reduces the space taken by each item in the list).

Slim Extension List only fixes this if you install it first before you install any other extensions. :-\

No, I just installed it and it sorted my pre-existing big list of extensions.

Try this: 1.) Start FF 2.) Install Slim Extension List 3.) !DO NOT RESTART FF! 4.) Install another extension (so both should get activated upon restart) 5.) Close and reopen FF 6.) Look at your extension list Also try my steps with Slim being last. See if that makes a difference.

(In reply to comment #9) > The extension Slim Extension List (http://v2studio.com/k/moz/) fixes this (it > also reduces the space taken by each item in the list). Sorry; The question in this place is not what extensions may or may not exist to circumvent this deficiency. It is whether it is perceived as a deficiency in the FF/TB product itself and if so then when and how that will be fixed. This is not a forum for discussing what individual extensions do (as against the way extensions in general, regarded as product features are accomodated and handled). It is for reporting bugs on FF/TB etc and progressing their cure. Like various features previously provided by extensions, this feature has now been recognized as being the proper province of the base products and therefore it is being handled here. Discussions on extensions belong elsewhere. I do get very weary of developers wingeing here about users quite properly trampling the corridors of their ivory towers with, heaven forbid, actual battle front / shop floor wisdom (which sometimes seems tragically absent nearer the design/coding coalface). However, this current sort of discussion is spam here and is liable to provoke immature, insulting and counterproductive reactions in the people who should be handling the base product bugs and deficiencies. At very best it is being ignored. Please take it to TEM or MozillaZine where we can discuss it. If you want the deficiency fixed, vote for it, if not, vote for something else you think is important. If you have end-user input on how the interface perhaps should work for you and why, then, unlike some, I believe that is more than legitimate material to post here. Best regards, RDL

(In reply to comment #9) > The extension Slim Extension List (http://v2studio.com/k/moz/) fixes this (it > also reduces the space taken by each item in the list). Sorry; The question in this place is not what extensions may or may not exist to circumvent this deficiency. It is whether it is perceived as a deficiency in the FF/TB product itself and if so then when and how that will be fixed. This is not a forum for discussing what individual extensions do (as against the way extensions in general, regarded as product features are accomodated and handled). It is for reporting bugs on FF/TB etc and progressing their cure. Like various features previously provided by extensions, this feature has now been recognized as being the proper province of the base products and therefore it is being handled here. Discussions on extensions belong elsewhere. I do get very weary of developers wingeing here about users quite properly trampling the corridors of their ivory towers with, heaven forbid, actual battle front / shop floor wisdom (which sometimes seems tragically absent nearer the design/coding coalface). However, this current sort of discussion is spam here and is liable to provoke immature, insulting and counterproductive reactions in the people who should be handling the base product bugs and deficiencies. At very best it is being ignored. Please take it to TEM or MozillaZine where we can discuss it. If you want the deficiency fixed, please vote for it, if not, vote for something else you think is important. If you have end-user input on how the interface perhaps should work for you and why, then, unlike some, I believe that is more than legitimate material to post here. Best regards, RDL

(In reply to comment #14) > If you have end-user input on how the interface perhaps should work for you and > why, then, unlike some, I believe that is more than legitimate material to post > here. Sorry. I've done what I should've done to begin with: submitted the "extensions take too much space" problem as an enhancement request (bug 289359).

This patch adds sortByType to the EM which allows sorting of both extensions and themes. I am going to wait for the patch in bug 285584 to land before submitting the ui portions of this patch and asking for review.

This patch adds sortTypeByName to allow sorting either extensions or themes via a context menuitem. It also adds the "move" context menu items to the theme manager's context menu. Note: bug 298055 has a patch waiting for review that adds DnD and keystroke support for reordering items in the Extension/Theme Manager.

Offtopic bugzilla question, but how come it shows 7-12 as the last modification date even though I got 2 email notifications and "View Bug Activity" shows activity yesterday?

So, this has been -'ed for 2.0. Is it just going into the WONTFIX bin then? I imagine since there is a patch, and an extension which does this from which the code could be borrowed, that a fix is not too far away, and it is just a decision at this point to not put it in, correct? Thanks.

There is neither a patch nor anybody working on it, so it can't block anything.

Code from Caio Chassot's Slim Extension List (http://v2studio.com/k/moz/). I just removed the functions.

Here is another extension to look at for clues: http://www.vesterman.com/FirefoxExtensions/SortExtensions also: http://www.extensionsmirror.nl/index.php?showtopic=1086 and: http://moonwolf.mozdev.org/#embfx might help. Thanks for looking into this.

(In reply to comment #22) - The first extension sorts the extensions inside of the files, which has been reported to be sometimes buggy. It's also very slow. - The two others use the same code from Torisugari, which sorts the extensions in memory and keep them sorted for the Firefox session. - The Caio Chassot's implementation, the faster one (nearly instantaneous here with 25 extensions), doesn't keep the extensions sorted for the Firefox session. But what is really interesting is that with these two last implementations, if an extension is installed while the list is sorted, it's kept sorted accross the sessions. So the patch I've submitted doesn't seem to be the best way to do it. To avoid any slow down (even a few ms), the extension list should be automatically sorted just before an extension installation.

Looking to the future, maybe beyond the scope of this bug, the ideal thing would be to have columns (like in Windows Explorer) where you could sort by clicking on extension name, status (enabled, disabled), home page, etc.

Sort Extensions (http://www.vesterman.com/FirefoxExtensions/SortExtensions), on which this bug fix could be based, has just been updated.

I can think of no reason to not automatically sort the extension list when a new extension gets installed. Given this, there doesn't need to be any UI change, context menu option, or anything like that. It would just work, and users could always expect the list to be alphabetically sorted. If we do decide to sort automatically, then the "Move to Top", "Move Up", and "Move Down" context menu items can be removed. However, that can be a separate bug if necessary.

*** Bug 318247 has been marked as a duplicate of this bug. ***

*** Bug 324165 has been marked as a duplicate of this bug. ***

*** Bug 225669 has been marked as a duplicate of this bug. ***

Fixed on trunk by the checkin of bug 329045

Robert, I wonder if your sorting implementation is the better one. There is a delay when we show the extensions list, but I was thinking that you only sorted them when a change occured ? If it's true, why this delay ?

The method used doesn't sort (e.g. move the add-ons in the RDF container) if there are no add-ons to sort. What are you seeing in the way of delay? Also, how many add-ons are in the list? What is the time difference between a build without the change and a build with the change. Also, just in case disable all your add-ons when you test it in with both builds in case it is an add-on causing the delay.

Well, actually there's no difference. I was misled by the fact that the delay is longer when showing the extensions list than the themes list. Additionnally, when clicking on a tab, we expect to see immediately its content.

Thomas - out of curiosity, how many extensions do you have installed?

23 plus 6 disabled.

Approximately how much of a delay are you seeing? I checked the time from launch to display and it has been consistently around .5 seconds with 30 extensions and around 1.5 seconds with 100. Of course these will vary depending on the system.

Indeed, it's around .5 second.