450933 - [Today Pane] Doesn't remember between restarts if "Tasks", "Events" or "Events and Tasks" is selected

Status: RESOLVED FIXED

(Calendar :: Lightning Only, defect)

Description

[Ingo Müller]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8.1.12) Gecko/20080227 Lightning/0.8 Thunderbird/2.0.0.12

Every couple of days, I have to change the today pane in calendar mode from "Tasks" to "Events and Tasks".

When I start up TB and the mail view shows up, "Events and Tasks" is selected as I want it. But when I change to calendar view, "Tasks" is selected. I can restart a couple of times before the selection is reset (maybe it's every other time, not sure...).

Reproducible: Sometimes

Steps to Reproduce:
1. Set the today pane to show "Events and Tasks" in calendar mode.
2. Restart Thunderbird and go to calendar mode.
3. Restart Thunderbird a couple of times again (one more time?).
4. Go to calendar mode again.
Actual Results:  
At (2) the today pane remembered "Events and Tasks" correctly.
At (4) the today pane is reset to show "Tasks" only.

Expected Results:  
The today pane should remember "Events and Tasks" until changed by the user.

Comment 1

[Ingo Müller]

Still not working, even worse now: At (2) the today pane is already reset to "Tasks" now. Is this intentional? IMO this is very counter-intuitive!

Comment 2

[d2_c2]

Same behaviour for me.  It appears to be random, but it reverts to tasks only more often than not.  Not a critical bug, but awfully annoying.

Comment 3

[Bruce Rusk]

Win XP SP3, latest nightlies, it usually reverts to Tasks for me.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081204 Lightning/1.0pre Thunderbird/3.0b1

Comment 5

[Decathlon]

Attachment: workaround for the issue

I've tried to look into this issue, and it seems that the attribute 'collapsedinmodes' in agenda-panel binding can't persist if it becomes a zero-length string (""). It persists only (but it seems not always) if store is forced by document.persist() inside setVisible method in calendar-widget.xml file http://mxr.mozilla.org/comm-central/source/calendar/base/content/widgets/calendar-widgets.xml#202.

According to steps to reproduce, this happens first time Lightning runs when you set agenda+task pane, so, next start, localstore.rdf has the right value "" for 'collapsedinmodes' but then, if you close Lightning without changing today pane, no document.persist() is used and the value isn't stored (in localstore.rdf there isn't 'collapseinmodes' attribute). Next time Lightning runs, the attribute gets the default value "calendar" and agenda-panel collapses.

I've tried to force the store of the attribute with the document.persist(...) method but there are always others combinations or sequences enable/disable of agenda/todo panels that don't work when Lightning restarts. I've probably missed something or there is something about 'persist' method that I don't know (maybe could bug 15232 about persist method be related?) but I'm not able to make it work in every case.

At last I tried the attached workaround: change the value "" to "," (a string that works fine with join(",") method without further code, but every other string different from "" would work). In this way 'persist' seems working fine for the attribute 'collapsedindmodes' in every situation and there isn't need to force the attribute with document.persist().
I also add three lines to avoid 'collapsedinmodes' attribute to assume values like ",calendar" or ",,calendar" (first one happens normally without the workaround, the second one happens with workaround) although workaround works without them.

Obviously, if it needs a real patch, discard the attachment ;-)

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 364874 [details] [diff] [review]
workaround for the issue

I'd like berend to take care of this review since he is our expert for mode persistance. I'll keep an eye on this one though.

Comment 7

[Berend Cornelius]

Comment on attachment 364874 [details] [diff] [review]
workaround for the issue

patch looks good and works fine. It is of course not an ideal solution to set the collapsedinModes attribute to something like "," but that's currently the way it works. I bet It was not quite so easy to get into this stuff. Maybe you or somebody else can change the implementation one day in such a way that the modeboxes are also capable to handle other attributes than "collapsed" mode-dependently.

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/de127dbd5477>

-> FIXED