413326 - Read only calendar, use 'Click Here to Add a New Task' text field -> nothing happens

Status: VERIFIED FIXED

(Calendar :: Lightning Only, defect)

Description

[Andreas Treumann]

STEPS TO REPRODUCE:
===================

- set your home calendar read only
- switch to Task Mode
- use the 'Click Here to Add a New Task' text field to create a new task 

RESULT:
=======

- nothing happens

EXPECTED RESULT:
================

- the user should get the information that a task creation isn't possible because the calendar is read only.

REPRODUCIBLE:
=============

- always

Comment 1

[Przemyslaw Bialik]

> - the user should get the information that a task creation isn't possible
> because the calendar is read only.
or even be more friendly and allow him to choose non read-only calendar (if user used "Today Pane" to do this he can't quickly change default calendar)

error console:
Error: '<error>' when calling method: [calICalendar::adoptItem] = <unknown>
Source file: file:///extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calCachedCalendar.js
Line: 381

Comment 2

[Pete Griffin]

I have the same failure (XP, TB 2.0.0.12, LT 0.8) if the currently selected calendar is a google calendar (I don't believe google calendar supports tasks). Possibly the same issue? Or should I file a separate bug? The silent failure could lead to data loss for anyone adding tasks if they weren't checking as they were adding them, or frustration if they don't realise what's going on...

Comment 3

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

Same issue, no new bug needed. If the click here... field values the tasks capabilities, then everything will be fine for Google Calendar.

Comment 4

[Gerald]

Same issue here. Since I have installed the extension ThunderbirthDay, the automatically added calendar "Birthdays from Thunderbird" was selected as default calendar. Since this calendar is readonly, I had the same problem as described here. After just switching to Calendar "private" the problem was solved. However, I needed to search Bugzilla to find that solution....

Comment 5

[klint]

(In reply to comment #2)
> I have the same failure (XP, TB 2.0.0.12, LT 0.8) if the currently selected
> calendar is a google calendar (I don't believe google calendar supports tasks).
> Possibly the same issue? Or should I file a separate bug? The silent failure
> could lead to data loss for anyone adding tasks if they weren't checking as
> they were adding them, or frustration if they don't realise what's going on...
> 
 
Such a bug had already been filed (bug 423871).

Should they be considered as duplicates (maybe by updating the title of this one as "Read-only or non task-enabled calendar, use 'Click Here...' ...") or not?

Comment 6

[Andreas Treumann]

A different scenario after checkin of bug 434092:

- open the properties dialog of a calendar in the calendar list
- deselect 'Switch this calendar on'
- select this calendar in the calendar list
- use the 'Click Here to Add a New Task' text field to create a new task

Result:

- a new task is visible in the task list
- double mouse clicking this task -> readonly dialog comes up
- restart thunderbird -> task is gone 

Comment 7

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

Attachment: Handle Readonly/Disabled case - v1

If the currently selected calendar is not writable, then a message is displayed in all task quickadd textboxes, which are also marked as readonly (to still allow tabbing to the textbox) and marked as disabled for screen readers.

Comment 8

[Daniel Boelzle [:dbo]]

Comment on attachment 323382 [details] [diff] [review]
Handle Readonly/Disabled case - v1

ui=dbo, I like that behaviour.

However, the patch has some oddities:
uncheck (visibility) a calendar in task mode:
- selection of the title still stays "Select a writable calendar"
- mark the invisible one read-only, title selection doesn't switch to diabled
I think this results due to observing composite only.

Comment 9

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

Attachment: Handle Readonly/Disabled case - v2

Thanks for catching that! I also added task capability support in this patch version.

Comment 10

[Berend Cornelius]

patch looks good and works fine, especially as you already had in my to provide accessibility for the edit control.

you could probably consolidate the following sections:
>+        var calendar = getSelectedCalendar();
>+
>+        if (calendar.getProperty("capabilities.tasks.supported") === false) {
>+            taskEdit.setupTaskField(edit, true, calGetString("calendar", >"taskEditInstructionsCapability"));
>+        } else if (!isCalendarWritable(calendar)) {
>+            taskEdit.setupTaskField(edit, true, calGetString("calendar", >"taskEditInstructionsReadonly"));
>+        } else {
>+            taskEdit.setupTaskField(edit, false, edit.savedValue || "");
>         }

and

>        var calendar = getSelectedCalendar();
>+
>+        if (calendar.getProperty("capabilities.tasks.supported") === false) {
>+            taskEdit.setupTaskField(edit, true, calGetString("calendar", >"taskEditInstructionsCapability"));
>+        } else if (!isCalendarWritable(getSelectedCalendar())) {
>+            taskEdit.setupTaskField(edit, true, calGetString("calendar", >"taskEditInstructionsReadonly"));
>+        } else {
>+            edit.savedValue = edit.value;
>+            taskEdit.setupTaskField(edit, false, calGetString("calendar", >"taskEditInstructions"));
>+        }

However I am not insisting, since both sections vary in detail...

Comment 11

[Berend Cornelius]

Comment on attachment 323543 [details] [diff] [review]
Handle Readonly/Disabled case - v2

r=berend.

Comment 12

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

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 13

[Andreas Treumann]

I checked this issue and it does not work as expected.

STR:

- select a readonly calendar
- text in the 'add new task' control changed to 'Please Select a Writable Calendar'
- select a writable calendar -> text changed to 'Click Here to Add a New Task'
- after selecting the control box with the mouse the text changed back to 'Please Select a Writable Calendar' -> But a writable calendar is selected (Step 3)!   

Comment 14

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

Attachment: Additional fix - v1

This bug was quite aggravating. There are some timing issues that cause the selected calendar to be changed before onBlur is processed.

This fixes.

Comment 15

[Berend Cornelius]

In "OnBlur" you set 
>+        edit.showsInstructions = true;
and on the following lines you set

>+            if (!edit.showsInstructions) {
>+                edit.savedValue = edit.value || "";
>+            }

This way you will always have a savedValue of "" as far as I see.

Comment 16

[Berend Cornelius]

Comment on attachment 324456 [details] [diff] [review]
Additional fix - v1

r=- based on my previous comment.

Comment 17

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

Attachment: Additional fix - v2

Sorry, must have lacked coffee when uploading v1 ;-) I also tested entering text into the box, changing focus (instruction shows), then changing back (old text shows). I hope everything works as expected now.

Comment 18

[Berend Cornelius]

Comment on attachment 324589 [details] [diff] [review]
Additional fix - v2

r=berend

Comment 19

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

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 20

[Andreas Treumann]

Checked in lightning build 2008061203 -> VERIFIED.