254428 - Extension and theme list should be sorted by name (alphabetically)

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, enhancement)

Description

[:deanis74]

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.

Comment 1

[Jo Hermans]

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

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 3

[Peter van der Woude [:Peter6]]

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

Comment 4

[:deanis74]

The Extension Manager Buttons (EMButtons) extension for Firefox has an option to
sort the list.

http://moonwolf.mozdev.org/

Comment 5

[andrew.ferrier]

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.

Comment 6

[Worcester12345]

(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.

Comment 7

[Worcester12345]

(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

Comment 8

[RDL]

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.

Comment 9

[Chris Wood]

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

Comment 10

[Dan Fischbach]

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

Comment 11

[Justin Kerk]

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

Comment 12

[Dan Fischbach]

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.

Comment 13

[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, 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

Comment 14

[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

Comment 15

[Chris Wood]

(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).

Comment 16

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress

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.

Comment 17

[Robert Strong (they/them - no direct email)]

Attachment: patch

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.

Comment 18

[Worcester12345]

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?

Comment 19

[Worcester12345]

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.

Comment 20

[Thomas Bertels]

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

Comment 21

[Thomas Bertels]

Attachment: Sort by name

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

Comment 22

[Worcester12345]

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.

Comment 23

[Thomas Bertels]

(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.

Comment 24

[Worcester12345]

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.

Comment 25

[Worcester12345]

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

Comment 26

[Aaron P]

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.

Comment 27

[:Gavin Sharp [email: [e-mail]]]

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

Comment 28

[Steve England [:stevee]]

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

Comment 29

[Robert Strong (they/them - no direct email)]

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

Comment 30

[Robert Strong (they/them - no direct email)]

Fixed on trunk by the checkin of bug 329045

Comment 31

[Thomas Bertels]

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 ?

Comment 32

[Robert Strong (they/them - no direct email)]

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.

Comment 33

[Thomas Bertels]

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.

Comment 34

[Robert Strong (they/them - no direct email)]

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

Comment 35

[Thomas Bertels]

23 plus 6 disabled.

Comment 36

[Robert Strong (they/them - no direct email)]

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.

Comment 37

[Thomas Bertels]

Indeed, it's around .5 second.