518112 - "New Event/Task" buttons and menu entries don't change the disable/enable status when calendars change mode

Status: RESOLVED FIXED

(Calendar :: Lightning Only, defect)

Description

[Decathlon]

When calendars become read-only, switched off or event-only (don't support tasks), menu entries and buttons related to New Event and New Task commands should become immediately enabled or disabled according to the situation of all calendars, but actually this happens only if the user click on some elements (I suppose these elements take the focus) otherwise the items don't change status and are unresponsive (when they shouldn't).


Reproducible:
Always


Steps to Reproduce:
1. look at the status of the following items:
   - menu entry File->New->Event.../Task...
   - menu entry New Event.../Task... on context menu in calendar views
   - toolbar buttons Write->Event/Task
   - button New Event on todaypane
   - button New Task on task view
2. set every calendar in read only mode or switch them off in order to get no
   writable calendars;
3. click on one of these elements (maybe also others):
   todo panel of todaypane, agenda of todaypane, calendar view, a calendar in
   the list, a Thunderbird's tab (to change mode to mail, calendar or task);
4. set one calendar in writable mode or switch it on.
5. click on an element listed in step 3.

Actual Results:  
After step 2, the entries/buttons mentioned above don't change status and remain in enabled status but are unresponsive like they should be (because all calendars are read-only).
After step 3, buttons and menu entries change status and become disabled.
After step 4, the entries/buttons don't change status and remain disabled and unresponsive but they shouldn't (because one calendar is writable).
After step 5 the entries/buttons become enabled like they should be.


To change the status the user must click on an element listed in step 3, but other elements don't make change status to the buttons/entries e.g. minimonth, miniday in todaypane, navigation buttons in calendar view, todaypane button,...


Expected Results:  
The entries should become disabled or enabled immediately after all calendars have gone in read only mode or switched off.

Comment 1

[Stefan Sitter [:ssitter]]

Most probably a Lightning-only issue because I cannot reproduce the issue using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4pre) Gecko/20090930 Calendar/1.0pre.

Comment 2

[Decathlon]

I've just tried with 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090930 Calendar/1.0pre
and I can reproduce the issue on a new and old profile.
Actually on a new profile I don't get the issue the first time I set the calendar in read only mode, but I get it when I re-set the calendar in writable mode and then every time I change calendar mode. 
The same with Lightning.

Comment 4

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

Attachment: Fix - v1

This patch takes care. I admit the calendar list might not be the best place to check for this, but the other observers make even less sense and I don't think we should create a whole new file just for this purpose.

Comment 5

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

I think this is a minor issue and should not block 1.0. It has a patch now though :-)

Comment 6

[Decathlon]

Comment on attachment 463933 [details] [diff] [review]
Fix - v1

The patch works fine except that the following case.

Str:
1. Create two calendars, a local one and a calendar that doesn't support tasks (e.g. a Google calendar) both activated and not in read only mode;
2. switch to task mode so you can see the "New task" button;
3. delete the local calendar in order to have only the calendar that doesn't support task (hence a "New task" button that should be disabled);

-->  the input field where you can insert a new event becomes immediately disabled, with the sentence "Please Select a Calendar that Supports Tasks", instead the button "New task" is still enabled but it doesn't work. If you click elsewhere (e.g. the tasks list or the today pane) the button becomes correctly disabled (the same occurs to the "New task" menu entry and to the button on the main toolbar).

r- unless the issue mentioned above becomes another bug.

Comment 7

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

Attachment: Fix - v2

This patch should take care of the issue described.

Comment 8

[Decathlon]

Philipp, the patch Fix - v2 doesn't seem working as expected, I get the same exact behavior of the previous patch described in comment #6.
It worked the first time I tested it because of the first reload of the remote calendar just after I deleted the last but one calendar, but without forcing the calendar reload, the "New Task" button and menu entry don't change the status.

Moreover I have to add that the issue described in comment #6 happens not only with remote calendars that don't support tasks, but with local calendars in read only mode too, i.e. the status of the buttons/entries don't change if, with two calendars, you delete that one not in read only mode and keep that one in read only mode.

I've also noticed that the entry "Delete calendar" in the contextual menu of calendars list, has the same behavior of the commands "New Event/Task", but this should be bug 551908 (probably is the same issue).

Comment 9

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

Attachment: Fix - v3

Seems there needs to be a setTimeout when doing it in onDefaultCalendarChanged. I've chosen to rather use onCalendarDeleting, which doesn't require using setTimeout. I hope this time it goes better :-)

Comment 10

[Decathlon]

Comment on attachment 468486 [details] [diff] [review]
Fix - v3

This works fine for me.
Philipp, take also a look to bug 551908 because this patch fixes that bug too.

Comment 11

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

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

Comment 13

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

Backported to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/8b47e5525023>

a=philipp