320266 - Many "Failed to load XPCOM Component:" info bubbles in the js-console when starting a new profile

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Joey Minta]

regression window: 20051213: no bug, 20051214: bug

When starting a new profile, I get a ton of info messages about failures to load particular components.  I first get

Failed to load XPCOM component: /home/joey/Sandbox/sb-12-14/sunbird/components/libimgicon.so
Failed to load XPCOM component: /home/joey/Sandbox/sb-12-14/sunbird/components/libmozgnome.so

Then I get similar messages for all of the javascript calendar-components.

The cpp components appear to be unaffected.

Perhaps bug 316416?

Comment 1

[Joey Minta]

More info:  I get similar messages starting up a thunderbird build from this morning.
Failed to load XPCOM component: /home/joey/.Trash/thunderbird/components/libmozgnome.so
Failed to load XPCOM component: /home/joey/.Trash/thunderbird/components/myspell/en-US.dic
Failed to load XPCOM component: /home/joey/.Trash/thunderbird/components/myspell/en-US.aff

etc...

Note that there appears to be no loss of functionality.

Triage suggestions?  This clearly doesn't belong in Calendar.

Comment 2

[Benjamin Smedberg]

The messages about imgicon, mozgnome, and the dictionaries are "normal" (we expect not to load some of these components when running on machines with downrev gnome/gtk installs).

What's this about all the calendar components not loading?

Comment 3

[Joey Minta]

After the failures in libimgicon and libmozgnome, I get the same messages about the calendar js-components in the following order:

Failed to load XPCOM component: /home/joey/Sandbox/sb-12-14/sunbird/components/calAlarmService.js

calAttachment.js
calAttendee.js
calCalendarManager.js
calRecurrenceInfo.js
calEvent.js
calItemBase.js
calTodo.js

Then the same messages about the components that use the import/export categories
calOutlookCSVImportExport.js
calHtmlExport.js
calIcsImportExport.js

The odd thing here is that the ordering doesn't really seem to match how they're listed in http://lxr.mozilla.org/mozilla/source/calendar/base/src/calItemModule.js#79

calItemBase should definitely be either first or last.

As I said, the components actually are being loaded and Sunbird functions without a problem.  So, the only problem is that these messages are appearing.

Comment 4

[Benjamin Smedberg]

This is in fact a calendar bug, because calendar is putting files into components/ which don't directly implement NSGetModule (these are subcomponents, calItemModule.js is the actual component-that-implements-NSGetModule).

The possible solutions include
1) renaming these submodules with another extension such as .js-submodule
2) moving these submodule files into a different directory such as res/modules
3) making each subcomponent a real component (blech)

Comment 5

[Benjamin Smedberg]

Actually option 1) wouldn't fix this bug, because we still won't have a componentloader for .js-submodule files.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #5)
> Actually option 1) wouldn't fix this bug, because we still won't have a
> componentloader for .js-submodule files.
> 

Why wouldn't that fix it?  Not having a component loader for those files means that noone would try and automagically load them, and they'd be loaded manually from calItemModule.js.

Comment 7

[Benjamin Smedberg]

The componentloader code issues a console warning about any file in components/ that isn't loaded, even if there isn't a componentloader for that file extension.

Comment 8

[LaurentS]

I get the same messages as in comment #3, but alarms don't work at all, along with a few other functions (import/export...).

This has happened with sunbird 0.3a1, the nightly build 20051228 and a home made build based on 20051229 source code. All of them under Windows XP, built with MSVC6 as detailed in the doc. I've never had any alarm working in any of these versions.

The order of the last few messages is slightly different in my case. The components are always the same .js scripts.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #8)
> I get the same messages as in comment #3, but alarms don't work at all, along
> with a few other functions (import/export...).

These warnings themselves are because the components in question have already been loaded.  Any functionality issues are separate problems.  These warnings are merely confusing and a waste of cycles.

Comment 10

[Matthew (lilmatt) Willis]

Attachment: rev0 - uses makefile targets to put non-module files elsewhere

This uses the libs and install targets to put .js files that don't implement nsIModule that previously lived in /bin/components in /bin/js.

It updates other files so they can find the files in their new location.

Comment 11

[Matthew (lilmatt) Willis]

There's some goofy stuff in the patch that doesn't show up even after checking out fresh copies of the files.

Rest assured I won't commit the parts where it's adding newlines all over the place or where it's rearranging const iosvcIID 

Comment 12

[Matthew (lilmatt) Willis]

Attachment: diff -w

Comment 13

[Matthew (lilmatt) Willis]

Comment on attachment 230210 [details] [diff] [review]
rev0 - uses makefile targets to put non-module files elsewhere

calendar/base/src/Makefile.in

Fix tabs vs. space in EXTRA_SCRIPTS.

+libs:: $(EXTRA_SCRIPTS)
+	$(NSINSTALL) -D $(DIST)/bin/js
+	$(INSTALL) $^ $(DIST)/bin/js
+
+install:: $(EXTRA_SCRIPTS)
+	$(SYSINSTALL) $(IFLAGS1) $^ $(DESTDIR)$(mozappdir)/js
See if we can use NSINSTALL for all three. If not, add comments explaining why not.

Index: calendar/base/src/calItemModule.js

http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/loader/mozJSComponentLoader.cpp#971

+        // We expect to find the subscripts in ./../js
+        var appdir = __LOCATION__.parent.parent;
+        appdir.append("js");
If __LOCATION__.parent ==  . make sure to make that clear in the comment.


Index: calendar/import-export/Makefile.in

Same NSINSTALL-fu from above.

+ install:: $(JS_SUBSCRIPTS)
Fix to be EXTRA_SCRIPTS


-	calImportExportModule.js \
+    calOutlookCSVImportExport.js \
Fix tab vs. space


r=dmose with those changes

Comment 14

[Matthew (lilmatt) Willis]

Patch with nits addressed checked in on MOZILLA_1_8_BRANCH and trunk

-> FIXED

Comment 15

[Matthew (lilmatt) Willis]

Attachment: lightning bustage fix

Bustage fix for lightning.

The patch changes from dist/bin/js to using FINAL_TARGET.

From http://lxr.mozilla.org/mozilla/source/config/config.mk#71

# FINAL_TARGET specifies the location into which we copy end-user-shipped
# build products (typelibs, components, chrome).
#
# It will usually be the well-loved $(DIST)/bin, today, but can also be an
# XPI-contents staging directory for ambitious and right-thinking extensions.

Comment 16

[Joey Minta]

Comment on attachment 231045 [details] [diff] [review]
lightning bustage fix

bah.. makefiles. r=jminta