163489 - [RFE] Need to notify user that theme is broken

Status: RESOLVED EXPIRED

(SeaMonkey :: Themes, enhancement)

Description

[Jerry Baker]

Currently, if you are using a third party theme for Mozilla, and you download a
nightly that has broken third party themes (bug 162891) Mozilla just stops
working properly without any indication as to why this is happening.

This happened to me coincidentally at the same time that I had moved my Mozilla
installation directory. I thought Mozilla had screwed up my profile and spent
some time trying to correct that. I thought I had lost my profile. I am not a
new Mozilla user, and I understand most of its quiks and behaviors. This kind of
thing is going to affect the less computer literate much more severely.

Is there some way that Mozilla can have a way to check if a theme should work
with the current build? I was thinking of keeping some sort of independent
version number in a file that Mozilla can read when applying a theme. Everytime
something is changed that will break current third party themes, this version
number would be incremented. That way Mozilla will not allow you to continue to
use themes that will not work.

Comment 1

[James Rome]

I filed a similar bug on this a long while ago stating that theme maintainers be
notified when changes are made that cause themes to break. The 8/28 Linux build
will not open the mail/news window with other than the default theme. 

Changes that break themes should not be put into the builds until the theme
maintainers have been notified and have had some time (a week?) to fix the themes.

And the theme installs still do not work properly, namely the "use this theme"
box is ignored. Unless the user goes into preferences and sets it, the nowly
downloaded "default" theme is not used.

Comment 2

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 3

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420