272764 - Mozilla is unable to open .xpi files (Theme/Extension/Language pack installation fails/is broken)

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Klaus P. Kuhlemann]

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.

Comment 1

[James Rome]

I see this also. With the same description.

Comment 2

[Oliver Klee]

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

Comment 3

[Klaus P. Kuhlemann]

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.

Comment 4

[R.K.Aa.]

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.

Comment 5

[Daniel Veditz [:dveditz]]

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

Comment 6

[Daniel Veditz [:dveditz]]

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

Comment 7

[James Rome]

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

Comment 8

[James Rome]

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

Comment 9

[HJ]

(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.

Comment 10

[HJ]

Ah, I found bug 264560, interesting...

Comment 11

[OstGote!]

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

Comment 12

[WADA:World Anti-bad-Duping Agency]

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

Comment 13

[Artur Polaczynski]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041207

OS: ALL +
Bloking1.8a6: ?

Comment 14

[David G King]

[e-mail]:

Drivers have advised me that you don't have permission to set a Blocking Flag to
"+", thus resetting to "?".

Comment 15

[John Griffiths]

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

Comment 16

[Daniel Veditz [:dveditz]]

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

Comment 17

[Giacomo Magnini]

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

Comment 18

[HJ]

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

Comment 19

[Dimosthenis Stamatiou]

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

Sorry

Comment 20

[James Ross]

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. ;)

Comment 21

[HJ]

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

Comment 22

[HJ]

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 ;)

Comment 23

[WADA:World Anti-bad-Duping Agency]

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

Comment 24

[Alex Vincent [:WeirdAl]]

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

Comment 25

[Alex Vincent [:WeirdAl]]

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.

Comment 26

[Alex Vincent [:WeirdAl]]

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

Comment 27

[Alex Vincent [:WeirdAl]]

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?

Comment 28

[Alex Vincent [:WeirdAl]]

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.

Comment 29

[Klaus P. Kuhlemann]

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.  

Comment 30

[Ian Neal]

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

Comment 31

[HJ]

(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?

Comment 32

[Ian Neal]

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

Comment 33

[Jason Bassford]

> 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.

Comment 34

[HJ]

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 :-)

Comment 35

[HJ]

(In reply to comment #34)

Oops, don not add the " "); junk left in from my .js file ;)

Comment 36

[HJ]

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

Comment 37

[HJ]

(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...

Comment 38

[Chris Siebenmann]

 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.)

Comment 39

[Jason Bassford]

> (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.

Comment 40

[HJ]

(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!

Comment 41

[HJ]

(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...

Comment 42

[Eyal Rozenberg]

(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.

Comment 43

[HJ]

(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!

Comment 44

[Tom Kloos]

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.

Comment 45

[James R. Thomsen]

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.

Comment 46

[James Rome]

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

Comment 47

[HJ]

(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?

Comment 48

[James R. Thomsen]

(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.
 

Comment 49

[Eyal Rozenberg]

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.

Comment 50

[Alex Vincent [:WeirdAl]]

(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?

Comment 51

[Jens Hatlak (:InvisibleSmiley)]

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.

Comment 52

[Klaus P. Kuhlemann]

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.  

Comment 53

[Jens Bannmann]

(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.

Comment 54

[Klaus P. Kuhlemann]

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. 

Comment 55

[HJ]

(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...

Comment 56

[Jens Hatlak (:InvisibleSmiley)]

(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.

Comment 57

[Jens Bannmann]

Attachment: 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?

Comment 58

[HJ]

(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

Comment 59

[Karsten Düsterloh]

>  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",  "");

Comment 60

[Jens Bannmann]

Attachment: revised patch

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

Comment 61

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 169706 [details] [diff] [review]
revised patch

+pref("xpinstall.whitelist.required", "false");

is this really a string pref?

Comment 62

[Jens Bannmann]

Attachment: patch v3

(In reply to comment #61)
> is this really a string pref?

Oops, of course not. Thanks!

Comment 63

[HJ]

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

Comment 64

[HJ]

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...

Comment 65

[Ian Neal]

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.

Comment 66

[Robert Kaiser]

(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 67

[[e-mail]]

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.

Comment 68

[HJ]

(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 

Comment 69

[Ian Neal]

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

Comment 70

[[e-mail]]

(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?

Comment 71

[HJ]

(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.

Comment 72

[Alexander Doborshhuk]

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
-

Comment 73

[Ian Neal]

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?

Comment 74

[OstGote!]

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

Comment 75

[Alexander Doborshhuk]

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 76

[Daniel Veditz [:dveditz]]

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

Comment 77

[HJ]

(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?

Comment 78

[HJ]

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

Comment 79

[Daniel Veditz [:dveditz]]

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)

Comment 80

[Daniel Veditz [:dveditz]]

Attachment: patch 4

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.

Comment 81

[Daniel Veditz [:dveditz]]

Fix checked in.

Comment 82

[HJ]

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?

Comment 83

[Robert Kaiser]

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)

Comment 84

[Jens Bannmann]

(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...

Comment 85

[Michael Lefevre]

"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.

Comment 86

[Robert Kaiser]

(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.

Comment 87

[James Rome]

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.

Comment 88

[Alexander Doborshhuk]

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

Comment 89

[Bill Gianopoulos [:WG9s]]

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

Comment 90

[HJ]

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"

Comment 91

[Ian Neal]

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

Comment 92

[Boris Zbarsky [:bzbarsky]]

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.

Comment 93

[timeless]

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

Comment 94

[timeless]

fwiw this stuff is covered by bug 273423

Comment 95

[sairuh (rarely reading bugmail)]

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

Comment 96

[David E. Ross]

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.  

Comment 97

[Jorge Vidal Wulff]

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!

Comment 98

[Robert Kaiser]

(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.

Comment 99

[HJ]

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. 

Comment 100

[Kurt Pruenner]

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)

Comment 101

[Jorge Vidal Wulff]

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.

Comment 102

[Jens Hatlak (:InvisibleSmiley)]

(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.

Comment 103

[Jorge Vidal Wulff]

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"?????

Comment 104

[Ian Neal]

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.

Comment 105

[Jason Bassford]

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.

Comment 106

[Jorge Vidal Wulff]

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.

Comment 107

[HJ]

(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 ;)

Comment 108

[Jorge Vidal Wulff]

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

Comment 109

[Jorge Vidal Wulff]

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...

Comment 110

[André]

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.