The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in 4.0.2.1

Status

Calendar
Provider: CalDAV
--
major
RESOLVED FIXED
2 years ago
4 months ago

People

(Reporter: Lukas Ruf, Assigned: Fallen)

Tracking

({regression})

Lightning 4.0.2
4.0.2.1
x86_64
Windows 7
regression
Dependency tree / graph

Details

(Reporter)

Description

2 years ago
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.
(Reporter)

Updated

2 years ago
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

Comment 2

2 years ago
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
(Assignee)

Updated

2 years ago
Blocks: 1194997

Updated

2 years ago
Duplicate of this bug: 1196389

Updated

2 years ago
Duplicate of this bug: 1195800

Updated

2 years ago
Component: Lightning Only → Provider: CalDAV

Updated

2 years ago
Duplicate of this bug: 1197081

Comment 6

2 years ago
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...

Comment 7

2 years ago
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)

Comment 8

2 years ago
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

Updated

2 years ago
Duplicate of this bug: 1197710

Updated

2 years ago
Duplicate of this bug: 1197727

Comment 11

2 years ago
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?
(Assignee)

Comment 12

2 years ago
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)

Updated

2 years ago
Duplicate of this bug: 1198635

Comment 14

2 years ago
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?
(Assignee)

Comment 15

2 years ago
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.
(Assignee)

Comment 16

2 years ago
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.
(Assignee)

Comment 17

2 years ago
Also backed out of beta so we can build:

https://hg.mozilla.org/releases/comm-beta/rev/561d02f77bb0
Flags: needinfo?(philipp)

Updated

2 years ago
Duplicate of this bug: 1199321

Comment 19

2 years ago
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/>.

Comment 20

2 years ago
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!
(Reporter)

Comment 21

2 years ago
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!

Comment 22

2 years ago
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!

Updated

2 years ago
Duplicate of this bug: 1200713

Comment 25

2 years ago
it seems to work on win7 x64 + TB 38.2.0 
great work!!! :-)

Comment 26

2 years ago
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)

Updated

2 years ago
Duplicate of this bug: 1201818
(Assignee)

Comment 28

2 years ago
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
Last Resolved: 2 years ago
Flags: needinfo?(philipp)
Resolution: --- → FIXED
Target Milestone: --- → 4.0.3

Updated

2 years ago
Duplicate of this bug: 1202129

Updated

2 years ago
Duplicate of this bug: 1202135

Updated

2 years ago
Duplicate of this bug: 1202185

Updated

2 years ago
Duplicate of this bug: 1202345

Comment 33

2 years ago
Any info on when this fix will become available to the public via official updates?

regards

Comment 34

2 years ago
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
(Assignee)

Comment 35

2 years ago
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)

Comment 36

2 years ago
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.
(Assignee)

Comment 37

2 years ago
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?

Comment 38

2 years ago
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

Comment 39

2 years ago
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?
(Assignee)

Comment 40

2 years ago
Those firstrun messages do not come from Lightning. Could it be the EWS Provider causing those messages?

Comment 41

2 years ago
(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.

Comment 42

2 years ago
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).

Updated

2 years ago
Duplicate of this bug: 1203933
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1204444

Comment 45

2 years ago
Still fighting with this in our office... would be REALLY nice to get a formal release to fix it.

Comment 46

2 years ago
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)
(Reporter)

Comment 47

2 years ago
(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!

Comment 48

2 years ago
Lightning 4.0.2.1 is about to be released. That contains another fix, so please use that instead of the preview build.

Comment 49

2 years ago
So... where do we get it?

Updated

2 years ago
Duplicate of this bug: 1206489

Updated

2 years ago
Duplicate of this bug: 1212410

Comment 52

4 months ago
The problem persists on 4.7.4.

Comment 53

4 months ago
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.