User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031806 Minefield/3.0b5pre Build Identifier: version 3.0a1pre (2008031802) Default settings! See screenshot. Reproducible: Always

the Screen

The main view in Sunbird is broken also: Error: [Exception... "'Trying to load a non-chrome URI.' when calling method: [nsIModule::getClassObject]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] Error: [Exception... "'Trying to load a non-chrome URI.' when calling method: [nsIModule::getClassObject]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "<unknown>" data: no] Error: [Exception... "'Trying to load a non-chrome URI.' when calling method: [nsIModule::getClassObject]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: chrome://calendar/content/calendar-month-view.xml :: :: line 837" data: no] Source File: chrome://calendar/content/calendar-month-view.xml Line: 837 Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://calendar/content/calendar-month-view.xml :: :: line 837" data: no] Error: [Exception... "'Trying to load a non-chrome URI.' when calling method: [nsIModule::getClassObject]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: chrome://calendar/content/calendar-month-view.xml :: :: line 837" data: no] Source File: chrome://calendar/content/calendar-month-view.xml Line: 837 Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://calendar/content/calendar-month-view.xml :: :: line 837" data: no] Error: [Exception... "'Trying to load a non-chrome URI.' when calling method: [nsIModule::getClassObject]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: chrome://calendar/content/calendar-multiday-view.xml :: :: line 2312" data: no] Source File: chrome://calendar/content/calendar-multiday-view.xml Line: 2312 Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://calendar/content/calendar-multiday-view.xml :: :: line 2312" data: no] Error: [Exception... "'Trying to load a non-chrome URI.' when calling method: [nsIModule::getClassObject]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: chrome://calendar/content/calendar-multiday-view.xml :: :: line 2312" data: no] Source File: chrome://calendar/content/calendar-multiday-view.xml Line: 2312 Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://calendar/content/calendar-multiday-view.xml :: :: line 2312" data: no] Error: [Exception... "'Trying to load a non-chrome URI.' when calling method: [nsIModule::getClassObject]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: chrome://calendar/content/calendar-management.js :: getCompositeCalendar :: line 47" data: no] Source File: chrome://calendar/content/calendar-management.js Line: 47 Error: uncaught exception: [Exception... "Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]" nsresult: "0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE)" location: "JS frame :: chrome://calendar/content/calendar-management.js :: getCompositeCalendar :: line 47" data: no] Error: [Exception... "'Trying to load a non-chrome URI.' when calling method: [nsIModule::getClassObject]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: chrome://calendar/content/calendar-management.js :: getCompositeCalendar :: line 47" data: no] Source File: chrome://calendar/content/calendar-management.js Line: 47 Error: this.monthView is null Source File: chrome://calendar/content/calendar-month-view.xml Line: 703 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031812 Calendar/0.6a1

Regression range: Works in Sunbird 0.6a1 (2008-03-17-06) Fails in Sunbird 0.6a1 (2008-03-17-22) Checkins during regression range: http://tinyurl.com/3862xs Possible causer: Bug 418356 (checkin comment: Set the right url in the script and don't allow loading non-chrome scripts.) Maybe someone with enough permissions can check if Bug 418356 is really the causer and if this is unwanted fall-out or if the entire calendar code must be updated. (If there are plans to port the patch to 1.8 branch we might be in serious trouble)

Maybe bzbarsky could give a comment on this.

Very likely, yes. I did see that there were lots of subscript loader calls in calendar, and couldn't tell what sort of URIs they were loading. I assumed they were being sane; apparently I was wrong. So: 1) What sort of URIs are they loading? 2) What sort of permissions do they expect the resulting script to run with?

I think the FoxyProxy extension is also affected by this: Failed to load XPCOM component: /Users/user/Library/Application Support/Firefox/Profiles/SALT/extensions/foxyproxy@eric.h.jung/components/superadd.js Failed to load XPCOM component: /Users/user/Library/Application Support/Firefox/Profiles/SALT/extensions/foxyproxy@eric.h.jung/components/proxy.js Failed to load XPCOM component: /Users/user/Library/Application Support/Firefox/Profiles/SALT/extensions/foxyproxy@eric.h.jung/components/foxyproxy.js Error: uncaught exception: Trying to load a non-chrome URI. Error: uncaught exception: Trying to load a non-chrome URI.

See http://starkravingfinkle.org/blog/2008/03/extension-developers-breaking-news-part-2/ and my post to mozilla.dev.security http://groups.google.de/group/mozilla.dev.security/browse_frm/thread/9b49bdf4dda69e03/6f7f08249dde12e8?tvc=1#6f7f08249dde12e8

Kris, that has nothing to do with this bug, really... The extension might just need to be fixed. Simon, can you answer the questions from comment 5?

Boris, I'm not entirely sure, but from looking at code sections like http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/calendar/itip/calItipEmailTransport.js&mark=374-397#363 http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/calendar/providers/memory/calMemoryCalendarModule.js&mark=70-97#64 http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/calendar/import-export/calImportExportModule.js&mark=116-149#110 it seems to me, that we're trying to load the JS files from mozilla/calendar/base/src, mozilla/calendar/itip and mozilla/calendar/providers/* taht we're trying to access here. Those files contain either general functions like calItemBase.js or calProviderBase.js, helper functions like in calUtils.js or specific protocol functions for the different calendar providers (ics, CalDAV, WCAP, etc.) or iMip/iTip. In a Sunbird release/nightly build, those file all live in c:\$AppDirectory$\js Does that help, Boris?

In reply to comments 5 and 9: This is done because some of our XPCOM Javascript components that get installed into the <installDir>/components directory need to use the common code that gets installed in the <installDir>/js directory. This is true for both Sunbird and Lightning. For Sunbird the path is right off the install path, <InstallDir>/components and <installDir>/js. For Lightning, you get something like this: <thunderbird profile>/extensions/<lightingUID>/components and <thunderbird profile>/extensions/<lightingUID>/js As far as permissions go, I'm a little unclear what they expect as I didn't create this structure. I know that the scripts that are performing these calls expect to run with normal user (non-elevated) permissions and the scripts expect to be able to execute Javascript code on the scripts they load. Bz: Does that answer your question? Simon: Your guess was correct, except the items we're loading do not get loaded from source, but from their location in the JS directory of the installed build of the software.

What I really wanted to know is: 1) What URI scheme is used to load the files? Is it file://? 2) If the files had the permissions that any web page loaded from that URI scheme has, would they break? The above comments don't really answer those questions (though it's sounding like "file://" and "yes").

The code that loads the files is this: 236 var fileurl = iosvc.newFileURI(f); 237 loader.loadSubScript(fileurl.spec, null); So, yes, it's a file:// uri. And the files loaded are the xpcom components that make the heart of calendar, so, yes, I guess that they would break if loaded like any webpage. They need to access a lot of other xpcom components, write to files, etc.

Boris, bug 418356 comment #35 sounds like a good way to me, too (and would avoid any changes to current calendar code). How likely is this to be implemented and when? Reading that bug, it's unclear to me how to correctly load subsequent (or shared) js files of js XPCOM components.

Unknown and unknown. But before anything lands on branch, for sure. And before the beta. Ideally, you guys would be using resource URIs instead of file URIs, obviating some of the jitters jst and I have about the whole thing... But there are extensions that are using file:// without the ability to use resource://, so it's all bad.

Presumably, for the longer term on trunk, calendar wants to use Components.utils.import for the perf win of only evaluating each included file once.

TB build: version 3.0a1pre (2008032106) Lightning: 2008032020 It works again

Marking as FIXED as jst's additional checkin for bug 418356 seems to fix this for us.

Works for me too using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b5pre) Gecko/2008032318 Calendar/0.6a1.