Closed Bug 423727 Opened 16 years ago Closed 16 years ago

[Trunk] Calendar views are broken (Error:Trying to load a non-chrome URI)

Categories

(Calendar :: General, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hebbet, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

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
Attached image Lightning + TB nightly
the Screen
Component: General → Lightning Only
Product: Thunderbird → Calendar
QA Contact: general → lightning
Version: unspecified → Trunk
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Lightning Only → General
Severity: major → normal
Summary: Today's TB nightly + Lightning looks strange → [Trunk] Calendar views are broken (Error:Trying to load a non-chrome URI)
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)
Keywords: regression
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?
Blocks: 418356
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.
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").
OS: Windows XP → All
Hardware: PC → All
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.
Severity: normal → critical
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Works for me too using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b5pre) Gecko/2008032318 Calendar/0.6a1.
You need to log in before you can comment on or make changes to this bug.