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

RESOLVED FIXED in 1.0b3

Status

defect
--
minor
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: bv1578, Assigned: Fallen)

Tracking

Trunk
1.0b3
Bug Flags:
blocking-calendar1.0 -

Details

Attachments

(1 attachment, 2 obsolete attachments)

Reporter

Description

10 years ago
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.
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.
Severity: normal → minor
Component: General → Lightning Only
QA Contact: general → lightning
Reporter

Comment 2

10 years ago
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.
Flags: blocking-calendar1.0?
Duplicate of this bug: 498157
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Posted patch Fix - v1 (obsolete) โ€” โ€” Splinter Review
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.
Attachment #463933 - Flags: review?(bv1578)
I think this is a minor issue and should not block 1.0. It has a patch now though :-)
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Flags: blocking-calendar1.0? → blocking-calendar1.0-
Reporter

Comment 6

9 years ago
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.
Attachment #463933 - Flags: review?(bv1578) → review-
Posted patch Fix - v2 (obsolete) โ€” โ€” Splinter Review
This patch should take care of the issue described.
Attachment #466095 - Flags: review?(bv1578)
Attachment #463933 - Attachment is obsolete: true
Reporter

Comment 8

9 years ago
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).
Posted patch Fix - v3 โ€” โ€” Splinter Review
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 :-)
Attachment #468486 - Flags: review?(bv1578)
Attachment #466095 - Attachment is obsolete: true
Attachment #466095 - Flags: review?(bv1578)
Reporter

Comment 10

9 years ago
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.
Attachment #468486 - Flags: review?(bv1578) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/b0c0a81d13cb>
-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b3
Duplicate of this bug: 551908
You need to log in before you can comment on or make changes to this bug.