All users were logged out of Bugzilla on October 13th, 2018

the list of events for the listbox (unifinder) is sorted three times



14 years ago
8 years ago


(Reporter: mvl, Unassigned)



Bug Flags:
blocking-calendar1.0 +


(Whiteboard: [not needed beta][no l10n impact])

The list of events for displaying in the listbox is sorted three times before
the user sees it.
1. inside libxpical, by date
2. in function calEvent_getAllEvents (or one of it's friends), by date
3. in the actual display, by whatever the user selected.

The first two seem redundant, at least in this case. Are there cases where they
are needed? If so, can we pass a parameter or something, to skip sorting if not


13 years ago
QA Contact: gurganbl → sunbird

Comment 1

13 years ago
with lots of entries, of course, (I have 1,200) this could explain some of the performance problems reported elsewhere.

Comment 2

13 years ago
(In reply to comment #1)
> with lots of entries, of course, (I have 1,200) this could explain some of the
> performance problems reported elsewhere.

This bug is pretty old, and our method of getting the events from a calendar has changed since it was filed.  In particular, (1) is gone and (2) is obsolete.  Events are now returned based on their next occurrence, which works, in a vague way, if the unifinder sort is based on start/end columns.  (I would need to look into the details of which column might use this.)  (3) still exists, and is necessary in all cases other than where we can re-use the sort.  Still, Array.protoype.sort(), which is what (3) uses, is reasonably fast.  There are other areas in the unifinder that have much more severe consequences on our performance.  See also

mvl, any objection to closing this bug?

Comment 3

13 years ago
1 still exists, but is now insed the provider. Don't know about 2 (maybe the composite does some sorting). 3 also still exists.
Let's keep it open until we are sure.
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Unifinder is also available in Lightning now.
Component: Sunbird Only → General
QA Contact: sunbird → general
Keywords: perf
Summary: the list of events for the listbox (unifinder) is sorted tree times → the list of events for the listbox (unifinder) is sorted three times
Flags: blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]

Comment 6

9 years ago

Is this bug still valid. if that is the case I am ready to work on it with some guidance.

Kind Regards
Christophe, I'm glad you'd like to step up. I'm not sure how valid this still is, it requires some investigation. What you can do:

* Read some of the provider code (i.e storage/ics) to find out if there is some sorting being done.
* If applicable, read relevant libical code that retrieves items from an ics stream to see if it is sorted.

The mentioned point (3) is definitely needed, you'd need to find and comment out all sorting code in points (2) and (1). When you have this, check all places that call getItems() and see if they still do what they should.

Note that we don't really want to do code changes in libical itself. If its not possible to work around, we should file an upstream bug.
Assignee: nobody → c.humbert
Assignee: c.humbert → nobody
I had a look at this and believe, it is not valid anymore.

for 1.:
is now libical. (comm-central/calendar/libical)
The array sorting is done in [1], and does not seem to be called automatically inside libical [2].

for 2.:
should be the getItems(...) functions of the providers now.
After having looked through [3], I can not see any sorting code there

for 3.:
This is, where sorting should happen. And it does, when needed for added items [4]

So I believe, this bug can be closed.

Thanks for the investigation! Closing this bug as suggested.
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.