Closed Bug 272764 Opened 20 years ago Closed 20 years ago

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

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: KKuhlemann, Assigned: dveditz)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file, 3 obsolete files)

patch 4
1.53 KB, patch
Details | Diff | Splinter Review 
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.
Keywords: regression
Version: unspecified → Trunk
I see this also. With the same description.

*** This bug has been marked as a duplicate of 272688 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Keywords: crash
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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.
Keywords: crash
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This might be because bug 266554 didn't land on the trunk yet, but the aviary
xpinstall changes refering to it did.
Assignee: xpi-packages → dveditz
Severity: critical → blocker
Depends on: 266554
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. ***
Summary: Mozilla is unable to open .xpi files → Mozilla is unable to open .xpi files (Theme/Extension/Language pack installation fails/is broken)
*** 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: ?
OS: Windows 2000 → All
Flags: blocking1.8a6?
Flags: blocking1.8a6? → blocking1.8a6+
KKuhlemann@t-online.de:

Drivers have advised me that you don't have permission to set a Blocking Flag to
"+", thus resetting to "?".
Flags: blocking1.8a6+ → blocking1.8a6?
Also happening on Linux:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041208
Flags: blocking1.8a6? → blocking1.8a6+
status update: I have been working on this, got stuck in aviary->trunk merge
hell on some other bugs.
Status: NEW → ASSIGNED
Flags: blocking1.8a6+ → blocking1.8a6?
nscizor: mkaply (driver) had already set the blocking+ bit: why on earth are you
downgrading it?
Don't remove (driver only) blocking (-/+) flags...
Flags: blocking1.8a6? → blocking1.8a6+
(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 ;)
Hardware: PC → All
*** 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.
Keywords: aviary-landing
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?
Attachment #169705 - Flags: review?(dveditz)
(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",  "");
Attached patch revised patch (obsolete) — — Splinter Review 
Took out the unused .progress and .type prefs, changed accidental
"blacklist.required" to the correct "whitelist.required"
Attachment #169705 - Attachment is obsolete: true
Attachment #169706 - Flags: review?(dveditz)
Comment on attachment 169706 [details] [diff] [review]
revised patch

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

is this really a string pref?
Attached patch patch v3 (obsolete) — — Splinter Review 
(In reply to comment #61)
> is this really a string pref?

Oops, of course not. Thanks!
Attachment #169706 - Attachment is obsolete: true
Attachment #169760 - Flags: review?(dveditz)
Attachment #169705 - Flags: review?(dveditz)
Attachment #169706 - Flags: review?(dveditz)
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.
Blocks: 270170
(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
Attachment #169760 - Flags: superreview+
Attachment #169760 - Flags: review?(dveditz)
Attachment #169760 - Flags: review+
(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)
No longer depends on: 266554
Attached patch patch 4 — — Splinter Review 
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.
Attachment #169760 - Attachment is obsolete: true
Attachment #170324 - Flags: superreview?
Attachment #170324 - Flags: review?
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
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 this stuff is covered by bug 273423
Blocks: 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)
Keywords: aviary-landing
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...
Attachment #170324 - Flags: superreview?
Attachment #170324 - Flags: review?
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.
Component: Installer: XPI Packages → Installer
QA Contact: general
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: