Closed Bug 405034 Opened 17 years ago Closed 17 years ago

Task list doesn't persist sort order or column selection anymore

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: omar.bajraszewski, Assigned: michael.buettner)

References

Details

(Keywords: regression)

Attachments

(1 file)

Lt 2007112211&Tb2.0.0.9 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10pre) Gecko/20071122 Calendar/0.8pre

When you custom task list by adding new columns (like Category) it's not saved. After restart you can see initial view

1)Create sample tasks
2)Add i.e. Category column to task list
3)restart Sb/Tb

Actual result:
You can't see 'category' column

Expected result:
The custom view is saved and visible after restart
Omar, are you referring to the unifinder todo (the task list shown in the today pane), the unifinder (the event/task list shown above the calendar views) or the new task list shown in the task mode? I tested the column customization feature with all of them and couldn't find anything that didn't work as expected. Could you please give some more details? Or can anybody else confirm this bug?
Confirmed using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.10pre) Gecko/20071123 Calendar/0.8pre

Neither sort order nor column selection of the task list (unifinder-todo)is restored after Sunbird restart -> Regression.
Regression Range:
  WORKS in Sunbird 0.8pre (2007-11-21-05)
  FAILS in Sunbird 0.8pre (2007-11-22-05)

-> Regressed by the checkin for Bug 253396
Blocks: 253396
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Summary: It's impossible to custom task list in mail/tasks mode → Task list doesn't persist sort order or column selection anymore
Version: unspecified → Mozilla 1.8 Branch
In my opinion a major regression that needs to be fixed for 0.8. It currently prevents me from using Sunbird 0.8pre for daily work.
Flags: wanted-calendar0.8?
Attached patch patch v1Splinter Review
The problem is that the new 'calendar-task-tree' binding needs to take care that several attributes (e.g. ordinal, width, sorting direction, etc.) on the tree columns are made persistent between sessions. Since the tree content now lives inside a binding we can't just employ the document.persist() mechanism in itself.

Originally I just created identifiers from the bound tag and the anonid's of the columns in order to use document.persist(). Interestingly enough, this works under Windows XP & Lightning like a charm. But under Sunbird this just doesn't work as expected, as well as under Mac with Lightning & Sunbird. The attributes are getting always stored in the localstore.rdf but it seems that sometimes the binding gets constructed after the localstore-stuff has been reapplied.

Unfortunately I can't use xbl:inherits with attribute forwarding since the attributes on the columns are constructed 'by value' (e.g. xbl:inherits="hidden=foo" - as this is a 1:many relationship). This can't work by definition and is the reason I didn't take this route in the first place.

After some discussion with the guys on the xul channel this patch now contains what we were coming up with. The tag the element gets bound to now receives the attributes explicitly and makes them persistent under it's (unique) identifier. I tested this approach extensively with Lightning & Sunbird and it seems to get the job done.
Assignee: nobody → michael.buettner
Status: NEW → ASSIGNED
Attachment #290538 - Flags: review?(Berend.Cornelius)
Attachment #290538 - Flags: review?(Berend.Cornelius) → review+
I reviewed and tested your patch and found that everything works excellent and also the source-code looks great!
There was one thing that made me think:
In the 'UnLoad' method you set up the arrays "widths" and "ordinal" by getting the according attributes of each treecolumnn and appending this to a string that is assigned to a self-created attribute where this persistent data is stored. When this attribute is transformed into an array with 
>        var ordinals = this.getAttribute("ordinals").split(' ');
>        var widths = this.getAttribute("widths").split(' ');
it should be guaranteed that for each treecolumn a "width" or "ordinal" attribute is available and the indices of the respective treecolumn in its container and the 'width' (or 'ordinal') attribute in its array are guaranteed to be synchronous.
The following lines

>         if (ordinals && ordinals.length > 0) {...
and 

>         if (widths && widths.length > 0) {..

could potentially (and probably theoretically) destroy this order. Therefor I wonder if you should not just skip these lines or assign the width and ordinals like
...
   treecols[i].ordinal = Number(ordinals[i]);
..
   treecols[i].width = Number(widths[i]);
(In reply to comment #7)
> it should be guaranteed that for each treecolumn a "width" or "ordinal"
> attribute is available and the indices of the respective treecolumn in its
> container and the 'width' (or 'ordinal') attribute in its array are guaranteed
> to be synchronous.
Since the outside world (with respect to the binding) is not allowed to change the internals this can be guaranteed. This even works if we later decide to add or remove columns.

> The following lines
> could potentially (and probably theoretically) destroy this order. Therefor I
> wonder if you should not just skip these lines...
Hm, this code is responsible for streaming the saved attributes back to the life objects. What if we never saved before, i.e. delete your localstore.rdf? In this case the if-statements make sure that we don't access an undefined variable and throw an exception. I'm leaving this as is for now...

Thanks for the review, Berend.
patch checked in on trunk and MOZILLA_1_8_BRANCH

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: wanted-calendar0.8?
Target Milestone: --- → 0.8
Version: Mozilla 1.8 Branch → unspecified
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11pre) Gecko/20071208 Calendar/0.8pre and Lt 2007120803
Status: RESOLVED → VERIFIED
Problem still exists on Trunk using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007121214 Calendar/0.6a1.
You need to log in before you can comment on or make changes to this bug.