User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a5) Gecko/20041122 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a5) Gecko/20041201 Since the 20041201 build, Mozilla is not able to open any .xpi files. Nothing happens, after the trial the preferences won't open. Shutting Mozilla an instancer of mozilla.exe remains in memory and has to be killed using the task manager. Once I got a crash with the tackback ID TB2303367K, but I could not reproduce crashes. I tried with the actual german 112604-de_AT language file, with the 1.8a5 de_AT language-file, with a theme Early-Blue.xpi which worked since 1.4 with any Mozilla and with themer.xpi (.jar-installer extension), same behaviour. My profile was not broken, with the same profile works 20041130 nightly and 20041122 1a5-release. Reproducible: Always Steps to Reproduce: 1. Download and install Mozilla 20041201 18a6 nightly (custom install with all components or without chatzilla and DOM-inspector. 2. Try to open an .xpi - file for installation. 3. Actual Results: Preferences won't open After shutdown of Mozilla an instance remains in memory, it won't diappaear after some waiting Expected Results: Open and install of the .xpi (or refuse as "needs update") TB2303367K talkback ID. It's a regression.

I see this also. With the same description.

*** This bug has been marked as a duplicate of 272688 ***

After bug 272688 had been fixed, the .xpi istallation dont work with the 20041202 Mozilla nightly. There had been no crash, the installation dialog appears, the earlier behaviour of staying in memory wasn't there any more. But there was no function of the installer, only to read "stopped" in the status bar. That is why I reopened the bug, may be it is more than bug 272688.

i tried to install adblock and flashblocker with todays trunk build, XP, and allthough the "install" dialog appeared and i clicked it, nothing more happened. Nothing was installed.

This might be because bug 266554 didn't land on the trunk yet, but the aviary xpinstall changes refering to it did.

removing extraneous CC. Thought I had blown it away in my last comment

This is still dead on build 2002120304. It hangs Mozilla if you try to install one by dragging it to the browser window.

This is still dead on build 2004120304. It hangs Mozilla if you try to install one by dragging it to the browser window.

(In reply to comment #5) > This might be because bug 266554 didn't land on the trunk yet, but the aviary > xpinstall changes refering to it did. Are you saying that we need a referrer send to be able use XPInstall? Oh, and a note to 'James Rome'. Please don't add a comment for each and every build you are going to use...I don't think that this will help anybody here. Thanks.

Ah, I found bug 264560, interesting...

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

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

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041207 OS: ALL + Bloking1.8a6: ?

KKuhlemann@t-online.de: Drivers have advised me that you don't have permission to set a Blocking Flag to "+", thus resetting to "?".

Also happening on Linux: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041208

status update: I have been working on this, got stuck in aviary->trunk merge hell on some other bugs.

nscizor: mkaply (driver) had already set the blocking+ bit: why on earth are you downgrading it?

Don't remove (driver only) blocking (-/+) flags...

(In reply to comment #17) > nscizor: mkaply (driver) had already set the blocking+ bit: why on earth are you > downgrading it? Sorry

I just happened to be trying a debug Mozilla to try to fix another problem, and I got this when trying to install an XPI: ###!!! ASSERTION: Can't invoke XPInstall FE without a FE URL! Set xpinstall.dialog.status: 'NS_SUCCEEDED(rv)', file mozilla/xpinstall/src/nsXPInstallManager.cpp, line 479 I guess this is the reason it doesn't work, I just hope Daniel Veditz knows how to fix it. ;)

FYI: you can still install your extensions, even with the most recent version of Mozilla, but with a little extra work: 1) download the XPI instead of installing it 2) 'unzip' the JAR file from the downloaded XPI 3) copy the JAR file to the mozilla application directory 4) copy the lines from installed-chrome.txt in the downloaded XPI and paste them to mozilla/chrome/installed-chrome.txt 5) delete mozilla/chrome/chrome.rdf 6) restart mozilla

Got an e-mail that it didn't work, so I loked again and it seem that MultiZilla's installed-chrome.txt looks like this: content,install,url,jar:resource:/chrome/multiviews.jar!/content/ skin,install,url,jar:resource:/chrome/multiviews.jar!/skin/ locale,install,url,jar:resource:/chrome/multiviews.jar!/locale/en-US/ but that must be converted, after you've paste it to mozilla/chrome/instaled-chrome.txt like this: content,install,url,jar:resource:/chrome/multiviews.jar!/content/multiviews/ skin,install,url,jar:resource:/chrome/multiviews.jar!/skin/modern/multiviews/ skin,install,url,jar:resource:/chrome/multiviews.jar!/skin/classic/multiviews/ locale,install,url,jar:resource:/chrome/multiviews.jar!/locale/en-US/multiviews/ i.e. you need "multiviews/" at the end, and make sure you have two lines, for 'skin'. One for 'modern' and one for 'classic' theme. Other extensions can be installed like this, but you might need to copy a component from the jar file to mozilla/components/compname.js In that case you also need to remove mozilla/components/compreg.dat before you start Mozilla. I hope this helps, like it helped other people to install MultiZilla with a new profile, in the aplication directory ;)

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

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

A line of thought worth investigating, at least until someone tells us what's happened to cause this: Firefox/Thunderbird require an install.rdf file be in extensions for Mozilla. Maybe with the aviary landings, Mozilla does too. So I considered adding in a install.rdf for Mozilla App Suite as a possible test. Unfortunately, I don't know of any uuid for MozAppSuite, so I don't know precisely how to add an install.rdf to a dummy XPI for testing. Would it be reasonable to expect MozAppSuite to eventually use the Extension Manager code, and thus have a uuid? If so, declaring one now would mean I could test to see if install.rdf is the pitfall for this bug. Also, re comment 20: setting xpinstall.dialog.status didn't seem to help.

Hm, Firefox still installs the file, both 1.0 and 1.0+ from beast tinderbox, so maybe my guess is wrong.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041122 Mozilla 1.8a5 is not affected by this bug. So when exactly did this regress?

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-11-17&maxdate=2004-12-01&cvsroot=%2Fcvsroot Bonsai query from 11-17-2004 (1.8a5 freeze) to 12-01-2004 (when bug was first reported). I see only checkins on 11-30 as likely culprits for this bug. Those checkins were from an aviary landing. XPInstall was touched by dbaron on 11-29, but only to remove platform-forms.css. Based on bonsai evidence, adding aviary-landing keyword and cc'ing ben, who authored the patch.

Answer to Alex Vincent, comment #27: This bug appeared first in the 1.8a6 20041201 Seamonkey nightly, the 20041130 nightly did not show the bug. I have tested both - it's the exact time.

I have backed out locally all the changes landed to xpinstall/src as part of the aviary landing and, once done and recompiled, XPIs can be installed into Mozilla suite

(In reply to comment #30) > I have backed out locally all the changes landed to xpinstall/src as part of the > aviary landing and, once done and recompiled, XPIs can be installed into Mozilla > suite May I ask what files you have backed out locally? Do you have a bonsai link for me?

I did the following to back out changes since 30th November 2004: cvs update -j1.229 -j1.228 nsInstall.cpp cvs update -j1.96 -j1.95 nsInstall.h cvs update -j1.72 -j1.71 nsInstallTrigger.cpp cvs update -j1.90 -j1.87 nsSoftwareUpdateRun.cpp cvs update -j1.106 -j1.105 nsSoftwareUpdate.cpp cvs update -j1.39 -j1.38 nsXPInstallManager.h cvs update -j1.129 -j1.127 nsXPInstallManager.cpp The relevant diffs are: http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fxpinstall%2Fsrc&file=nsInstall.cpp&rev1=1.229&rev2=1.228&whitespace_mode=show&diff_mode=context http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fxpinstall%2Fsrc&file=nsInstall.h&rev1=1.96&rev2=1.95&whitespace_mode=show&diff_mode=context http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fxpinstall%2Fsrc&file=nsInstallTrigger.cpp&rev1=1.72&rev2=1.71&whitespace_mode=show&diff_mode=context http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fxpinstall%2Fsrc&file=nsSoftwareUpdateRun.h&rev1=1.90&rev2=1.87&whitespace_mode=show&diff_mode=context http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fxpinstall%2Fsrc&file=nsSoftwareUpdate.cpp&rev1=1.106&rev2=1.105&whitespace_mode=show&diff_mode=context http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fxpinstall%2Fsrc&file=nsXPInstallManager.h&rev1=1.39&rev2=1.38&whitespace_mode=show&diff_mode=context http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fxpinstall%2Fsrc&file=nsXPInstallManager.cpp&rev1=1.129&rev2=1.127&whitespace_mode=show&diff_mode=context

> I see only checkins on 11-30 as likely culprits for this bug. FWIW: I haven't been using any of the newer builds for December because, when using them, none of my extensions (notably Linky) would work - they simply wouldn't show up in my context menus. For a while I was using a 12/06 build - which still showed me my context menu extensions - but I just now deleted all of my extensions in an attempt to fix this, before I stumbled onto this bug. Even though 12/06 showed me my context menus additions from extensions that were already installed, it wouldn't let me install any new extensions. I'm now back to a 11/30 build which does let me install extensions. So, it certainly does look like comment 28 and comment 29 are accurate. The 11/30 build was the last one in which extensions worked properly. Moreover, it looks like things have gotten worse as December has progressed because even though I couldn't install a new extension in the 12/06 build, I *could* still use any that were already installed. Builds after that wouldn't even do that.

Please add the following preferences, and you should see a progress dialog, and XPI now works for me! xpinstall.dialog.confirm "chrome://communicator/content/xpinstall/institems.xul"); xpinstall.dialog.progress.chrome "chrome://communicator/content/xpinstall/xpistatus.xul?type=extensions"); xpinstall.dialog.progress.skin "chrome://communicator/content/xpinstall/xpistatus.xul?type=themes"); xpinstall.dialog.progress.type.chrome "Extension:Manager-extensions" xpinstall.dialog.progress.type.skin "Extension:Manager-themes" This works for me, with a mozilla version that was unable to install any XPI's because it returned an -201 error, and so didn't install anything! One note, I had to set chrome:extension="true" myself (chrome.rdf) but that can be related to all my testing...I hope this help guys, Merry Christmas :-)

(In reply to comment #34) Oops, don not add the " "); junk left in from my .js file ;)

Make sure you either disable white listing (A) or white list the domain name (B) you use for XPInstallations! (A)Disabling white listing: 1) enter 'about:config' in location bar 2) enter 'xpinstall.' as filter (shows a short list with prefs) 3) double-click on 'xpinstall.whitelist.add' (a dialog box should open now) 4) select false 5) press enter, or click on the OK button (B)White listing a domain: 1) enter 'about:config' in location bar 2) enter 'xpinstall.' as filter (shows a short list with prefs) 3) double-click on 'xpinstall.whitelist.add' (a dialog box should open now) 4) enter 'mozdev.org or 'mozilla.org' (examples) or whatever domain you need 5) press enter, or click on the OK button

(In reply to comment #36) Darn, make that 'xpinstall.whitelist.required' for (A/3) P.s. MultiZilla users can 'enable' installed extensions with QPrefs/Extension Management...

Using a current CVS build of Mozilla on Linux, I can manually fiddle with the preferences as per comment #34 and comment #36) and get a test XPI (PrefBar, found at http://prefbar.mozdev.org/) to install. However, PrefBar then seems to be totally broken: it doesn't create the menu entry or toolbar it's supposed to, and its section of Preferences (in Advanced -> Preferences ToolBar) comes up with the selection of buttons/etc totally blank. (Possibly this is or should be another bug, but I am guessing that it is an error in the installation process.) (I tested this with a totally clean build and a new $HOME, so it is definetly not picking up anything from my normal Mozilla install.)

> (Possibly this is or should be another bug, but I am guessing > that it is an error in the installation process.) I doubt that this is a problem with the install. As I said in comment 33, I had previously existing extensions (such as Linky) that had been installed and worked just fine under earlier builds, which, while still installed, failed to function properly under the newer builds. While you could be correct that these are actually two separate bugs (although we can't really know, at least without further testing / confirmation of what's happening, until this one is fixed and then see if that also fixes the other), I'm "assuming" that it's something about the XPI code in general that's broken both installation of new extensions *and* interpretation of existing extensions.

(In reply to comment #38) I installed prefbar and the XPInstall process worked just fine. Just check chrome/installed-chrome.txt for the entries for the prefbar and chrome.rdf is also Ok. I also have the preferences in my pref tree, so the overlay works, however, I see some tree errors (in JS console) but that might be because of Jan Varga's tree patch for Mozilla and so I don't think this is XPInstall related. Again, I have installed not only MultiZilla and the GoogleBox, but I also installed a theme, all without any problems, so the prefs work, as you will find out soon enough!

(In reply to comment #39) > While you could be correct that these are actually two separate bugs (although > we can't really know,... Oh but I do :-) XML Parsing Error: error in processing external entity reference Location: chrome://prefbar/content/prefbarOverlay.xul Line Number 42, Column 69:<!DOCTYPE window SYSTEM "chrome://prefbar/locale/prefbarOverlay.dtd"> --------------------------------------------------------------------^ chrome://prefbar/content/prefbarOverlay.xul -<!DOCTYPE window SYSTEM "chrome://prefbar/locale/prefbarOverlay.dtd"> +<!DOCTYPE overlay SYSTEM "chrome://prefbar/locale/prefbarOverlay.dtd"> and also replace all instances of 'toggle-prefBar:key' with 'toggle-prefBar.key' and all instances of 'prefbar-toggle:label' with 'prefbar-toggle.label' chrome://prefbar/locale/prefbarOverlay.dtd -<!ENTITY toggle-prefBar:key "VK_F8"> -<!ENTITY prefbar-toggle:label "Preferences Toolbar"> +<!ENTITY toggle-prefBar.key "VK_F8"> +<!ENTITY prefbar-toggle.label "Preferences Toolbar"> Happy Holidays...

(In reply to comment #34) HJ, can you explain exactly what needs to be done manually in chrome.rdf and/or installed-chrome.txt ? Because I tried installing BiDi Mail UI, and I saw basically the same results as in comment #38.

(In reply to comment #42) > (In reply to comment #34) > > HJ, can you explain exactly what needs to be done manually in chrome.rdf and/or > installed-chrome.txt ? Because I tried installing BiDi Mail UI, and I saw > basically the same results as in comment #38. I didn't change anything in installed-chrome.txt for MultiZilla, GoogleBox and ToyFactory, and I don't think you need to for other extensions. Feel free to e-mail me the link for that add-on and I might have a look at it later today ;) Adding the missing preferences makes XPInstall work again, but some other (Mozilla?) bugs might prevent the add-on from being fully functional, but that's up to the extension authors to find out!

I followed HJ's comments exactly (except "xpinstall.whitelist.add" should be xpinstall.whitelist.required->false ?). Autoscroll, optimoz, multizilla, and googlebox now all install and work just fine in the 12/26 nightly! Many thanks again HJ! No edits to installed-chrome.txt were required and I simply deleted chrome.rdf prior to a restart.

Im using Windows 2000 SP4 with last build 2004122705. Trying install Calendar, quicknote and other themes and nothing. Only the box SOFTWARE INSTALLATION open, and I click Install. Then the box disapears, and nothing happends.

So when are these fixes going to be applied to the nightly builds?

(In reply to comment #45) > Im using Windows 2000 SP4 with last build 2004122705. > > Trying install Calendar, quicknote and other themes and nothing. > Only the box SOFTWARE INSTALLATION open, and I click Install. > Then the box disapears, and nothing happends. You might have a typo in one of the pref settings. Also, did you check mozilla/install.log for possible errors?

(In reply to comment #47) > (In reply to comment #45) > > Im using Windows 2000 SP4 with last build 2004122705. > > > > Trying install Calendar, quicknote and other themes and nothing. > > Only the box SOFTWARE INSTALLATION open, and I click Install. > > Then the box disapears, and nothing happends. > > You might have a typo in one of the pref settings. Also, did you check > mozilla/install.log for possible errors? No errors in the install.log, and the key xpinstall.whitelist.required are set to "false". If I uninstall this build and install the 1.8a5 all my extensions are installed ok, then I think no errors in my profile to.

Ok, here's what I tried: - created a new profile - set the preferences as per the instructions in comment #34 - installed BiDi Mail UI 0.6, from http://bidiui.mozdev.org/ . The installation went fine (this is an installation to the profile directory) - Restarted mozilla - The overlays for the extension simply do not load - The chrome directory of the profile appears to be in order: the .jar is there, the chrome.rdf entries are there, the overlayinfo subdirs are correctly populated (AFAICT) etc. Then I tried the following: - installed Mozilla 1.8a5 - created a new profile - installed BiDi Mail UI 0.6, from http://bidiui.mozdev.org/ ; it worked after restaring Mozilla - installed a 'latest' build I downloaded yesterday And the extension stopped working. No Javascript errors, yet no overlay would load, either for the messenger window or for the message composition window. However, the extension prefs were visible and manipulable in Edit|Preferences.

(In reply to comment #46) > So when are these fixes going to be applied to the nightly builds? Whoa, slow down. (1) No one's offered a patch, so for all intents and purposes, this is still busted. (2) Even if someone did offer a patch incorporating the workaround, we don't know yet if that is the correct course of action. There may be other bugs underlying which this doesn't fix yet. dveditz, ben, could you comment please?

For what it's worth, I successfully batch-installed 30 extensions and three themes from my local disk, on both Windows and Linux, everything globally (Mozilla program directory), after adding the prefs mentioned in comment #34. Pulled an built Mozilla from CVS/trunk. Everything working as expected (as far as I can see). So at least we have a workaround, right? If some extensions are broken, this could be the result of some other changes made to the trunk. There may be other bugs open for them.

The workaround described in comment #34 and #35 did not work for me. After install of the latest 20041227 nightly my old themes and extensions (themer.xpi) worked fine. Having done the 4 new preferences and having set whitelist on false, installation of the german language file was successfull, the install log was OK. But Mozilla was severely broken after the installation and following switch to the german language. The only readable part was the progress bar, which was german, menu-bar, right-click-menu and preferences had been completely gone, they werent shown at all. That is why, this workaround is not sufficient to fix this bug. Comment #38 and #49 show that other people had broken installations, too.

(In reply to comment #52) > Having done the 4 new preferences and having set whitelist on false, > installation of the german language file was successfull, the install log was > OK. But Mozilla was severely broken after the installation and following switch > to the german language. To me, this sounds like the workaround works indeed. This bug is titled "Mozilla is unable to open .xpi files", and after the prefs are set you *are* able to install xpi files. Any problems occuring after the XPInstall engine processed the xpi file and installed the containing files should be filed as separate bug.

Jens Bannmann, you are right. Sorry, I did not see that there was a new 20041222 de_at.xpi because mozilla.kairo.at is offline. With this file and with the skypilot theme available as .xpi, installation works fine. But nevertheless I tried very often to install a language .xpi which was too old, it never damaged Mozilla before, normally there was no effect switching to it or it told "needs update". Probably Robert Kaiser, who is in the cc list, can explain why the 20041126 file did so or whether its still a bug.

(In reply to comment #49) > And the extension stopped working. No Javascript errors, yet no overlay would > load, either for the messenger window or for the message composition window. > However, the extension prefs were visible and manipulable in Edit|Preferences. This is what I see: XML Parsing Error: error in processing external entity reference Location: chrome://bidimailpack/content/composeOverlay.xul Line Number 5, Column 1:%bidimailpackDTD; ^ and that's because te extensions author uses a ':' instead of '.' for things like: :label (instead of .label) :accesskey (instead of .accesskey) :keycode (instead of .keycode) :modifiers (instead of .modifiers) etc... and I'm almost sure, without checking, that this is the same problem for the German language pack. There might be another bug filed for this...

(In reply to comment #54) > Jens Bannmann, you are right. Sorry, I did not see that there was a new 20041222 > de_at.xpi because mozilla.kairo.at is offline. With this file and with the > skypilot theme available as .xpi, installation works fine. OK, so the next step for this bug would be to integrate the prefs HJ came up with into the default settings, right? Anyone who had problems, please report if XPI installation itself works so that we can finally fix this bug. Broken extensions are /not/ covered by this bug. > But nevertheless I tried very often to install a language .xpi which was too > old, it never damaged Mozilla before, normally there was no effect switching to > it or it told "needs update". Probably Robert Kaiser, who is in the cc list, can > explain > why the 20041126 file did so or whether its still a bug. I don't want to sound rude but that has nothing to to with this bug, so it should not be discussed here. Extensions (esp. language XPIs for nightlies) break over time. Nothing special about it. Just wait for an updated version or contact the author. bugzilla.mozilla.org is just the wrong place for broken (third-party) extensions.

Possible patch based on comment 34. To stay with the current behaviour, whitelisting stays disabled (AFAIK we don't have UI yet). Dan, is this a sufficient fix, or did we miss something?

(In reply to comment #57) > Created an attachment (id=169705) [edit] > possible patch, for xpfe/bootstrap/browser-prefs.js > > Possible patch based on comment 34. To stay with the current behaviour, > whitelisting stays disabled (AFAIK we don't have UI yet). > > Dan, is this a sufficient fix, or did we miss something? We don't need "xpinstall.dialog.progress" see also: http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsXPInstallManager.cpp#90

> pref("xpinstall.whitelist.add", "mozilla.org, mozdev.org, texturizer.net"); > pref("xpinstall.blacklist.add", ""); > +pref("xpinstall.blacklist.required", "false"); You did just add .blacklist.required, but not .whitelist.required. Are the following two prefs still needed? > pref("xpinstall.dialog.progress", > "chrome://communicator/content/xpinstall/xpistatus.xul"); > pref("xpinstall.dialog.progress.type", "");

Took out the unused .progress and .type prefs, changed accidental "blacklist.required" to the correct "whitelist.required"

Comment on attachment 169706 [details] [diff] [review] revised patch +pref("xpinstall.whitelist.required", "false"); is this really a string pref?

(In reply to comment #61) > is this really a string pref? Oops, of course not. Thanks!

Note to extension(add-on) authors: please check bug 276434 for the why and what not about using colons instead of dots, thank you.

Having these prefs is fine, but having a dialog (triggered when an XPInstallation is blocked) would also be handy don't you agree? I wonder if a bug (RFE) for this is filed or not...

As well as adding these new prefs there will need to be a way of adding/removing sites as per firefox - not sure what ff does about sites which aren't in the list or are blocked wrt visible warnings.

(In reply to comment #64) > Having these prefs is fine, but having a dialog (triggered when an > XPInstallation is blocked) would also be handy don't you agree? I wonder if a > bug (RFE) for this is filed or not... FF does display info bars that contain/link the UI for adding sites to the whitelist. The first step for getting all that into Seamonkey is porting info bars, which is done in bug 270443

Comment on attachment 169760 [details] [diff] [review] patch v3 I think these values are wrong for Seamonkey. Basically you should just duplicate the progress prefs but with extra chrome and skin suffixes.

(In reply to comment #67) > (From update of attachment 169760 [details] [diff] [review] [edit]) > I think these values are wrong for Seamonkey. Basically you should just > duplicate the progress prefs but with extra chrome and skin suffixes. We are using the right values, not the Mozilla Firefox values i.e.: chrome://mozapps/content/extensions/extensions.xul?type=extensions chrome://mozapps/content/extensions/extensions.xul?type=themes I use the original Seamonkey value: chrome://communicator/content/xpinstall/xpistatus.xul with |?type=extensions| and |?type=themes| to prevent the XPIstallation process from failing with some other error, presumably error -207

I've attached a patch to bug 270170 as a provisional pass at install whitelists.

(In reply to comment #68) >+pref("xpinstall.dialog.progress.type.chrome", "Extension:Manager-extensions"); >+pref("xpinstall.dialog.progress.type.skin", "Extension:Manager-themes"); And what about these?

(In reply to comment #70) > (In reply to comment #68) > >+pref("xpinstall.dialog.progress.type.chrome", "Extension:Manager-extensions"); > >+pref("xpinstall.dialog.progress.type.skin", "Extension:Manager-themes"); > And what about these? The values should both be set to "Extension:Manager" and we should add windowtype="Extension:Manager", probably at this point: http://lxr.mozilla.org/seamonkey/source/xpinstall/res/content/xpistatus.xul#47 to enable nsXPInstallManager.cpp to focus a previously opened XPI progress window.

Still not working for me after all whitelist, .chrome and .skin modifications. This is what i get after trying to install theme: - Error: window.arguments has no properties Source File: chrome://communicator/content/xpinstall/xpistatus.js Line: 130 -

Alexander: What do you xpinstall entries now read? What website are you trying to install from? What are the exact steps you take to get this error message?

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

Ian, user_pref("xpinstall.dialog.progress.chrome", "chrome://communicator/content/xpinstall/xpistatus.xul?type=extensions"); user_pref("xpinstall.dialog.progress.skin", "chrome://communicator/content/xpinstall/xpistatus.xul?type=themes"); user_pref("xpinstall.dialog.progress.type", "Extension:Manager"); user_pref("xpinstall.dialog.progress.type.chrome", "Extension:Manager-extensions"); user_pref("xpinstall.dialog.progress.type.skin", "Extension:Manager-themes"); I have played with various Extension:Manager* settings and now i am not able to reproduce error in JavaScript window. Anyway, i just opened JavaScript console and clicked "Install" on da site - and error appeared. The site is spuler.us, theme - Smoke. Also tried on some themes on mozdev.org. Let me know if i can by at any further assistance.

Comment on attachment 169760 [details] [diff] [review] patch v3 > pref("xpinstall.whitelist.add", "mozilla.org, mozdev.org, texturizer.net"); as long as we're here change this to have only "update.mozilla.org" r/sr = dveditz

(In reply to comment #76) > (From update of attachment 169760 [details] [diff] [review] [edit]) > > pref("xpinstall.whitelist.add", "mozilla.org, mozdev.org, texturizer.net"); > > as long as we're here change this to have only "update.mozilla.org" Is this an official policy change, as in The Mozilla Foundation no longer 'trust' the other sites that were white listed before? If so, can we first have bug 270170 fixed before this change goes into the tree?

Ah, I seem to have missed the following line: +pref("xpinstall.whitelist.required", false); That will work...

yup, we'll definitely do bug 270170 before actually turning this on. In the meanwhile I don't want to propogate a bad list (*.mozilla.org in particular)

Actually scratch the previous, this one is right. The suite doesn't make a distinction between skin and other installs on the progress dialog. If we make one in the future there's no guarantee the extra cruft here is what we'd use. We don't have a central group progress dialog type to notify or focus, using a blank type actually does the right thing here.

Fix checked in.

Bummer, It never shows this theme (skin) dialog window: http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsXPInstallManager.cpp#286 Is that working for you?

dveditz: why removing mozdev.org if you mainly care about *.mozilla.org? mozdev has a big bunch of Seamonkey XPIs and it looks bad to disable access to those, especially if we have no UI (not counting about:config) to enable them again. Or does that patch mean that we disable whitelisting (and blocking XPIs outside the whitelist) completely for now? (That would make things easier but may be considered a security regression to previous releases and therefore should be relnoted IMHO)

(In reply to comment #83) > why removing mozdev.org if you mainly care about *.mozilla.org? I guess for parity with Firefox. However, the whitelist is not yet enabled, so it doesn't really make a difference. > Or does that patch mean that we disable whitelisting (and blocking XPIs outside > the whitelist) completely for now? > (That would make things easier but may be considered a security regression to > previous releases and therefore should be relnoted IMHO) Since when has Seamonkey required the whitelist for XPIs? At least in my 1.7.3 install, the pref "xpinstall.whitelist.required" defaults to false...

"Or does that patch mean that we disable whitelisting (and blocking XPIs outside the whitelist) completely for now?" Yes it does - see comment 78 and comment 79. "That would make things easier but may be considered a security regression to previous releases" I don't think it's a big deal - if it's been enabled in previous releases at all (I'm not sure it has), then they were only earlier 1.8alpha releases. It's off in 1.7.x releases.

(In reply to comment #85) > I don't think it's a big deal - if it's been enabled in previous releases at all > (I'm not sure it has), then they were only earlier 1.8alpha releases. It's off > in 1.7.x releases. I remember not being able to install XPIs from the Mozilla German page (mozilla.kairo.at) in 1.7.5 without adding that site to the whitelist - and I think it was true for earlier 1.7.x builds as well.

I tried the Mozilla 2001010506 build on XP Pro. xpi installs kind of work. 1) Enigmail took minutes (literally!) before the install window appeared. During this time, Mozilla was totally non-responsive, and I thought it had hung up. 2) Calendar installs (also slowly) but will not run. I no longer seem to get a compreg.dat file in my profile. 3) It is MUCH faster to save the .xpi file as a file and then to drag it to mozilla. This should not be the case.

And JAR theme files are no longer supported? Nothing happens when i try to install them. XPi's working quite well after patch.

Re comment #88: This would appear to be the same issue as Firefox bug 273423.

This JAR bug is introduced by the patch for bug 242529. We should change the following line to make it work, without the previous work around/hack: http://lxr.mozilla.org/mozilla/source/xpinstall/src/nsInstall.h#76 -#define XPINSTALL_BUNDLE_URL "chrome://global/locale/xpinstall/xpinstall.properties" +#define XPINSTALL_BUNDLE_URL "chrome://communicator/locale/xpinstall/xpinstall.properties"

Isn't /xpinstall used by both toolkit and suite though? So making this change would break firefox?

Why is xpinstall depending on a properties file that's not part of xpinstall itself? The properties file in qiestion should be part of core xpinstall (like the Gecko localization files are part of Gecko), not part of the app.

fwiw, the problem is basically that part of the aviary change never made it, compare: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpinstall/res/jar.mn&rev=FIREFOX_1_0_RELEASE&mark=8 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpinstall/res/jar.mn&rev=1.4&mark=8

fwiw this stuff is covered by bug 273423

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

Eliminating colons from entities broke PrefBar, one of the most popular Mozilla Suite and Firefox extensions. This illustrates why bug #258881 should be implemented, integrated PrefBar into Mozilla products. If that had already been done, the elimination of colons would have included modifications to PrefBar to preserve compatibility.

THis bug is still present in 1.8a6 *release* version. Plus, the personal toolbar is gone...reverting back to 1.8a5 fixes the problems... I wonder, why do the devs release buggy versions???? The KNOW about these issues and still release a non-working, buggy version??? why in the world would they do that?????? bye!

(In reply to comment #97) > THis bug is still present in 1.8a6 *release* version. An Alpha is an Alpha, and not a "real" *release*. "Real" releases are final Releases like Mozilla 1.8 will be. The latest Mozilla *release* is 1.7.5, and there will even be a Beta before the final 1.8 release. When your personal toolbar is gone, it indicates that your installation or personal profile may have a bigger problem than just this bug. Personal toolbar is working quite well for everyone I heard so far.

Jorge, you should at least check for JavaScript errors on your JavaScript console, because I'm sure you will find one or more, if you enabled the dump, chrome and stricts warnings/errors. Also, what extensions (add-ons) do you have installed? Make sure to disable them one by one, to find the cause of the error, good luck.

This is a bug in PrefBar: http://bugzilla.mozdev.org/show_bug.cgi?id=8653 Same thing happened with the DownloadWith extension, because they all use colons where dots should be used... np: Verbose - Maykasaharaspointofview (Intelligent Toys 2)

Is this bug still there? I wanna try the newest nightly-build, but I don't wanna screw something up. I'm still using 1.8a5 build 20041122.

(In reply to comment #101) > Is this bug still there? > I wanna try the newest nightly-build, but I don't wanna screw something up. > I'm still using 1.8a5 build 20041122. RESOLVED FIXED, as the status says. Go ahead. :-) However, if extensions/themes fail to work, there might be other issues independent from the one this bug is about.

Alright, I just dloaded and installed both the latest milestone "1.8a6" and the latest nightly build and both still suffer from the same bug: The personal toolbar appears blank. In both cases, re-installing 1.8a5 fixed it. Why is this bug marked as "resolved"?????

As far as I am aware the personal toolbar being blank is nothing to do with this bug, this bug was to do with being able to install .xpi files.

Plus, if it does have anything to do with XPIs (this bug affected me in terms of already installed XPIs and things being black), you need to remove all existing extentions, exit Mozilla, delete your chrome.rdf file, restart Mozilla, and reinstall your extensions. If, after installing a particular extension, problems occur again it's that one extensions fault.

I'll try a clean install, to avoid any problems...But, I remeber doing that a little while ago and the personal toolbar still appeared blank, on a fresh installation...AND XPIs couldn't be installed, also.

(In reply to comment #106) > I'll try a clean install, to avoid any problems...But, I remeber doing that a > little while ago and the personal toolbar still appeared blank, on a fresh > installation...AND XPIs couldn't be installed, also. This sounds like a serious JavaScript error to me, so what JavaScript errors do you see on your JS console? Oh, and please take a look at your debug pref panel "Show chrome JavaScript errors and warnings" (javascript.options.showInConsole) before you reply with something like; I don't see no JS errors ;)

OK, but I'm still gonna try a clean install of the latest nightly. bye!

Alright, I found some time to do a clean install of mozilla 1.8b2 20040220. It works, but now my fav themes/addons don't work or completely screw-up mozilla (missing menus, personal toolbar empty,etc). Downloadwith installs, but nothing happens, it's like it's not installed. Mailbutton only works in classic theme, it doesn't appear in moderm. Plus, some menus disappear. And, some themes I used to use make the personal toolbar empty... I guess, I'm just screwed, since there are no updated versions of this themes/extensions...

When I attempt to install the British English language pack, I get the message 'Out of space'. A similar problem arises when I attempt to install the relevant e-mail dictionary. Both of the above worked fine on older versions of SeaMonkey.