User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124) Gecko/20071127 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:188.8.131.52pre) Gecko/20080206 Calendar/0.8pre Create a new calendar, network .ics feed. Edit properties and turn cache on. Events displayed fine. Close Sunbird. Disconnect from network. Reopen Sunbird - calendar is empty, nothing seems to have been cached. Reproducible: Always Steps to Reproduce: See details above Actual Results: No events shown. Expected Results: Calendar events shown from cache, even though offline.
Clearly needs investigation.
Setting qawanted - we'd like to get this confirmed as soon as possible. Jonathan also noted that he had seen this on Windows, so we need to confirm that too.
Jonathan, could you please reconfirm the order. Is it really like 1. You configure your calendar and see the events, then you switch caching on. 2. You restart Sunbird. 3. You switch off network. The thing is that the first caching sync occurs on the first restart after caching has been switched on. To let that sync happen you obviously need the network.
Well, I didn't appreciate that caching took place only after the restart, but yes it is reproducible with that sequence of steps. Also I've tried 1. configure, see events, switch caching on 2. restart 3. see events, then close Sunbird 4. switch off network 5. restart - nothing doing.
This issue is reproducible on Linux and Windows, too.
OS: Mac OS X → All
Hardware: Macintosh → All
One further thing to note: if I proceed exactly as in comment #3 - i.e. switch off network while Sunbird is still running - then I do have access to calendar events after the network connection is closed. It's just that I expected the cache to persist through restarting Sunbird too, not just while the app was still open having had network access earlier.
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20080209 Calendar/0.8pre and steps from comment #4
Status: UNCONFIRMED → NEW
Ever confirmed: true
I agree the expected behaviour is Jonathan's remark.
Problem has been that the caching facade has waited for the initial sync to complete until it runs the getItem[s] call on the (local) cached calendar. IMO we could get rid of the inital sync since the calendar is refreshed either way at startup (and further on every 30 minutes).
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Attachment #303041 - Flags: review?(philipp)
Comment on attachment 303041 [details] [diff] [review] fix Works as expected, initial sync seems to happen in any case.
Attachment #303041 - Flags: review?(philipp) → review+
The initial sync unfortunately does not happen for changelog-based providers.
This seems to do it for me. Also makes gdata offline more robust. Tested with gdata and ics on linux.
Attachment #303041 - Flags: review+ → review-
Comment on attachment 303713 [details] [diff] [review] Fix v2 I debugged through the code together with Philipp as I am not so familiar with it -> r=berend.
Attachment #303713 - Flags: review?(Berend.Cornelius) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.8
Checked in lightning 2008030318 and sunbird 20080303 -> task is fixed and verified.
Status: RESOLVED → VERIFIED
Whiteboard: [gdata-cvs] → [gdata-0.4]
You need to log in before you can comment on or make changes to this bug.