Closed Bug 689589 Opened 13 years ago Closed 13 years ago

Lightning doesn't work in Thunderbird 9.0a2 and 10.0a1, startup errors [document.getElementById("calendarDisplayDeck") is null]

Categories

(Calendar :: Lightning Only, defect)

x86
Windows 7
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Assigned: mmecca)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Lightning 1.0b9pre with Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110927 Thunderbird/9.0a1

After installing Lightning 1.0b9pre (20110927) in a fresh Thunderbird 9.0a1 profile I get many startup errors. Lightning doesn't work, e.g. no default Home calendar is available and all views are just blank.

It seems to work fine using Lightning 1.0b8pre with Thunderbird 8.0a2.

From error console:

Error: getPrefSafe is not defined
Source File: chrome://calendar/content/calendar-migration-dialog.js Line: 681

Error: document.getElementById("calendarDisplayDeck") is null
Source File: chrome://lightning/content/messenger-overlay-sidebar.js Line: 192

Error: document.getElementById("calendarDisplayDeck") is null
Source File: chrome://calendar/content/calendar-task-view.js Line: 301

Error: calendar is null
Source File: chrome://calendar/content/calendar-task-editing.js Line: 134
Someone from IRC also confirmed this. He said that the calendarDisplayDeck element is actually there, but still the code is not finding it. I wonder whats going on here.
Regression range:
Works: Thunderbird 9.0a1 (BuildID: 20110926030105)
Fails: Thunderbird 9.0a1 (BuildID: 20110927030110)

Checkins during regression range:
http://hg.mozilla.org/comm-central/pushloghtml?fromchange=a96dbbf9f375&tochange=feb47379243c
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c722928d8b69&tochange=803b01dcc589
Better regression range:
Works: BuildID 20110926223431 Fails: BuildID 20110927030110

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cf6245609f48&tochange=803b01dcc589
@Boris Zbarsky: 
Yesterday you did a big merge from mozilla-inbound to mozilla-central, see link in comment 3. One of the changes most probably regressed this bug here. Lightning waits for the "load" event, tries to access an overlayed XUL deck object by using document.getElementById() fails. Do you have an idea what bug could be responsible?
Yep.  If you're looking for load events then bug 185236 could have affected you.  How are you doing that, exactly?
Right here, we add a load handler on the document, toplevel of the file:

http://mxr.mozilla.org/comm-central/source/calendar/lightning/content/messenger-overlay-sidebar.js#472

which calls ltnOnLoad, defined here:

http://mxr.mozilla.org/comm-central/source/calendar/lightning/content/messenger-overlay-sidebar.js#186

messenger-overlay-sidebar.js is loaded via the respective xul file, the actual include is done in the file included via preprocessor define, see here:

http://mxr.mozilla.org/comm-central/source/calendar/lightning/content/messenger-overlay-sidebar.xul#76

The xul file is overlayed into messenger.xul here:

http://mxr.mozilla.org/comm-central/source/calendar/lightning/jar.mn#6
Severity: normal → critical
Keywords: regression
Summary: Lightning doesn't work in Thunderbird 9, startup errors like [getPrefSafe is not defined] or [document.getElementById("calendarDisplayDeck") is null] → Lightning doesn't work in Thunderbird 9.0a2 and 10.0a1, startup errors [document.getElementById("calendarDisplayDeck") is null]
Just adding a note that I have seen this too :)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a2) Gecko/20110929 Thunderbird/9.0a2
Lightning 1.0b9pre (20110929)

same problem here with new profile. 

Error: (new component).QueryInterface is not a function
Source File: resource://gre/modules/XPCOMUtils.jsm Line: 301

Error: view.goToDay is not a function
Source File: chrome://calendar/content/calendar-views.js Line: 377

Using the old profile linked to Earlybird 8.0a2 I can see the today pane with events showing but nothing in the main pane except the headers, date, day, week,etc.
You probably know this but Lightning 1.0b5 is not working in Thunderbird Daily 10.0a1 either.

I just noticed that my platform is listed as x86 Windows 7. I am actually running Windows 7 x64 if it matters. I must of forgot to say so when I filed the bug. Sorry about that.

My current build is:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110930 Thunderbird/10.0a1 ID:20110930055354

Norm
NRLacasse, Lightning 1.0b5 requires Thunderbird 6. It will not work with other releases and you should not be able to install it. See https://developer.mozilla.org/en/Calendar/Calendar_Versions for getting the correct Lightning version.
Thanks Stefan, I will update Lightning and bookmark the link.
If I understand correctly Bug 185236 causes load events to fire when the style sheets are loaded, which may be before the calendarDisplayDeck element is ready.
Attached patch Fix v1 (obsolete) β€” β€” Splinter Review
Check for calendarDisplayDeck element on load event
Assignee: nobody → matthew.mecca
Status: NEW → ASSIGNED
Attachment #563928 - Flags: review?(philipp)
> Right here, we add a load handler on the document

Uh... no.  Documents don't have load events.  Windows do.  What you're adding there is a load event for "anything in the document that happens to fire a load event".  That used to be just images and scripts, but now includes stylesheets.  So before you were waiting until the first image or script load completed before running ltnOnLoad; I'm not sure why this was a useful thing to wait for....

This is _exactly_ the code pattern that the addons manager also had that I had to hack around in bug 185236.

If you want to actually listen for document load, you need to add the listener to the window object.  If you want to listen for the load of some other element, you need to either add the listener to that element or use what you have now but check the target to make sure it's the right thing.

I have no idea what the code is actually trying to do, so can't tell you which of those two approaches is correct in your case.
(In reply to Boris Zbarsky (:bz) from comment #15)
> I have no idea what the code is actually trying to do, so can't tell you
> which of those two approaches is correct in your case.

I'll defer to Philipp here...
Boris, thanks for the clarification. I was always under the impression that using window.addEventListener is just a shortcut to document.addEventListener defined for compatibility reasons. Good to know there is a difference!

Matthew, can you put up a patch that changes all our document.addEventListener("load", ...)'s to using window? I don't think we have any code that actually needs any load events on the document.
Attached patch Fix v2 β€” β€” Splinter Review
Use window instead of document to listen for load events.
Attachment #563928 - Attachment is obsolete: true
Attachment #563928 - Flags: review?(philipp)
Attachment #563987 - Flags: review?(philipp)
That won't help on its own unless you also switch to bubbling listeners (which should work because now you will get the _window_'s load event) or to checking targets.
no fix in sight?
From my testing, with Fix v2 applied it works as well as it did before.

@Philipp, if it makes sense to you maybe we can take this fix to get comm-central and comm-aurora working again and spin off a followup bug to take a look at how we handle load events and address Boris's comments.
I can confirm that Matthew Mecca's Fix v2 works for me as well:  Windows XP with SeaMonkey nightly branch (Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111004 Firefox/10.0a1 SeaMonkey/2.7a1) and with the Lightning 20111004 nightly build (Lightning1.0b10pre).
Comment on attachment 563987 [details] [diff] [review]
Fix v2

Review of attachment 563987 [details] [diff] [review]:
-----------------------------------------------------------------

Using bubbling listeners is just a matter of setting the third argument of add/removeEventListener to false. I'll test this and then check in.
Attachment #563987 - Flags: review?(philipp) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/007485db1000>
-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Target Milestone: Trunk → ---
Backported to comm-aurora <http://hg.mozilla.org/releases/comm-aurora/rev/0f7b46859486>

Looks like we need a new milestone again
Target Milestone: --- → Trunk
Not Resolved Fixed, on my computer anyway.

I'm using 1.0b10pre

Lightning did not start working correctly on my computer. The Tasks view was partially working and the calendar view never started working. Now after the update 10 minutes ago neither the calendar or tasks are working. It's doing the same thing as before.

Is there a lightning update I need to install?

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111007 Thunderbird/10.0a1 ID:20111007030032
I can confirm the fix with SeaMonkey trunk nightly (Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111007 Firefox/10.0a1 SeaMonkey/2.7a1) and latest Lightning comm-central nightly -- Lightning1.b10pre -- 20110107.


@NRLacasse:

Are you using the latest *Lightning* nightly?
http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/win32-xpi/

I did not have today's update. I just updated it and it is working. I tend to right click in the add-on manager to update them when need be. I went to comm-central and downloaded today's update. I'll have to do less right clicking, sorry about that. I have SeaMonkey 2.7a1 so I'm also going to install it there. That will give me 3 versions of Lightning.

Thanks,
Norm
Can confirm the latest nightly update (7/10/11) from comm-aurora is working.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.