Closed Bug 1195974 Opened 9 years ago Closed 9 years ago

Lightning 4.0.2 switches caldav calendards off and read-only when offline

Categories

(Calendar :: Provider: CalDAV, defect)

Product:
Calendar
Component:
Provider: CalDAV
Version:
Lightning 4.0.2
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
4.0.2.1

People

(Reporter: Lukas.Ruf, Assigned: Fallen)

References

Details

(Keywords: regression) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150812163655

Steps to reproduce:

I have two local and a series (8) CalDAV-based calendards.  Until recently, the CalDAV calendars worked perfectly with and without offline support as expected.

Since the updating to 4.0.2, all CalDAV calendars are switched off and set to Read Only when there is no connection to the server.


Actual results:

All CalDAV calendars are switched off and set to Read Only when there is no network connection to the server


Expected results:

The settings of CalDAV calendars should not be changed, i.e. not switched off and not set to Read Only, when there is no connection to the server.
Severity: normal → major
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
I can confirm the bug. An user on our support forum is having the same problem with a calendar subscribed with caldav and hosted on his private NAS. When he disconnects from the NAS, the calendar disappears and it's reloaded as read only. I've forwarded him the link to this bug, he will contribute with more info (or I'll do it for him if he can't speak English)
Status: UNCONFIRMED → NEW
Ever confirmed: true
As Iacopo has written, I've the same problem with lightning and caldav calendar on my private NAS.
The problem doesn't happen with portable TB (3.1.7) + ligthning 3.3.3 (installed as plugin and not integrated on TB as on the new version of TB).
below you will find the report of error console when trying to activate the calendar when i'm offline from the nas (sensible info are deleted! - report is in italian....i'm sorry):

Data e ora: 16/08/2015 20:43:47
Errore: [calCachedCalendar] replay action failed: null, uri=http://10.8.0.1/owncloud/remote.php/caldav/calendars/admin/condiviso, result=2147500037, op=[xpconnect wrapped calIOperation]
File sorgente: file:///C:/Users/XXX/AppData/Roaming/Thunderbird/Profiles/8dcox2e4.XXXX/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCachedCalendar.js
Riga: 322

Data e ora: 16/08/2015 20:43:47
Avviso: Si è verificato un errore durante la lettura dei dati dal calendario: condiviso. Codice di errore: READ_FAILED. Descrizione:
File sorgente: file:///C:/Users/XXX/AppData/Roaming/Thunderbird/Profiles/8dcox2e4.XXXX/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Riga: 960

Data e ora: 16/08/2015 20:43:47
Avviso: Si è verificato un errore durante la lettura dei dati dal calendario: condiviso. Codice di errore: DAV_NOT_DAV. Descrizione: La risorsa a http://10.8.0.1/owncloud/remote.php/caldav/calendars/admin/condiviso non è una collezione DAV oppure non è disponibile
File sorgente: file:///C:/Users/XXX/AppData/Roaming/Thunderbird/Profiles/8dcox2e4.XXXX/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Riga: 960
Component: Lightning Only → Provider: CalDAV
Confirmed on Arch Linux using Thunderbird 38.2.0 and Lightning 4.0.2 and with Server Software CalDav as well as SOGo.
It's pretty annoying...
Confirmed on DAViCal 1.1.3.1 running on Debian 8 Jessie (server side) + Thunderbird 38.2.0/Lightning 4.0.2 running on MS Windows 7 SP1 (client side)
Thanks, but currently no further confirmations are required for this bug. This appears for whatever caldav setup you're running.

This seems to be a regression of bug 1186547.
Keywords: regression
As far as I know in the past there was a real read-only state that was set by the user in the calendars properties dialog. 

And there was the concept of a calendar being temporarily read-only e.g. because calendar was not available. When calendar went back online or Thunderbird was restarted the temporarily read-only flag was reset. When using cache the underlying CalDAV calendars were internally read-only but the cache calendar on top was editable.

Maybe this feature was working as intended but Bug 1186547 incorrectly assumed it to be an error? Back-out Bug 1186547 and restore previous behavior?
I really need to take care of this one soon. I'm not sure a backout is the right thing to do because iirc then mReadOnly was set but not really used. It looks like I made a wrong assumption when writing the patch for bug 1186547, I just have to fix it.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Flags: needinfo?(philipp)
A workaround for all who want to work with CalDAV calendars until this gets fixed:

1. under Add-Ons, select Lightning -> more, and there set automatic updates radio buttons to off.
2. back to Add-Ons, switch to "Search for Add-Ons", search/select Lightning, click on "learn more"
3. In the "About this Add-on" box search for and click on "complete version history"
4. locate version 4.0.1.2, and then move cursor right of it: a green "+ Add to Thunderbird" appears, click it
5. switch back to the current Add-Ons panel and be patient: there is no visual feedback, that the last step succeeded, but it did, believe me, as I was impatient and clicked multiple times, only to find multiple simultaneous downloads in the temp folder
6. confirm the confirmation dialog and wait till the installation finishes, then restart Thunderbird
7. reactivate all your CalDAV calendars and remove the Read-Only check mark

Btw, Philipp Kewisch: you set the needinfo flag: what info are you still asking for?
requesting needinfo from myself to remind me I really need to write the patch :-) This is major enough that I'll likely release 4.0.2.1.
Given there have been more than enough regressions in 4.0.x I now agree the best thing to do is back this out on 4.0.x and fix it for beta.

Backout on esr38: https://hg.mozilla.org/releases/comm-esr38/rev/839f27cac475

Keeping this bug open for the patch for beta I am working on.
Also backed out of beta so we can build:

https://hg.mozilla.org/releases/comm-beta/rev/561d02f77bb0
Flags: needinfo?(philipp)
Could someone test if the behavior with Thunderbird 38 is now as expected using the latest automatic Lightning test build? You find them in the comm-esr38-<platform> sub-folder on <https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/tinderbox-builds/>.
Seems to be working in my case (Linux Mint/TB 38.2)...
now I need to wait for it to find its way into the repo so I can have my german back, but I'll survive ;)

Thx!
Works in my case (Win7 Pro EN, TB 38.2.0, latest test build) as expected.

Test cases:
- set offline while TB/Lightning were running
- while offline, restart TB/L
- while offline, after restart, added new entry to CalDav-Calendar (davical)
- set to online
- pressed 'synchronize' manually

Results:
- As expected
- Offline added entry was sync'd with Caldav-Server, entry appeared on a different device (Android)

Thanks a lot!
Ubuntu 14.04 64bit
TB: 38.2.0
Lightning Latest tinderbox-builds

Now it works perfect!

Thanks!
Tested successfully on Win7 Pro EN, Mac OS 10.10, Ubuntu 14.04 with TB 38.2 and latest tinderbox-builds.

Thanks!
it seems to work on win7 x64 + TB 38.2.0 
great work!!! :-)
Philipp, back-out for comm-central and comm-aurora is still missing. Once that is done and functionality is restored we should re-open or terminate Bug 1186547.
Blocks: 1186547
Flags: needinfo?(philipp)
Ok, lets take it out until I come up with a completely new patch. I've filed bug 1201862 to take care.

https://hg.mozilla.org/comm-central/rev/82baea639081
https://hg.mozilla.org/releases/comm-aurora/rev/45663d9662d2
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(philipp)
Resolution: --- → FIXED
Target Milestone: --- → 4.0.3
Any info on when this fix will become available to the public via official updates?

regards
I'm wondering this too

(In reply to schorsch from comment #33)
> Any info on when this fix will become available to the public via official
> updates?
> 
> regards
Hope to do the release some time tomorrow. In the meanwhile, can you test these builds? https://mozilla.kewis.ch/releases/ltn4021/

(if you get a secure connection failure, try reloading. Looks like there are OCSP timeouts atm)
I can't say if the build you sent helped with this issue, but after installing it I lost my setting of the "first day of the week" (before update was Monday, after update Sunday). I'm not sure if this is normal when installing from other sources.
This pref should not be changed during an update, but it doesn't sound related. Can you try to reproduce by 1) dowgrade to whatever you had installed before 2) set pref to monday 3) update again. Do you get any error console messages, either now or during the reproduce process?
Ok, it was probably false alarm, since downgrading to 4.0.2 and upgrading back didn't change the pref.

And I see on error in the console after plainly starting TB (but it is both with 4.0.2 and 4.0.2.1):
Error: TypeError: this.tree.view is undefined
Source file: chrome://calendar/content/calendar-unifinder.js
Line: 624
Ok, same here (on win32). It works, the error console shows some errors due to CalDAV resource not available, but calendar is shown and writable. And, mysteriously, week start is reset to Sunday (was: Monday) when updating from 4.0.1.2 for me too, and I see this error on Lightning startup as well:

Error: TypeError: this.tree.view is undefined
Source file: chrome://calendar/content/calendar-unifinder.js
Line: 624

Not sure if this is related, there are some info messages in the beginning like:
firstrun 3
firstrun 4
before register
register uninstall start
register uninstall start 1
register uninstall start 2
register uninstall new 2
after register
firstrun 2
firstrun 2d

without source, it seems there is some "firstrun" initialization there, could this account for resetting of week start?
Those firstrun messages do not come from Lightning. Could it be the EWS Provider causing those messages?
(In reply to Martin Pecka from comment #36)

If you did not changed this setting in preference dialog you should get the default value that is actually localization specific. Maybe you were using e.g. Lightning with German localization that defines Monday as first day of week. And the test build uses English localization that defines Sunday as first day of week. Or maybe this mechanism is broken.
on Linux i686 upgrading 4.0.1.2 to 4.2.0.1 did NOT change week start, it stayed on Monday for my German localization. But maybe I fiddled with it in the past, so this setting probably was not default any more, so it did not change. In response to the test build using English localization, both (win32 and Linux i686) are completely localized (all German strings), and looking into the xpi I see the chrome folder has all localizations, so it really is multi-language (as a release candidate is expected to).
Still fighting with this in our office... would be REALLY nice to get a formal release to fix it.
I have been running the patch since it got released. I havn't had an issue yet. We are pushing it out manually to our users and so far, all seems good.

(In reply to Philipp Kewisch [:Fallen] from comment #35)
> Hope to do the release some time tomorrow. In the meanwhile, can you test
> these builds? https://mozilla.kewis.ch/releases/ltn4021/
> 
> (if you get a secure connection failure, try reloading. Looks like there are
> OCSP timeouts atm)
(In reply to Karl Rossing from comment #46)
> I have been running the patch since it got released. I havn't had an issue
> yet. We are pushing it out manually to our users and so far, all seems good.
> 
> (In reply to Philipp Kewisch [:Fallen] from comment #35)
> > Hope to do the release some time tomorrow. In the meanwhile, can you test
> > these builds? https://mozilla.kewis.ch/releases/ltn4021/
> > 
> > (if you get a secure connection failure, try reloading. Looks like there are
> > OCSP timeouts atm)

We do the same at our place: no issues so far.

Thanks!
Lightning 4.0.2.1 is about to be released. That contains another fix, so please use that instead of the preview build.
So... where do we get it?
The problem persists on 4.7.4.
Nevermind, this is the issue I'm having: https://bugzilla.mozilla.org/show_bug.cgi?id=992340
You need to log in before you can comment on or make changes to this bug.