If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

calendar XPI needs main-window overlay to explicitly start alarm service

RESOLVED WONTFIX

Status

Calendar
Sunbird Only
--
major
RESOLVED WONTFIX
12 years ago
11 years ago

People

(Reporter: dmose, Assigned: Peter Weilbacher)

Tracking

({regression})

Trunk
regression

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
As a result of the changes made in bug 325476, the alarm service is no longer being started in calendar.xpi.  An overlay to the main application window needs to be added that explicitly starts the service.

Comment 1

12 years ago
*** Bug 328767 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 2

12 years ago
Created attachment 216301 [details] [diff] [review]
add alarm init to overlay

This isn't really a killer, a very similar problem exists with MailNews, too, where you have to open that window once to activate mailbox checks.

But I looked at this and this patch works, I tested with SeaMonkey. Unfortunately, it also slows down the startup time by quite a bit because initializing the alarm service obviously means that it checks each event before continuing and that all takes place before any windows are painted, so it's pretty annoying.

Btw, are the files calendar\resources\content\calExtOverlay.* still in use for Firefox? Then the same lines would need to be added there.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
(Assignee)

Comment 3

12 years ago
As Joey remarked in the newsgroup timezone=-1 was not very clever, but it doesn't have any serious results AFAICS.

But there doesn't seem to be an interface that lets me access calendarDefaultTimezone() or at least guessSystemTimezone() to do this correctly or am I blind?

Comment 4

12 years ago
(In reply to comment #3)
> As Joey remarked in the newsgroup timezone=-1 was not very clever, but it
> doesn't have any serious results AFAICS.
It should, if there are any items with alarms actually in the calendar:

js> var cdt = Components.classes["@mozilla.org/calendar/datetime;1"].createInstance(Components.interfaces.calIDateTime);
js> cdt.jsDate = new Date();
Sun Mar 26 2006 12:33:45 GMT-0500 (CDT)
js> cdt.getInTimezone(-1);
uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [calIDateTime.getInTimezone]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: typein :: <TOP_LEVEL> :: line 3"  data: no]


> 
> But there doesn't seem to be an interface that lets me access
> calendarDefaultTimezone() or at least guessSystemTimezone() to do this
> correctly or am I blind?
> 
You need to include chrome://calendar/content/calendarUtils.js, then the function will be available.
(Assignee)

Comment 5

12 years ago
Created attachment 216340 [details] [diff] [review]
With calenderUtils.js included...

Oh yes, including works, too, and is better than cheating. Stupid me! :-)

Let me figure out over the next days if I find a way to not make it block the startup while loading the alarms.
Attachment #216301 - Attachment is obsolete: true
(Assignee)

Comment 6

12 years ago
Created attachment 217617 [details] [diff] [review]
Asynchronous alarm init

Now that the calendar extension is announced to be dead any more work is probably wasted. But as I had already done this new patch I can as well upload it.

I haven't actually timed if synchronous or this new asynchronous alarm init is faster to display the main window, so I leave both active...

Comment 7

11 years ago
calendar.xpi is dead
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.