489079 - Google Calendars disappear with latest trunk of Shredder [Error: Error parsing XML streamReferenceError: gCal is not defined]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Kris]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090418 Minefield/3.6a1pre GTB5
Build Identifier: trunk Shredder/Thunderbird 3.0b3pre 20090119033223

When updating Shredder to the latest trunk, Lightning no longer functions. The list of calendars cannot be seen in the calendar view, nor can the actual appointments on the calendar.

Reproducible: Always

Steps to Reproduce:
1. Update Shredder to latest trunk (today)
2. Restart Shredder
3. Calendars disappear
Actual Results:  
The list of calendars cannot be seen in the calendar view, nor can the actual appointments on the calendar.

Expected Results:  
To see my calendars, of course!

Comment 1

[Mark Banner (:standard8)]

(In reply to comment #0)
> Build Identifier: trunk Shredder/Thunderbird 3.0b3pre 20090119033223
> 
> When updating Shredder to the latest trunk,

Build 20090119033223 isn't the latest trunk. That is a build from the 19th January 2009. Did you mistype?

My build is:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090419 Lightning/1.0pre Shredder/3.0b3pre

(Lightning is todays, 19th as well).

Most calendars are working, but the gdata-provider is broken. I'm seeing:

Error: Error parsing XML streamReferenceError: gCal is not defined

on the error console.

Comment 2

[Kris]

Yes I did mistype. It IS from 20090419.

All I have is Gmail calendars, so all mine are broken. It may very well be the provider. Thank you for pointing that out. Does Mozilla develop the provider too?

Comment 3

[Mark Banner (:standard8)]

(In reply to comment #2)
> Does Mozilla develop the provider too?

The gdata-provider extension, yes.

Comment 4

[Daniel Boelzle [:dbo]]

This might be the same as bug 487205. Do you use a master password?

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> This might be the same as bug 487205. Do you use a master password?

No.

The only thing I saw that looked out of place was:

http://mxr.mozilla.org/comm-central/source/calendar/providers/gdata/components/calGoogleCalendar.js#769

all the other gCal references seem to have xml. or something else in front of them.

Comment 6

[Kris]

I've done more testing on this and have more to report.

20090418 and 20090419 trunk have issues with GCal. However, if you upgrade to latest trunk, then reinstall the Provider and Lightning, you can see your calendars in the left hand pane. However, they load on the calendar without the assigned colors and they do not give the pop-up notices of when an appt is due.

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to comment #5)

> The only thing I saw that looked out of place was:
> 
> http://mxr.mozilla.org/comm-central/source/calendar/providers/gdata/components/calGoogleCalendar.js#769
> 
> all the other gCal references seem to have xml. or something else in front of
> them.
The code here is fine. This is an e4x filter expression, everything in the () is automatically prefixed by whatever is outside of it.

Comment 9

[Mark Banner (:standard8)]

(In reply to comment #7)
> The code here is fine. This is an e4x filter expression, everything in the ()
> is automatically prefixed by whatever is outside of it.

Ok I missed that. In which case I've got no idea...

Comment 10

[Stefan Sitter [:ssitter]]

There were no changes to the Lightning and Provider for Google Calendar extension in the last days. I suspect that some change in the Mozilla Toolkit or Thunderbird might be the cause. 

Could you retest with current Lightning and Provider for Google Calendar extension but with previous Thunderbird nightly builds? It would be helpful to know the last working Thunderbird nightly build and the first failing one.

Comment 11

[Kris]

I'm got it to work in trunk 20090417 but none of the later trunks. But I'm going to have to downgrade because there are resource issues with this trunk.

Comment 12

[Mark Banner (:standard8)]

According to tinderbox, the 1.9.1 revisions used are:

17th April: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/37d1bb0c86b5
18th April: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/7b39d6b3b56d

Regression range: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-04-17+02%3A30&enddate=2009-04-18+02%3A56

Comment 13

[Stefan Sitter [:ssitter]]

Confirmed as regression using Provider for Google Calendar 0.6pre (2009042003):

Minimized regression range: Works in Sunbird 1.0pre (20090417073223)
                            Fails in Sunbird 1.0pre (20090417113701)

Checkins during regression range: <http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-04-17+07:30&enddate=2009-04-17+11:40>

I suspect it's caused by one of the many bugs that were landed on the mozilla-1.9.1 branch around Fri Apr 17 08:29:35 2009 by Robert Sayre. 

CCing Robert hoping that he can point to the right persons to look at this.

Comment 14

[Robert Sayre]

You should update again. There was a bug that bit Friday's builds pretty hard, fixed on Saturday night.

Comment 15

[Kris]

I installed trunk of all three this morning (20090420) and still the issue persists.

Comment 16

[Brendan Eich [:brendan]]

How about if you try reproducing using recent tracemonkey builds?

/be

Comment 17

[Stefan Sitter [:ssitter]]

Tested with 20090420 builds:

getItems_response() calls XMLEntryToItem():
    /calendar/providers/gdata/components/calGoogleCalendar.js
    line 882 -- var item = XMLEntryToItem(entry, timezone, this);

XMLEntryToItem() calls getIdFromEntry():
    /calendar/providers/gdata/components/calGoogleUtils.js
    line 702 -- item.id = getIdFromEntry(aXMLEntry);

getIdFromEntry() fails at the following call:
    /calendar/providers/gdata/components/calGoogleUtils.js
    line 662 -- var id = aXMLEntry.gCal::[e-mail]();
    
The exception bubbles upwards and is caught and reported in both XMLEntryToItem and getItems_response.

Comment 18

[Brendan Eich [:brendan]]

(In reply to comment #17)
> getIdFromEntry() fails at the following call:
>     /calendar/providers/gdata/components/calGoogleUtils.js
>     line 662 -- var id = aXMLEntry.gCal::[e-mail]();

Is that verbatim? What's the error?

It looks like a Google bug. They use an extended form of JS with namespaces (processed via a Rhino-based compiler, IIRC) and it looks like something leaked.

Or else they are now using E4X, but that works only in Firefox, and obviously it is not working in this app!

/be

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

Brendan: the CalDAV code in Lightning, which does use e4x in Thunderbird, is broken too, presumably by the same change.

Comment 20

[Stefan Sitter [:ssitter]]

> How about if you try reproducing using recent tracemonkey builds?
Do you mean Thunderbird 3.0b3pre (1.9.1) or Thunderbird 3.1a1pre (1.9.2)?

> Is that verbatim? What's the error?
See Comment #1 for the error message.

Seems CalDAV provider is affected by a similar error: http://groups.google.com/group/mozilla.dev.apps.calendar/browse_thread/thread/a3500811f8c7bef0

Was there some recent change regarding namespace handling?

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

Definitely 3.0b3pre (1.9.1); I haven't tested a 1.9.2 (3.1a1pre) build.  The error message you linked to is the same bustage I was referring to.

Comment 22

[Brendan Eich [:brendan]]

Who is using E4X? Google, or Firefox?

/be

Comment 23

[Stefan Sitter [:ssitter]]

It is used by Mozilla Sunbird and the Lightning extension from <http://www.mozilla.org/projects/calendar/>.

The source code mentioned above in comment #17 is located at <http://mxr.mozilla.org/comm-central/source/calendar/>.

<http://mxr.mozilla.org/comm-central/search?string=new+namespace&find=/calendar/> lists the source code places that might be affected too.

Comment 24

[Brendan Eich [:brendan]]

Anyone have a reduced testcase?

/be

Comment 25

[chris]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b4pre) Gecko/20090420 Lightning/1.0pre Shredder/3.0b3pre

Using CalDAV connecting to a google calendar, no events show in the calendar.

The error console shows:

Error: D is not defined
Source File: <snip-path-to-profile-extension>/calendar-js/calDavRequestHandlers.js
Line: 206

With the offending line as:

multigetQueryXml.D::prop += <D:href xmlns:D={D}>{locpath}</D:href>;

Comment 27

[lord_alan]

Confirmed. I use TB3 (Latest nightly) and Lightning 1.0 (latest nightly) with the Cosmo Caldav Calender Server - NOT Google.

Same problem. Calendars are not displayed and the error is as in #25 above.

Going back to a TB build of 17/04/09 but maintaining my Lightning from 20/04/09 and the calenders work.

Am running on Ubuntu Jaunty.

Comment 28

[Brendan Eich [:brendan]]

Reduced testcase still welcome...

/be

Comment 29

[Mike Beltzner [:beltzner, not reading bugmail]]

Why do we think this blocks Firefox Beta 4 as opposed to final?

Comment 30

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #29)
> Why do we think this blocks Firefox Beta 4 as opposed to final?

This is possibly an upvar correctness bug, with unknown consequences. At the very least, we should block until we understand what, exactly, is broken.

Comment 31

[Andreas Gal :gal]

Reporting conversation 2nd-hand. This might be a fallout from upvar2, and we think its a p1 blocker to find out whats going on. The fix might be lower priority. Brendan is working on this today.

Comment 32

[Brendan Eich [:brendan]]

Attachment: reduced js shell test

Comment 33

[Brendan Eich [:brendan]]

Attachment: fix (condignly ugly for e4x)

Comment 34

[Brendan Eich [:brendan]]

http://hg.mozilla.org/tracemonkey/rev/ab3af3308c0e

/be

Comment 35

[Brendan Eich [:brendan]]

Fixed in m-c:

http://hg.mozilla.org/mozilla-central/rev/8fa4388dc10b

/be

Comment 36

[Jens Müller (:tessarakt)]

Please fix it in

Comment 37

[Jens Müller (:tessarakt)]

Please fix it in Shredder 3.0b3pre! Thanks ...

Comment 38

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Given this is blocking1.9.1 it will be checked in in the next few days on mozilla-1.9.1, which means it will be fixed in the following Shredder build.

Comment 39

[Stefan Sitter [:ssitter]]

Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090422 Shredder/3.1a1pre (BuildID: 20090422073425) with Lightning 1.0pre (20090422) and Provider for Google Calendar 0.6pre (20090422). Tested both CalDAV and GData provider against Google Calendar.

Comment 40

[Kris]

Please advise where you downloaded those version: this isn't the Shredder version I get from the latest-trunk folder.

Comment 41

[Kris]

This is what I get from the trunk folders: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b4pre) Gecko/20090422 Lightning/1.0pre Shredder/3.0b3pre ID:20090422031642

Comment 42

[Stefan Sitter [:ssitter]]

I took the hourly build from <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/tinderbox-builds/comm-central-trunk-win32/1240410114/> because of the missing win32 nightly builds.

Comment 43

[Kris]

Pardon my stupidity, but did you get Provider and Lightning from the latest-trunk or somewhere else?

Comment 44

[Peter Lairo]

I still see this bug using Tb 3.0b3pre + Lightning 22-Apr-2009 06:25 PST build. No Google CalDAV calendars are visible.

(In reply to comment #39)
> Verified fixed using ... Shredder/3.1a1pre with Lightning 1.0pre (20090422) 

BTW: I have never been able to get Thunderbird trunk 3.1* to work with Lighning trunk at all (even before this bug existed). That is why I have been using Thunderbird pseudo-branch-trunk 3.0b3pre. How did you get 3.1* to work?

I'm (conf)using:

ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/

http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/win32-xpi/

Too many confusing "trunk" FTP directories (latest-trunk, latest-comm-central, latest-comm-central-calendar). If they all go to the same place, why have them? it's confusing. Trunk should be trunk. </rant>

Comment 45

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Please be patient, this is not fixed in 3.0b3pre, since its not checked into 1.9.1 yet.

mozilla-1.9.1 => 3.0b3pre
mozilla-central (1.9.2a1pre) => 3.1a1pre

Comment 46

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5e9b409c7ed4