459908 - Error "gCalendarStatusFeedback is not defined" when some dialogs

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Stefan Sitter [:ssitter]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081014 Calendar/1.0pre (BuildID: 20081014045208)

Lightning 1.0pre (20081014030985) + Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081014 Shredder/3.0b1pre (BuildID: 20081014031016).

Steps to Reproduce:
===================
1. Create new event and open the Invite Attendees dialog
2. Close the Invite Attendees dialog using [Ok] or [Cancel]

Actual Results:
===============
Error: gCalendarStatusFeedback is not defined
Source File: chrome://calendar/content/calUtils.js
Line: 1874

Expected Results:
=================
No error

Comment 1

[Stefan Sitter [:ssitter]]

Regression range: Works in Sunbird 1.0pre (20081013031044)
                  Fails in Sunbird 1.0pre (20081014045208)

Checkins during regression range:
http://hg.mozilla.org/comm-central/pushloghtml?startdate=2008-10-13+03:00:00&enddate=2008-10-14+05:00:00

Comment 2

[Berend Cornelius]

Certainly a regression from Bug 456102 - Minimonth should generally be able to show free-busy states. Taking over...

Comment 3

[Berend Cornelius]

Attachment: patch v. #1

Comment 4

[Berend Cornelius]

patch pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/0e08c97df3af

->fixed

Comment 5

[Stefan Sitter [:ssitter]]

The Go To Date dialog and the Custom Reminder dialog show the same error.

(I hope it's OK to reopen this bug instead of filling a new one.)

Comment 6

[Stefan Sitter [:ssitter]]

Add the Print Preview dialog to that list.

Comment 7

[Stefan Sitter [:ssitter]]

The Choose Timezone dialog reports the error too.

Maybe calUtils.js is not the right place for getCompositeCalendar()? Or maybe the check for gCalendarStatusFeedback should be improved? Could something similar to |if ("gCalendarStatusFeedback" in window)| work?

Comment 8

[Daniel Boelzle [:dbo]]

Attachment: fix2

@Stefan: Your code assumes we always have a |window| object which we may not have. I think our only safe haven is catching away such an error here.

Comment 9

[Berend Cornelius]

Comment on attachment 344048 [details] [diff] [review]
fix2

patch solves the problem and saves us quite some trouble. But I don't know if this is really an "exception" by definition that we handle here. So you should probably add a comment here why we wrap the exception handling around.
r=berend;

Comment 10

[Daniel Boelzle [:dbo]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/296018803281>

-> FIXED

Comment 11

[Andreas Treumann]

Checked in lightning build 2008102203557 ans sunbird 20081022 -> VERIFIED