74690 - We shouldn't allow themes to be installed anywhere but the profile directory.

Status: RESOLVED WONTFIX

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Peter Lairo]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1), 2001-04-03

We shouldn't allow themes to be installed anywhere but the profile directory,
since the unistall of themes only works for that scenario.

BTW, how does one get rid of all the themes already installed into the install
directory - most themes currently install there?

Comment 1

[:deanis74]

Confirming, from bug 71194

Comment 2

[Boris Zbarsky [:bzbarsky]]

how do you tell whether it's a theme or just some random XPI file?

I think this should be an XPI installer bug....

Comment 3

[:deanis74]

Should anything get installed into the installation directory?  Probably program
updates and the sort, I guess.  I think this should be installer as well.

Comment 4

[akayser]

Currently it is not possible from an XPI file to correctly install
a theme in such a way that it is 'un-installable'. The current
xpi themes at x.themes.org (lopburi, decklin, alfred, graymodern) use an 
install script that can install in the profile directory. But this is
apparently not enough. Installing using the HTML javascript statements as
in themepark is (probably) not possible from XPI.

How to reproduce: install 'alfred' from x.themes.org. It arrives in the profile
directory, but still is not 'uninstallable'.

How to fix: make it possible to install from XPI in such a way that it can be
uninstalled: i.o.w.: make it possible to use the themepark javascript statements
from the install.js script in XPI.

Comment 5

[:deanis74]

I see that too.  Very interesting.  Alfred, can you add your comments to bug
71194, so that Hyatt sees them and hopefully can help out.

Comment 6

[Joe Hewitt (gone)]

this is an installer issue

Comment 7

[Daniel Veditz [:dveditz]]

Taking bug, you're talking about the engine not the Mozilla Installer.

XPInstall has no idea what it's installing so I don't see any way to enforce 
that themes should only go into the profile. You could put skins in the OS 
directory if you wrote an installer to do that. You could install a virus, too. 
Installing should not be taken lightly, which is why we discourage using it for 
themes in favor of the safer method used by Netscape's theme park.

Anyway, I just checked the Alfred theme, and although it will put the chrome 
physically in the profile directory it does not register it there, it still 
writes to the global all-skins.rdf -- you need to specify PROFILE_CHROME to 
write to the profile .rdf files

At the top you could put "var chrome_type = SKIN;" and then in the block for 
installing into the profile you could do "chrome_type |= PROFILE_CHROME;"

getFolder("Current User") is deprecated, getFolder("Profile") would be more 
future-proof.

Comment 8

[Alfred Kayser]

This one can be closed, skins are now installed from a .jar with some javescript:

function installMe(name,file,version) {
  InstallTrigger.installChrome(InstallTrigger.SKIN,file+'.jar',name+"/"+version)
}

So a long as themers do this, all is well.

A even better solution is to create a new mimetype able to install themes 
(eg .thi, like .xpi, triggers the theme install, instead of a xpi install)
This enables theme installation from javascript-less sites (hosted or javascript
haters).

Comment 9

[Daniel Veditz [:dveditz]]

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