64803 - Must not allow switching to "old" skin or locale

Status: VERIFIED DUPLICATE of bug 53670

(Core :: XUL, defect)

Description

[Daniel Veditz [:dveditz]]

As people upgrade to newer versions of Mozilla they may have outdated themes and
language packs that will not work with the new version.

It will be easy enough at install time to make sure we select the updated
default skin and locale, but the user may then try to switch back to the old
incompatible themes/languages.  The chrome system must instead prevent this,
probably presenting an alert to the user indicating the selected skin/locale is
out of date and that the user should update it from whereever it came from.
(There may be a URL associated with the skin/locale that we could offer to take
the user back to.)

We could perhaps use the general.useragent.misc pref (currently "m18") if it'll
stay used for the same thing.

Comment 1

[tao]

Should we inform the user of provider name change when that occurs during
installer session?

Comment 2

[Daniel Veditz [:dveditz]]

nominating nsbeta1

At a minimum skins and locales will have to be tagged with some sense of what
version they match (assume unmarked chrome is N6/mozilla0.6). This could be the
useragent.misc string, a Gecko pulldate minimum, or an abitrary "generation"
number built into the chrome registry.

Not sure how to deal with "future" skins breaking older products (i.e. a
Mozilla1.0 user trying to use a Mozilla1.2 skin) because we don't know in
advance how long a skin is likely to remain useful before some feature change
breaks it. The "m18" type string would be useful in this regard because we could
simply say it had to match, and older or newer skins were unacceptable. For
Mozilla daily build users sometimes skins break mid-milestone, though, and
sometimes much older skins would still work OK.

But not all mozilla-based chrome requires skins to match the version of the
browser itself. It's far more important that the skin for the ActiveState IDE
thingy match the version of the IDE than that it match the version of the
platform. It might theoretically be best if each chrome content package (global,
navigator, mail, etc) had some arbitrary version number that must be matched by
the skin/locale for that package. But this is probably a lot more work to
implement and slower to process in a global skin/locale switch if checking has
to be done for each package.

Comment 3

[tao]

Mozilla is more vulnerable to langpack changes. Any new entity or (key,value) pair
introduced in XUL, RDF, JS, C++ code has the potential of making Mozilla unusable.

Comment 4

[timeless]

yes. we really need a way to overlay dtd files.

so, for example, a lang pack could borrow from en-US until it was fixed.

As for |Must not allow| could we instead warn and then analyze:

+-------------------------+
| Version Mismatch        |
+-------------------------+
| Warning, this langpack  |
| may not work with this  |
| version of mozilla.     |
| <Test> <Ignore> <Abort> |
+-------------------------+
Test would go through all xul files in the affected packages and try to resolve 
them.  For any cases where it can't, it would log an error message.

Possible responses to failed resolutions include
file per file chrome path resolution (~Messenger.xul could not resolve using 
HE-il, reverting to EN-us~)

Package level (~Part of Messenger could not resolve using HE-il, reverting to 
EN-us~)

Patch level (~Messenger.xul could not completely resolve using HE-il, loading 
remaining entities from EN-us~)

<Ignore> might not even be an option.  And we could just implement these 
schemes w/o showing a dialog.  [Merely a pref for Package/File/Patch and an 
interface to select the main and default packages]

Comment 5

[Peter Trudelle]

->moz0.9

Comment 6

[David Hyatt]

This is a dup of 53670.


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

Comment 7

[Chad Austin]

invalids, wontfixes, dups, worksformes