seen on mac builds (comm and moz) 2001-11-13-04-trunk -Install the build (stub or blob installers both fail) the installation process seems to complete. The splash screen pops up momentarily after installation, but then the app just silently fails. I'm not sure this is an installer bug. Perhaps it's build config or something else. Please assign it appropriately. Thanks
note: this a.m.'s windows build works fine (linux builds have been hosed since sat.)
the 2001-11-12-04-trunk build also exibited this failure. The last functional builds were from Friday, Nov. 9th.
This bug needs to be reassigned; Syd is unavailable today. Samir--who can help get this bug fixed?
here are file diffs between 11/9 and 11/13 builds- some files missing in 11/13 builds (using bbedit) file diffs between 11/9 and 11/13 builds 11/9 only- not in 11/13 ----------------------- chrome/all-locales.rdf chrome/all-packages.rdf chrome/all-skins.rdf chrome/overlay.info --all files in this folder chrome/user-locales.rdf chrome/user-skins.rdf components/xpti.dat essential files/RaptorShell.shlb widget.shlb in 11/13, not 11/9 ------------------ msgsmime.shlb non matching lines ------------------- 11/9 smime.shlb 11/13 smime-service.js v
Doesn't seem like an installer bug from the info in the report. Has someone tried installing the raw StuffIt archive? CC'ing some installer folks: curt and dprice.
assigning to curt, put that nice Mac I gave you to good use please :-)
Assignee: syd → curt
Erm, I think this is my fault.
Assignee: curt → sfraser
Aligning summary with symptoms manifested.
Component: Installer → Build Config
Summary: Installation fails silently on launch → App doesn't launch after install
Mac OSX build 2001-11-13-07-trunk also fails in the same manner.
Created attachment 57616 [details] [diff] [review] Fix to packages-mac Patch adds WidgetSupport.shlb in Essential Files, moves widget.shlb to Components, adds gfxComponent.shlb in Components, and removes the obsolete RaptorShell.shlb.
Comment on attachment 57616 [details] [diff] [review] Fix to packages-mac r=pink
Attachment #57616 - Flags: review+
Comment on attachment 57616 [details] [diff] [review] Fix to packages-mac sr=alecf
Attachment #57616 - Flags: superreview+
respin on os9 Moz 2001-11-13-11-trunk still fails silently respin on os9 Comm 2001-11-13-11-trunk now hangs on the splash screen
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
OK so this ain't fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is very weird. I can get the installed build to start up by moving the MJR plugin and jar file out of the Plug-ins folder. Put them back, and the build continues to start up. Debugging, the problem is one of JS permissions, I think. The failure point, which prevents us opening new windows, is in nsWindowWatcher::ConvertSupportsTojsvals(), where rv = contextGuard.Push(); fails.
Update: we're failing to init script contexts.
So here's the real problem. On the Mac, there is a MRJPlugin.jar file in the Plug-ins folder. This folder is in the XPT loading search paths, so we try to grovel in this .jar file for .xpt files, and fail. xptiZipLoader::EnumerateZipEntries() fails, xptiInterfaceInfoManager::DoFullValidationMergeFromFileList() returns PR_FALSE, and hence we never load any .xpt files. Bad.
Assignee: sfraser → jband
Status: REOPENED → NEW
So presumably this was caused by the checkin for bug 106122, which caused the plugins folder to be searched for XPT files?
Workaround checked in: Index: mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp =================================================================== RCS file: /cvsroot/mozilla/xpcom/reflect/xptinfo/src/ xptiInterfaceInfoManager.cpp,v retrieving revision 1.27 retrieving revision 1.28 diff -r1.27 -r1.28 234c234,235 < (void) AppendFromDirServiceList(NS_APP_PLUGINS_DIR_LIST, searchPath); --- > // Temporarily commented out; see bug 109893. > //(void) AppendFromDirServiceList(NS_APP_PLUGINS_DIR_LIST, searchPath);
Severity: blocker → major
Component: Build Config → XPConnect
Summary: App doesn't launch after install → Failure to look in .jar files for xpt files causes launch failure.
Was the fix to packages-mac necessary? Should it stay or go?
*** Bug 110054 has been marked as a duplicate of this bug. ***
mac os9 build 2001-11-14-04-trunk works fine.
The packages-mac fixes were necessary. We had compound bustage.
Created attachment 57960 [details] [diff] [review] fix to allow for case where zip/jar can't be openned I could not reporduce this on my Mac debug build (with MRJ stuff installed). Nevertheless, I tested this on Windows using a zip file that was being held exlusively open by another application. The old code would fail. With this patch we skip the locked file (logging a message if logging is enabled) and otherwise succeed. I think this is the right way to fix this.
Comment on attachment 57960 [details] [diff] [review] fix to allow for case where zip/jar can't be openned sr=jst
Attachment #57960 - Flags: superreview+
fix in trunk
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
verified fixed 2001111604 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.