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)
Calendar
Calendar Frontend
Tracking
(Not tracked)
VERIFIED
FIXED
0.8
People
(Reporter: omar.bajraszewski, Assigned: michael.buettner)
References
Details
(Keywords: regression)
Attachments
(1 file)
14.08 KB,
patch
|
berend.cornelius09
:
review+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•17 years ago
|
||
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?
Comment 2•17 years ago
|
||
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.
Comment 3•17 years ago
|
||
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
Comment 4•17 years ago
|
||
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?
Assignee | ||
Comment 5•17 years ago
|
||
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)
Comment 6•17 years ago
|
||
Attachment #290538 -
Flags: review?(Berend.Cornelius) → review+
Comment 7•17 years ago
|
||
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]);
Assignee | ||
Comment 8•17 years ago
|
||
(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.
Assignee | ||
Comment 9•17 years ago
|
||
patch checked in on trunk and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: wanted-calendar0.8?
Target Milestone: --- → 0.8
Version: Mozilla 1.8 Branch → unspecified
Reporter | ||
Comment 10•17 years ago
|
||
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
Comment 11•17 years ago
|
||
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.
Description
•