172062 - chrome.rdf in user profile should use relative target to (theme).jar

Status: RESOLVED INVALID

(SeaMonkey :: UI Design, defect)

Description

[E.T.]

The chrome.rdf file in the user profile uses absolute paths to the theme's jar file, which means it is not cross-platform (see bug 7067) and that if a user moves his profile it will break. And belive me, it breaks really badly. On windows at least, it shows an alert where you can't see any content or close it  (except by killing mozilla) and sometimes (I've deleted my profile file by file to see that was causing this so I saw this many times) even opens an infinite amount of windows (not really true, only placeholders in the wndows bar as far as I can tell...) untill you kill it. This should be considered another bug on it's own: Mozilla should not behave that badly when something is wrong with a profile!! It sometimes also sucess in giving an error which is in no way helpfull to the user: "no xbl binding for browser". Searching the web for a fix, I saw in forums that some people deleted their whole profile because of this, not knowing what else do, so this could be considered indirect dataloss and should be taken seriously. I had a backup that I restored after finding it was the chrome.rdf file that was wrong (and already knew how to fix the e-mail issues again because of absolute paths in prefs.js), but not many users will know that. And I'm sure this affects Netscape, Beonex, etc. too, so don't start saying Mozilla is not ment for us...

Now that bug 12911 implemented the underling code for relative paths it should be possible to fix this quickly, especially considering that it seems there is partial patch for the mail paths in bug 137006 which could give inspiration on this one too. I mean the theme is in the same directory as the chrome.rdf file, what's the need for a full path ?!?

To reproduce: install a third party theme, move your profile directory, use profile manager to tell Mozilla where to get it and launch the profile.

P.S.: forgive the spelling, I'm no native speaker and I re-installed Moz in trying to debug this and now it seems that download.mozdev.org is down so I can't get the spellcheaker back ;(

Comment 1

[Michael Lefevre]

for readability, here is the original report with linebreaks:

The chrome.rdf file in the user profile uses absolute paths to the theme's jar
file, which means it is not cross-platform (see bug 7067) and that if a user
moves his profile it will break. And belive me, it breaks really badly. On
windows at least, it shows an alert where you can't see any content or close it
 (except by killing mozilla) and sometimes (I've deleted my profile file by file
to see that was causing this so I saw this many times) even opens an infinite
amount of windows (not really true, only placeholders in the wndows bar as far
as I can tell...) untill you kill it. This should be considered another bug on
it's own: Mozilla should not behave that badly when something is wrong with a
profile!! It sometimes also sucess in giving an error which is in no way
helpfull to the user: "no xbl binding for browser". Searching the web for a fix,
I saw in forums that some people deleted their whole profile because of this,
not knowing what else do, so this could be considered indirect dataloss and
should be taken seriously. I had a backup that I restored after finding it was
the chrome.rdf file that was wrong (and already knew how to fix the e-mail
issues again because of absolute paths in prefs.js), but not many users will
know that. And I'm sure this affects Netscape, Beonex, etc. too, so don't start
saying Mozilla is not ment for us...

Now that bug 12911 implemented the underling code for relative paths it should
be possible to fix this quickly, especially considering that it seems there is
partial patch for the mail paths in bug 137006 which could give inspiration on
this one too. I mean the theme is in the same directory as the chrome.rdf file,
what's the need for a full path ?!?

To reproduce: install a third party theme, move your profile directory, use
profile manager to tell Mozilla where to get it and launch the profile.

==

I don't see any full paths in my chrome.rdf, but then I'm using a default theme.
  this certainly isn't a major or dataloss issue - users should not be messing
with their profiles, if they do, it's their own problem. however, if this is
easy and it improves things, maybe it's worth doing. reporter: has the situation
changed since this report was filed or is this still an issue?

Comment 2

[Conrad Carlen (not reading bugmail)]

Gee, I'm glad this bug exists - I meant to file just the same bug ;-) This
situation has changed lately. See bug 181641. That fixed the problem of flat-out
failure to launch when an invalid (moved, different platform, etc) file:// URL
exists in your <profile>chrome.rdf. This bug, though, points out the underlying
cause of that problem and I think this should be done. It's not a profile-mgr
bug, though. I'm not exactly sure who writes this file:// URL. chrome reg?
xpinstall?

> I don't see any full paths in my chrome.rdf, but then I'm using a default theme.

It only happens when you install a 3rd-party skin in your profile directory.

Comment 3

[OstGote!]

there is now a Firefox bug about this: Bug 246209

Comment 4

[Andrew Schultz]

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

Comment 5

[Benjamin Smedberg]

This has been fixed for the new toolkit (which doesn't use chrome.rdf any more),
it's only a problem in the Suite.

Comment 6

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 7

[Stefan [:stefanh]]

--> not a bug, since SeaMonkey doesn't use chrome.rdf anymore.