per Dan's comments in bug 26497. This only seems to be an issue on Linux. On Mac and Windows, even if the folder is "read-only", XPInstall still downloads files to it. This is how the Mac & Win OS behave as well, so we're consistent. We're also consistent with Linux, but install doesn't occur (w/ -225 error). 1. Make destination folder non-writable. e.g. on Linux, chmod 444 theFolder. (for this test case, create a folder called "a_addtestfile" and make it read-only). 2. Execute any xpi to it. Go to http://jimbob/trigger2.html. (a_addtestfile). Trigger. OK. 3. Check directory contents for install. (a_addtestfile) Result: On NT, Win98 & Mac, it let's you install, but not on Linux. Get -225 error. Can't list files in the directory. Suggestion: The only idea I can think of is install to a temporary directory. Don't rename installed files.

changed QA owner.

marking as REMIND.

not going to support this in current release. Moving to M30 and put on Help Wanted list.

Parcelling out Cathleen's bugs

Changing fictional "M30" to reality

*** Bug 64042 has been marked as a duplicate of this bug. ***

Updating QA Contact.

A whole slew of folks are experiencing this trying to install the gestures add-on <http://optimoz.mozdev.org>. Our bugzilla has more details on the issue: see <A HREF="http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=xpi&field0-0-1=component&type0-0-1=substring&value0-0-1=xpi&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=xpi&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=xpi&field1-0-0=product&type1-0-0=substring&value1-0-0=install&field1-0-1=component&type1-0-1=substring&value1-0-1=install&field1-0-2=short_desc&type1-0-2=substring&value1-0-2=install&field1-0-3=status_whiteboard&type1-0-3=substring&value1-0-3=install">the bugs</A>.

I'm copying some of my comments on the closed bug 105679 "Must surf as root for XPinstall under Linux" Say I want to install multizilla under Linux. I visit multizilla.mozdev.org as a user (of course, since I don't surf as root!). I then click on the proper link having "software installation" enabled. It will then download the package and say *nothing*. In effect, the package never gets installed. The same thing happens with the Java plug-in so this is a far reaching bug. Reproducible: Always Steps to Reproduce (multizilla): 1. Install Sun's JVM under Linux (rpm -ivh j2sdk-1_4_0-beta2-linux-i386.rpm for example) 2. You can verify that a mozilla-compatible plugin is available under /usr/java/j2sdk1.4.0/jre/plugin/i386 1. Install mozilla under Linux. 2. Visit a page like http://multizilla.mozdev.org/installation.html where you can install a component. (Surf as a user, not as root!) 3. Click on the proper link, wait till the download is done. Actual Results: You receive no error message. The package was never installed. Steps to Reproduce (java): 1. Install mozilla under Linux. 2. Visit a page like http://www.javalobby.org where you are asked to download the Java Plug-in 3. Click on the proper link, wait till the download is done. Actual Results (both cases): You receive no error message. The package was never installed. Expected Results (both cases): The package should get installed or at the very least, a proper error message should pop up saying that you can't install components as a user (please give the warning *before* the download!). Workaround: quit mozilla, log on as root (or other privilege account), visit the web page, install the package, quit mozilla, log on as user and use package. That's ugly, very inconvenient and potentially unsafe.

Sorry... I got mixed up... here's the multizilla steps: Reproducible: Always Steps to Reproduce (multizilla): 1. Install mozilla under Linux. 2. Visit a page like http://multizilla.mozdev.org/installation.html where you can install a component. (Surf as a user, not as root!) 3. Click on the proper link, wait till the download is done. Actual Results: You receive no error message. The package was never installed.

Not sure there's anything we can do. We can't warn the user ahead of time or deny the download because quite a number of things happily install into your profile. We can announce the failure to the user instead of relying on the triggering web site to do so but that's covered by another bug. People can write their install scripts with permission problems in mind, but that's an issue for lame script writers to resolve. I've heard chrome content cannot be installed to a profile dir unlike chrome skin or locale files, if so that's a limitation the chrome guys will have to resolve. Letting a web site probe your system for permissions is a security hole, so the best they could do is post the requirements on their site. Open to any ideas of what we could do differently.

I've submitted several solutions on mailing lists and such. They were all rejected because the XP model is too weak to allow any solutions for the packagers. I don't know anything about this, but before you close the bug saying "up to the packagers", please make sure the packagers *CAN* do something about it. If they can't, then the blame must lie with XP. Can the packagers of the Java Plug-in solve this problem? I see several ways to do it: A) Check for the presence of a JVM on the current machine. An engineer from Sun told me they could not do that, they can only provide an XP package. So damn... you have to download several megabytes just to get Java working even if you have all of the good stuff on your machine already... "because there is no other way"... B) Download only a descriptor (or the first bytes of the package) to check for the right permissions, so that you could at least abort a useless download. Again, I've been told that the packagers cannot do that. This descriptor could also look to see if there is already a Java plug-in before downloading the whole thing... again, I've been told that it is impossible, XP installation wasn't meant for this. C) Install in user space. Unfortunately, that's impossible, mozilla won't allow that for things such as the java plug-in, multizilla and so on. Other browsers have solutions to this. With Konqueror, I never need to surf as root to install Java. Strangely enough, they pull this trick without any security issue. So there *is* a way to do it. It might mean expanding the XP installation process, I don't know... but you just can't hide being the security issues... Quite the contrary, asking people to surf as root to install stuff is a security threat.

What about a model like this... 1) Download the damn thing to a tmp dir. So that you'll always download the thing. It is a bug to download to oblivion!!! If the user download something, make sure it gets written on disk. 2) Then, if the installation requires to be root, give a command that root must execute. The user can then copy and paste the command and make the request to a sysadmin or do it itself. At the very least, this way, it won't look like a bug. It will merely be inconvenient... but that would be much better than the current scenario... 1) Download to /dev/null for a long time. 2) Doesn't install, but user gets no warning. 3) Package apparently not working... 4) User go back to 1... Loop.

OS->ALL, this primarily affects Unix, but other platforms can also have write-protected directories or disk-full errors and the like. The installer puts files where the script says and that's about it. It sounds like most of your problem is because Mozilla is not flexible enough to run chrome and components from user directories. That is NOT an installer problem, that is a Mozilla problem and should be addressed elsewhere (bug 14923 for example). The installer can't magically make these other problems go away. For your Java example, A&B could be worked on creatively by thinking of individual install scripts as part of an install system rather than the end-all itself. I'll work with Sun off-line. The problem in C is essentially bug 14923 and there's nothing the install engine can do about it. As to your model of our current scenario 1) we already download to /tmp (/dev/null? please.) 2) telling the user about errors is bug 98458 3) offering to save the downloaded files is bug 47805 A command line to cut and paste would require bug 77365 I'm going to turn this into a tracking bug because I don't see any specific new thing to be done here.

Adding to comment 9: It is not only the case that we get no error message. Try for example: http://diggler.mozdev.org/diggler-0.4.xpi Click Install. Receive the message: "Download and installation status: diggler-0.4.xpi Success" This is clearly wrong. The installer should be able to detect that it could not write. So I really think that this is not an enhancement, it is a bug which makes it impossible to install those XPIs. pi

Could someone please comment. Mozilla claims that some installation is successful which is not. There seems to be no way to install XPI as a user under Linux. So this is a bad bug (actually dataloss and a total loss of function). If this here is a meta enhancement bug (whatever that means), where is the right bug to deal with that problem? pi

From the diggler install script: addFile("Diggler", "diggler.jar", // jar source folder getFolder("Chrome"), // target folder ""); // target subdir registerChrome(...) .... if (err==SUCCESS) performInstall(); rhetorical question: where does "err" get set? If you look at your install.log I'm sure you'll see that the addFile command returned an error, which you're ignoring. Then the registerChrome calls fail because the jars don't exist -- but you don't catch that error either. Finally you run performInstall which encounters no errors because there is nothing to do. If you want to be lazy and not track individual errors (reasonable enough in such a simple install) you could change "if (err == SUCCESS)" to "if (lastError() == SUCCESS)". XPInstall can't just stop and report the first error we come across, there is no way for the engine to be smart enough to know when it's really a fatal error or when the script has a reasonable backup plan. For example, the language packs typically do something like err = addDirectory(...global...); if (err != SUCCESS ) err = addDirectory(...profile...); If we stopped at the first error we'd block correctly installing the locale into the profile. Incidentally a recent bugfix landed which allows chrome *content* (not just locales and skins) to be installed into the profile directory -- might be worth looking into.

Filed bug 201966 for making extension install to profile dir the default behaviour.

The xpinstall script engine has been removed from the trunk, bugs in it are obsolete.