371298 - Missing suiterunner components when run without write permissions (Mac disk image, etc)

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Georg Maaß]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414

In Suiterunner Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a3pre) Gecko/2007022208 SeaMonkey/1.5a and also builds of some previous days. Only Browser and Compaoser are available. Mail/News, Addressbook and Chatzilla are missing. I've downloaded the disk immage from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/phlox-trunk/

Also trying to start seaMonkey from the console as suggested by otheres in the news group did not change that.

/Volumes/SeaMonkey/SeaMonkey.app/Contents/MacOS/seamonkey-bin -mail 

There is a Bug #360271, which might be the reason for this. I did not build SeaMonky my self, so I don't know, with which configuration the builds at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/phlox-trunk/ are created. May be that the Mac builds are created with a unwanted configuration. 

Reproducible: Always

Comment 1

[Georg Maaß]

Attachment: Screenshot of the window menu where some components are missing

Mail/News, Addressbook and Chatzilla are missing

Comment 2

[Caio Tiago Oliveira (asrail)]

http://tinderbox.mozilla.org/SeaMonkey-Ports/

Full log:
http://tinderbox.mozilla.org/showlog.cgi?tree=SeaMonkey-Ports&errorparser=unix&logfile=1172161920.1172169308.28285.gz&buildtime=1172161920&buildname=MacOSX%20Darwin%208.8.0%20phlox%20Depend%20suiterunner&fulltext=1


-->mozconfig<----------------------------------------
# phlox tinderbox config
mk_add_options MOZ_OBJDIR=../build

mk_add_options MOZ_CO_PROJECT=suite
ac_add_options --enable-application=suite

. $topsrcdir/build/macosx/universal/mozconfig

# these are done in tinder-config.pl since this doesn't seem to work:
export MOZILLA_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
export BUILD_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1

#ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk
ac_add_app_options ppc --enable-prebinding

ac_add_options --disable-tests
ac_add_options --enable-extensions=default
ac_add_options --enable-optimize="-O2 -g"
ac_add_options --disable-debug
ac_add_options --enable-crypto

# SVG and canvas
ac_add_options --enable-svg
ac_add_options --enable-canvas

# build SeaMonkey as XUL app
MOZ_XUL_APP=1
MOZ_PKG_SPECIAL=suiterunner

# MOZ_XUL_APP mail does only build static
ac_add_options --enable-static-mail
-->end mozconfig<----------------------------------------

It looks fine...

There is a tests error:
  ### ERROR - unable to create search "file".

There is a make error:
http://tinderbox.mozilla.org/showlog.cgi?tree=SeaMonkey-Ports&errorparser=unix&logfile=1172161920.1172169308.28285.gz&buildtime=1172161920&buildname=MacOSX%20Darwin%208.8.0%20phlox%20Depend%20suiterunner&fulltext=1#err0

Comment 3

[Stefan [:stefanh]]

Hmm, I didn't see this with the latest phlox build (the one after yours). Are there any errors in the js console?

Comment 4

[Georg Maaß]

After starting the SeaMonkey I open the JavaScript console and do nothing else. I get following info messages and error messages:


INFO:
-----
No chrome package registered for chrome://wallet/locale/walletTasksOverlay.dtd .

ERROR:
------
Error: undefined entity
Source File: chrome://wallet/content/walletTasksOverlay.xul
Line: 78, Column: 5
Source Code:
    <menu id="menu_passwordManager"
      ^
      |
------+

INFO:
-----
No chrome package registered for chrome://wallet/locale/walletNavigatorOverlay.dtd .

ERROR:
------
Error: undefined entity
Source File: chrome://wallet/content/walletNavigatorOverlay.xul
Line: 105, Column: 7
Source Code:
      <command id="cmd_walletPrefill" label="&prefillCmd.label;" 
        ^
        |
--------+

ERROR:
------
Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.canGoBack]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://navigator/content/nsBrowserStatusHandler.js :: anonymous :: line 319"  data: no]
Source File: chrome://navigator/content/nsBrowserStatusHandler.js
Line: 319

Comment 5

[Stefan [:stefanh]]

(In reply to comment #0)

> /Volumes/SeaMonkey/SeaMonkey.app/Contents/MacOS/seamonkey-bin -mail 

This is the reason. You're running seamonkey straight from the disk image. I'm not sure everything gets properly installed if you do that.

Comment 6

[Mark Banner (:standard8)]

> (In reply to comment #0)
> 
> > /Volumes/SeaMonkey/SeaMonkey.app/Contents/MacOS/seamonkey-bin -mail 
> 
> This is the reason. You're running seamonkey straight from the disk image. I'm
> not sure everything gets properly installed if you do that.

I wonder if this is a problem due to having some of the chrome registered via manifest files (the new toolkit way) and some of it via contents.rdf (installed-chrome.txt - the old way).

Its just from the errors you've given and looking at:

http://lxr.mozilla.org/seamonkey/source/extensions/wallet/jar.mn

The xul/js for wallet is registered in the manifest files, but the locales isn't. Which would explain why you get the no chrome package registered message.

If so, then we need to fix bug 366673 (note that applying the patches on bug 366962 would fix the mailnews parts of this).(In reply to comment #5)

Comment 7

[Stefan [:stefanh]]

Might be that toolkit always had problems with this. But I think we've always discourage people to run the app straight from the disk image.

See http://kb.mozillazine.org/Installing_Firefox#Mac_OS_X

Comment 8

[Georg Maaß]

You are right, when copying it to the hard disk and running it from there, the missing components appear.

So this is a serious bug, because test software is usually recommended to run from disk image avoiding "installation" on hard disk. I've now moved it to a write enabled sparseimmage, which is a disk image which is growing automatically on write up to the specified maximum size. On an disk.image, which is write enabled, no such trouble occures.

So you probably have the same trouble with the components, when running directly from a live CD or from a write locked USB stick. Hm, tested now the Copy from the sparseimage after moving to USB stick running with stick write locked, but there I did not get that trouble. If I copy from the original Disk-Image to the USB-Stick and make it write locked and try to run ist now on the USB-Stick, then I get the trouble. This means, it must be "blessed" once by the target computer, when it is write enabled; afterwards it works on the same computer also write locked.

So the problem has to do with write permissions and attemping to write information about the target computer anywhere inside the application bundle.

Why can't it keep this hardware information in RAM, if the volume is write locked? Why doesn't it report an error indicating the problem to write something?

Comment 9

[Caio Tiago Oliveira (asrail)]

At the first time you run it recreates the "app-chrome.manifest", which is exactly the same as the one in the build.

So this file is just missing in the package.

Comment 10

[Caio Tiago Oliveira (asrail)]

That file is created at the first time the program runs but that is not on the build (I'd run the program from the build directory and mistakenly assumed that).
But copying a app-chrome.manifest of another directory works.

You can reproduce this on Linux if you unpack the package as a user and run as another without write permission. It's the default method for a local installation (with root as user and the other users don't have write access).

I haven't tested myself on Windows.

Comment 11

[Caio Tiago Oliveira (asrail)]

Attachment: Shows CZ on Window menu and make it to work properly

Comment 12

[Caio Tiago Oliveira (asrail)]

Attachment: Makes Venkman use manifests for Suiteruner

A lot of content.rdfs are in use when building Suiterunner.
As a way of supporting older extensions, they are registered and a manifest is built, but it requires write permissions to the directory.
So Suiterunner runs fine when you've write permissions to the directory, but fails to register some components otherwise (including messenger).

I may take care of those and ask for some help, if needed.


PS: Yes, I know they won't be reviewed until I ask for a reviewer. They are a work in progress. I hope I finish them next change I make to this bug (tomorrow, for me).

Comment 13

[Georg Maaß]

The file app-chrome.manifest resides at:

  SeaMonkey.app/Contents/MacOS/chrome/app-chrome.manifest

But this is not the only item with timestamp from now.

  SeaMonkey.app/Contents/MacOS/updates/0/

is also created.

So "blessing" seems to be just creating this file and the two directories (updates as child of MacOS and 0 as child of updates). Inside app-chrome.manifest I don't see any host related path information or anything else, which depends on the host. Also the two directories updates/0/ are not host dependent.

If this stuff is shipped as part of the disk image, then probably also running from CD or other write locked media works. 

Comment 14

[Mark Banner (:standard8)]

(In reply to comment #11)
> Created an attachment (id=256254) [details]
> Shows CZ on Window menu and make it to work properly
> 
If you do this, then you would break CZ's support for older versions of the apps it supports. I think it would be better if CZ was built as an extension and this would effectively remove the need to worry about installed-chrome.txt there. There are some issues around this and it should be handled in a separate bug, but I'd prefer to talk to the CZ & SM teams first.

Comment 15

[Georg Maaß]

But at least an error message "Can't do my first run stuff due of being unable to write to location, where i'm installed" should be reported to give the user a chance to know, what he migt do to change the situation.

Comment 16

[Caio Tiago Oliveira (asrail)]

Comment on attachment 256254 [details] [diff] [review]
Shows CZ on Window menu and make it to work properly

(In reply to comment #14)
> (In reply to comment #11)
> > Created an attachment (id=256254) [details] [details]
> > Shows CZ on Window menu and make it to work properly
> > 
> If you do this, then you would break CZ's support for older versions of the
> apps it supports. I think it would be better if CZ was built as an extension
> and this would effectively remove the need to worry about installed-chrome.txt
> there. There are some issues around this and it should be handled in a separate
> bug, but I'd prefer to talk to the CZ & SM teams first.
> 

Even using "#ifdef MOZ_XUL_APP" would it break CZ?
The idea is to build it as an extension, anyway: http://wiki.mozilla.org/ChatZilla:Suiterunner#Building_as_an_extension
so we can leave it alone.

Wouldn't be the same for Venkman?

https://bugzilla.mozilla.org/attachment.cgi?id=251217 fixes the mailnews part.

Georg, that directory don't being updated won't break anything related to this issue.

Comment 17

[Georg Maaß]

I don't know whether being unable to create these directories, if they do not already exist, causes any problems (except fetching updates). But the idea to update a write protected system is ridiculous. If missing the directories harms only the update facility, which never can work without write facility, then this can be ignored.

Comment 18

[Robert Kaiser]

So, actualkly the bug here is no real separate bug bug from what I see, it's just a symptom from bug 366673, which has turned practically into a meta-bug about a just-not-finished item on the toolkit transition list.

Comment 19

[Stefan [:stefanh]]

I don't really know, but isn't this more an issue with the package script? Looking at phlox's log:

Removing unpackaged files...
cd ../../dist/seamonkey/SeaMonkey.app/Contents/MacOS; rm -rf seamonkey-config  core bsdecho gtscc jscpucfg nsinstall viewer TestGtkEmbed bloaturls.txt codesighs* elf-dynstr-gc mangle* maptsv* mfc* mkdepend* msdump* msmap* nm2tsv* nsinstall* rebasedlls* res/samples res/throbber shlibsign* winEmbed.exe os2Embed.exe chrome/chrome.rdf chrome/app-chrome.manifest chrome/overlayinfo components/compreg.dat components/xpti.dat content_unit_tests necko_unit_tests 
/usr/bin/make -C ../build//i386/xpinstall/packager \
          UNIVERSAL_BINARY= SIGN_NSS= stage-package
Creating package directory...

Comment 20

[Georg Maaß]

You mean the chrome/app-chrome.manifest, which is removed together with other stuff. Is it created by the build process or is it created during testing? Can the build process know, that it is there, or does only a cleanup detect it as something to remove.

Comment 21

[Caio Tiago Oliveira (asrail)]

(In reply to comment #19)
> I don't really know, but isn't this more an issue with the package script?
> Looking at phlox's log:
> [snip]

Yes, the file is not included in the package when it there exists, but it is not created by the build process.
So, if you don't run Suiterunner on that folder the file wouldn't be included in the package, anyway.

Bug 366673, bug 351715 and its Venkman counterpart should fix this one. This bug still open since it's an issue while the others are tasks and would be good to confirm that this bug has been actually fixed.

Comment 22

[Georg Maaß]

In suiterunner Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a3pre) Gecko/2007030400 SeaMonkey/1.5a downloaded just now it is not fixed. But I now get crashes, when starting from the disk image or shutting down from the disk image. Might be a different problem or a regression when trying to fix this.

Comment 23

[Robert Kaiser]

Stefan:
We should not require those files, so it's correct for the build scripts to not package them. That we actually do need them is a bug, which is just caused by suiterunner not being finished yet.

Georg:
We know that it's not fixed, else the dependencies would be marked FIXED, and this bug would be as well. Suiterunner is experimental, we know many things don't work as they should yet, else the official nightlies would already be suiterunner ones. Your crashes are probably a different problem and a different bug.

Comment 25

[Rich Gray (:rbgray)]

Bug 395552 showed lack of writablity to the .app causing crashes as well as loss of CZ and Venkman.  Basically, if one user installs the .app but does not run it, other users get Chrome Registration failures and a crash on their first run, then Venkman & CZ are missing on restarts.   The classic case would be an admin user installing SM into /Applications, but not running it.   All other users would then suffer the failure.  Note that if a non-admin user installs SeaMonkey.app into /Applications (by authenticating with an admin user id and password), SeaMonkey.app is owned by the installing user, not the admin user, so the installing user will be able to successfully start SM.

Comment 26

[Georg Maaß]

Is that caused by toolkit? I see similiar problems as that of comment#25 when creating a XulRunner application. It works only for the usere, who assembled it, but other users need a lot of finder tricks to make it run also for them. Do you see there a relation?

I did not yet file a bug about that XulRunner issue, because I'm not sure whether that is a bug or just my fault. But it sounds similiar to what you write.

Comment 27

[Robert Kaiser]

If you are creating a XULRunner app that does not use manifests for chrome (and the obsolete contents.rdf approach instead), you're probably running into the same problem - but you never should be doing that for XULRunner apps anyways, why use a backwards-compatibility layer if you just can use the new approach of toolkit itself?

Comment 28

[Georg Maaß]

In that case the symptons seen with XulRunner applications on the Mac, seem to be an other issue, because I do not use rdf there but use a manifest file.

Comment 29

[Serge Gautherie (:sgautherie)]

Caio,
Are you still working on this ?

Comment 30

[Caio Tiago Oliveira (asrail)]

Thanks Serge, this issue was resolved on the meantime, using other approachs.