1105044 - XULRunner fails with "Couldn't load XPCOM"

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect)

Description

[allenlee8]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/8.0 Safari/600.1.25

Comment 1

[allenlee8]

Only happened in MacOSX version.  Runs fine on Win32.  Besides, firefox 34 is fine too.  Only XULRunner 34 on MacOSX fails.

Comment 2

[Benjamin Smedberg]

Probably related to the bundle restructuring for Mac v2 signing, but XULRunner is unmaintained so it's unlikely that this will be fixed unless somebody volunteers a patch.

Comment 3

[Todd Whiteman]

Likely that "dependentlibs.list" moved from Contents/MacOS to Contents/Resources (at least that was the problem for me).

Comment 4

[allenlee8]

You're right.  Need to move "dependentlibs.list" to Contents/Resources.  Besides, the files listed in dependentlibs.list (i.e. libmozglue.dylib, libnss3.dylib, libmozalloc.dylib, XUL)need to be moved to Contents/Resources too.   It's kinda puzzling why such changes were made.  Any one any idea why?

Comment 5

[allenlee8]

Corrections:  In fact, there's no need to move the files in the dependentlibs.list to the Contents/Resources folder.

Comment 6

[Todd Whiteman]

The app layout changes are due to Mac OS X new signing requirements - you can read about it here:
http://hearsum.ca/blog/upcoming-changes-to-mac-package-layout-signing/

And the top-level mozilla bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1046906

Basically, it means XULRunner apps (from 34 onwards) will need to restructure their Mac app in a similar manner.

Resolving this bug as invalid - as there's nothing else to be done here.

Comment 7

[Laurent Jouanneau]

>it means XULRunner apps (from 34 onwards) will need to restructure their Mac app in a similar manner.

How exactly? Are there some instructions somewhere? Where should we put files of our App?

I tried to reorganize XulRunner file in  MacOS and Resources folders, and put files of my app in the Resources folder, but the app is not launched, even if I do ./xulrunner ../Resources/application.ini (from the MacOs folder). However, I don't have anymore the "Couldn't load XPCOM" error.

If someone could help me. I'm not a MacOS developer. My scriptable browser SlimerJS does not work anymore on MacOS :-( https://github.com/laurentj/slimerjs/issues/301

Comment 8

[Mike de Boer [:mikedeboer]]

(In reply to Todd Whiteman from comment #6)
> Resolving this bug as invalid - as there's nothing else to be done here.

Well, there is something to be done actually. You're correct that the app bundles need to be restructured, but the XULRunner stub will still look for the 'XUL.framework' contents in the wrong location.

I'll attach a patch that resolves this. It does _not_ fix the SDK redistributable as can be downloaded from ftp.mozilla.org, but AFAIK that package can not be used as-is for quite some time now.

I'll update https://github.com/mikedeboer/chromeless soon with a package builder that shows how app developers can update their projects.

Comment 9

[Mike de Boer [:mikedeboer]]

Attachment: Patch v1: update stub path finding to match the updated Mac app package signing requirements

Comment 10

[Benjamin Smedberg]

Comment on attachment 8577982 [details] [diff] [review]
Patch v1: update stub path finding to match the updated Mac app package signing requirements

Are there docs about how things *should* be packaged? Is there still a XUL.framework directory to keep the framework separate from the app code? That seems to be desirable.

Comment 11

[Mike de Boer [:mikedeboer]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #10)
> Are there docs about how things *should* be packaged?

No, unfortunately, not that I know of. I can write these docs, of course, for XULRunner packaging specifically.

> Is there still a
> XUL.framework directory to keep the framework separate from the app code?
> That seems to be desirable.

No, Firefox also doesn't ship with 'Frameworks/' directory; everything is packed together in the 'MacOS/' directory, where binaries should reside.
The app code should, always has been AFAIK, reside in 'Resources/'.

So you end up with the following package structure on OSX:

XulrunnerApp.app/Contents/MacOS/      (has xulrunner_stub binary and all other files
                                       from legacy XUL.framework)
                        ./Resources/  (has 'dependentlibs.list', 'application.ini'
                                       and all other app resources)

Comment 12

[Benjamin Smedberg]

Perhaps I shouldn't be nitpicking this, since XULRunner is basically unsupported anyway, but I really do think that there is still value in XULRunner-based having the runtime completely segregated away in XUL.framework rather than mixed up with the app itself.

I realize that Firefox isn't going to do this.

But is there a technical reason we couldn't keep supporting this structure?

FooApp.app/Contents
  MacOS/xulrunner_stub
  Resources/application.ini and other application chrome files
  Frameworks/XUL.framework/Versions/Current/XUL (and other binaries here)
  Frameworks/XUL.framework/Versions/Current/Resources/ ... other chrome here

If mixing things up is the better/only option, I'll review the patch as-is and stop nitpicking!

Comment 13

[Mike de Boer [:mikedeboer]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #12)
> Perhaps I shouldn't be nitpicking this, since XULRunner is basically
> unsupported anyway, but I really do think that there is still value in
> XULRunner-based having the runtime completely segregated away in
> XUL.framework rather than mixed up with the app itself.

I totally agree! However, unfortunately, this is not possible anymore (read more below ;) )...

> 
> I realize that Firefox isn't going to do this.
> 
> But is there a technical reason we couldn't keep supporting this structure?

Please see http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/standalone/nsXPCOMGlue.cpp#300, which was introduced in https://hg.mozilla.org/mozilla-central/rev/f877c9b66cec. Perhaps you'll remember that one, because you reviewed it.

So we need to have the shared libraries in the 'MacOS/' directory, because this is not configurable.

Comment 14

[Mike de Boer [:mikedeboer]]

(In reply to Mike de Boer [:mikedeboer] from comment #13)
> Please see
> http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/standalone/
> nsXPCOMGlue.cpp#300, which was introduced in
> https://hg.mozilla.org/mozilla-central/rev/f877c9b66cec. Perhaps you'll
> remember that one, because you reviewed it.

I meant to say this with a big wink ;-) I obviously don't expect you, or anyone, to really remember all the things they've seen/ reviewed in the past!

I hope this makes it a bit clearer why we can't keep supporting this structure.

Comment 15

[Mike de Boer [:mikedeboer]]

Thanks for the review! Pushed to fx-team as:

https://hg.mozilla.org/integration/fx-team/rev/ea17ed6738b5

Comment 16

[Nick Alexander :nalexander [he/him]]

https://hg.mozilla.org/mozilla-central/rev/ea17ed6738b5

Comment 17

[Eric Shepherd [:sheppy]]

I have updated the article on deploying XULRunner (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner/Deploying_XULRunner#Mac_OS_X) to cover this change.

Please review the updated information and make any needed corrections; hopefully there won't be any needed!