XULRunner fails with "Couldn't load XPCOM"

RESOLVED FIXED in Firefox 39

Status

--
critical
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: allenlee8, Assigned: mikedeboer)

Tracking

({dev-doc-complete})

34 Branch
mozilla39
x86
Mac OS X
dev-doc-complete
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox39 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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
(Reporter)

Updated

4 years ago
Severity: normal → critical
(Reporter)

Comment 1

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

Updated

4 years ago
Component: XPCOM → XULRunner
Product: Core → Toolkit

Comment 2

4 years ago
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

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

Comment 4

4 years ago
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?
(Reporter)

Comment 5

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

Comment 6

4 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID

Comment 7

4 years ago
>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
(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.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Assignee: nobody → mdeboer
Status: REOPENED → ASSIGNED
Iteration: --- → 39.2 - 23 Mar
Points: --- → 2
Flags: qe-verify-
Created attachment 8577982 [details] [diff] [review]
Patch v1: update stub path finding to match the updated Mac app package signing requirements
Attachment #8577982 - Flags: review?(benjamin)

Comment 10

4 years ago
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.
Flags: needinfo?(mdeboer)
(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)
Flags: needinfo?(mdeboer)

Comment 12

4 years ago
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!
Flags: needinfo?(mdeboer)
(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.
Flags: needinfo?(mdeboer)
(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.

Updated

4 years ago
Attachment #8577982 - Flags: review?(benjamin) → review+
Keywords: dev-doc-needed
https://hg.mozilla.org/mozilla-central/rev/ea17ed6738b5
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago4 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
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!
Keywords: dev-doc-needed → dev-doc-complete
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.