Closed Bug 195788 Opened 22 years ago Closed 22 years ago

XPI installs not working properly on OSX

Categories

(SeaMonkey :: Installer, defect)

PowerPC
macOS
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED WORKSFORME
mozilla1.4alpha

People

(Reporter: thad.hoffman, Assigned: ssu0262)

References

()

Details

(Whiteboard: [adt1])

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030212 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030212 Trying to install either of the XPI installs fails on Mac OS X (10.1.5). The install runs but the add ins don't register in the browser. In fact, the debugger gets completely removed from the menu options and the splash screen no longer pops up. The 2 XPI urls listed install perfectly in NS 7.0 on the same machine. Reproducible: Always Steps to Reproduce: 1. click on link listed above and select the XPI component to install 2. let the xpi installer do it's thing 3. it tells you to quit the browser, do so 4. it doesn't attempt to start the browser again like it does in NS 7.0. Actual Results: I had to restart the browser. Nothing was installed (chatzilla) to install the debugger, not only is it not installed, but the previous option / version is no longer accessible via the menu. Note: NS 7.0 and even earlier builds of Mozilla start up classic mode to finish the install, this is awkward, but is successful and even restarts the browser) Expected Results: should have installed the component. My Mozilla build is not in my applications directory, but rather in a separate Mozilla builds directory on a different partition. Netscape 7.0 is in a Netscape builds directory on the same partition as Moz is. Running 10.1.5 as well.
Note about the splash screen, even when I trashed my Moz build and all files, & reinstalled, the splash screen no longer appears after attempting an XPI install.
Thad, have you communicated with those XPI's developers about this?
Summary: XPI installer says it is installed, but never restarts the browser or registers the add ins. → XPI installer says it is installed, but never restarts the browser or registers the add-ins
Keywords: nsbeta1
no, I found this via attemptng to update venkman and reported it first to Robert Ginda, he asked that I confirm it with other XPI installs and then log a bug. I don't know how or who to talk to, other than logging a bug. Chat ports are closed to me at work, I guess I could post to the newsgroup, is there an XPI NG? sorry.
With: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030305 Tried installing the venkman 0.9.52 xpi from the url in the bug.. but after relaunch about venkman still reports its 0.9.48... However, I have installed checky[1] and livehttpheaders[2] as well and they're running just fine so (just grasping at straws... never screwed with XPI stuff myself) it may be venkman or it may be in the update process. [1] http://checky.mozdev.org/ [2] http://livehttpheaders.mozdev.org/
Thad, coud you give it a try with the latest nightly? http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.3/
I'm running 10.1.5 and none of my browsers are located in the Applications directory. Rather they are all on a separate partition under Moz and Netscape builds directories. In case that makes a difference with XPI. Also, I have tried 3 times each (chatzilla and venkman) with clean installs of Moz 1.3b (after wiping all files and prefs) each time the installs run but the browser doesn't restart as it does for me with 1.0.1 or NS 7.0, also the existing chatzilla and venkman get removed from my system. The chrome directory shows .old and .new files but never a .js file. Changing the names doesn't restore either new or old venkman/chatzilla , only a reinstall seems to bring them back. It appears as though something with the registering and the file replacing is funky.
Hey Robert, Same thing with the 3-6 nightly. Showed 0.9.48 before install, installed, it said restart to finish, I quit Moz, it started to start up Moz, failed, I started up Moz, new debugger not installed, old debugger removed from Moz, no splash screen any more.
I just installed 1.3b on my osx machine at work, and tried to install the latest venkman on top of it. The XPInstall dialog said "Chrome Registration Failed", instead of "Success". Something is screwey.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think we should at least figure out what's going on here before 1.3 ships. XPI installs that work on older builds are failing on current 1.3 builds.
Flags: blocking1.3?
Just to confirm that the XPI of venkman 0.9.52 isn't goofy, I just successfully installed it on my Moz 1.0.1 builds both on OS 9.1 and on my OS X box. Both installed fine and the start-up screen still pops up correctly. (note, don't have 1.0.2, NS 7.0.2, or 1.2 builds on OS X as the XMLSerializer is busted in those builds preventing them from working with our app)
setting blocker flag while we look at this. may not last.
Flags: blocking1.3? → blocking1.3+
Just to make sure we're clear on this: XPIs that install properly on mozilla 1.0 and 1.2 based builds fail to install on current 1.3 builds, only on OSX.
Summary: XPI installer says it is installed, but never restarts the browser or registers the add-ins → XPI installs not working properly on OSX
To clarify my experiences with recent 1.3 branch builds: (1) XPIs that aren't updates seem to work without incident (see comment 4 ) (2) the venkman XPI seemed to execute fine but the version number didn't change on relaunch (3) the chatzilla XPI seemed to run without incident but I don't know how to check the versioning (no About > Chatzilla) on it so i can't say if it was successful or not (4) not yet mentioned here, but I filed a crash bug today on the CaScadeS XPI installer... Bug 196699
re: 2, if the venkman version number didn't change, then the install didn't happen properly. re: 3, use /about to check the chatzilla version.
re: 2 - seemed fine should read "without incident" - i didn't see any errors in the installer and was left with the usual Downloading > Installing > Restart to complete sequence. re: 3 - /about shows v0.8.23 so my earlier attempt to install 0.8.24 failed (as w/ venkman w/o incident) [removing extra http in URL field]
Bug 195109 will fix part of this bug (indicated by comment #4). I'm still investigating why the Chrome registration is failing.
Status: NEW → ASSIGNED
Blocks: 197105
Installer triage team: nsbeta1+/adt1
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1]
Flags: blocking1.4a?
*** Bug 197572 has been marked as a duplicate of this bug. ***
Flags: blocking1.4a? → blocking1.4a+
Doh, XPInstall not working is a BLOCKER, updating severity.
Severity: major → blocker
Target Milestone: --- → mozilla1.4alpha
In this newsgroup (netscape.netscape7.windows) see this message thread: From: Mark Knipfer <webmaster@techaholic.net> Newsgroups: netscape.netscape7.windows Subject: .XPI files not installing Date: Sat, 15 Mar 2003 13:30:50 -0500 Message-ID: <b4vr1v$3be4@ripley.netscape.com> about the Mozilla 1.3 .XPI file installation and download problems.
Using Mac OS X 10.2.4 and it just takes me to a URL of theme rather than installing. Page I am taken to just says true.
Testing on the latest MachO trunkg builds shows that this bug is not longer reproduceable. I was not even prompted to restart the browser. JS debugger just showed up in the menus and started right up. I have a feeling that this bug was fixed by the following bugs being fixed: bug 186088 - Mozilla crashes during installation of XPI Packages [@ nsInstallFile::CreateAllFolders] bug 195109 - XPInstall Pre-Checkin Trigger smoketest fails Remember, xpinstall under OSX for 1.3 is disabled, but not in the nightly OSX trunk builds.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
That's strange, AFAIK, Mozilla can't install an XPI that registers chrome on *any* platform without a restart. Are you sure the debugger wasn't already installed? Venkman prints the version number at startup. Does it match the version you installed?
I can confirm that the venkman 0.9.56 and chatzilla 0.8.24 XPI installers work fine under OS X 2003032413 (although i did need to restart before seeing the new version). Theme installations that failed before (Orbit from themes.mozdev.org) also seem to install without crashing now
I was able to reproduce the part about not getting the Restart dialog and venkman working right away, but not anymore. It's always showing the Restart dialog on every test now. Maybe my system was in a bad state? If it doesn't show a restart dialog, it's new different bug. If it's still crashing, please reopen this bug.
I've verified that this is working with today's 03/25 Mac Mozilla build on OS X 10.2.4. Venkman and several other popular XPI (piro's tabbed browser extension, stumbleupon toolbar, skypilot xpi theme) all installed and worked fine. I verified the version number in the new install of Venkman and it was correctly 0.9.56. I also tested gray modern theme, orbit retro theme and little mozilla which all installed and worked fine.
Status: RESOLVED → VERIFIED
build 2003032503 on Mac OS X 10.1.5 works for me installing venkman. Started with 0.9.48 installed 0.9.56 successfully. One note. After the "restart moz" prompt, I quit Moz and an instance of Moz attempted to start (started to bounce in the doc) but failed/quit. The quitting Moz (original instance) wasn't fully shut down as the other started to launch the quit. Didn't seem to have any adverse affects, just thought it noteworthy. Could be similar to how older versions of the venkman xpi used to launch classic in order to install.
It does not work on 2003032908 Mac OS X 10.1.5 - cannot install new thgemes. I click on install in the theme webpage but it changes window but does not start installation.
I'm running Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 on a G4 Mac with MacOS 10.2.4. I get the same problem mentioned earlier when trying to install the Pinball v2003-03-26 theme from mozilla.deskmod.com - install takes me to the theme's page but no installation or anything else appears to happen. (It doesn't seem to be just this theme - I've tried others). Similarly from the mozdev.org site, trying to download Pinball produces an extra browser window with URL "javascript:InstallTrigger.installChrome(InstallTrigger.SKIN, 'http://downloads.mozdev.org/themes/themes/pinball_2003-03-26_1.3.jar', 'Pinball 2003-03-26_1.3 M13:trunk') " but no further action. Javascript is enabled in my preferences. Hope I'm not missing something here? (I've only just downloaded Mozilla 1.3 having been on v1.2.1 with Pinball hapilly installed).
I am able to reproduce the last series of steps and NOT install Pinball theme on Mac OS X. I can install that theme on 1.3 on Windows. What I see after clicking on 'install it' on mozdev page- is the word 'true' on my browser page - but not followed by the download and installation of the theme as it occurs on Windows.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Guys, this doesn't work in Mozilla 1.3, it was fixed since then (21 Mar bug 186088). Try using nightly builds and installing the current version of Pinball (looks like 2003-03-26_1.3 as of now). WFM, Mozilla 2003040209 and Pinball 2003-03-26_1.3.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WORKSFORME
duh, sorry my mistake- tried with 4/7 nightly and it works
Status: RESOLVED → VERIFIED
Hi guys, I'm assuming all the stuff up above here is telling you what I'm about to anyway, but for the record, I'm using Mozilla 1.3 on an iMac running OS10.2.5, and when I try to install Themes from http://themes.mozdev.org/ I merely get a window with the word 'True' displayed. No theme download. Thanks for your work, Mozilla rocks. Cheers Matt
Mac OS X users, please try Mozilla 1.3.1 release candidate build at: http://ftp.mozilla.org/pub/mozilla/nightly/2003-04-17-13-1.3.1/mozilla-mac-MachO.dmg.gz That should have the XPI fix. If XPI is not working in that build, please complain loudly.
Product: Browser → Seamonkey
Component: Installer: XPI Packages → Installer
QA Contact: agracebush → general
You need to log in before you can comment on or make changes to this bug.