191957 - replacement for unavailable skin components chosen in fragile way

Status: RESOLVED WONTFIX

(Core Graveyard :: Skinability, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

DESCRIPTION:  When the skin selected in a profile is not available because the
user is using a build in which it is not installed / with which it is not
compatible, the replacement skin package used is chosen in the fragile way that
caused bug 180984.  The selection added in bug 180984 makes no difference for
this replacement.

Steps to reproduce [must repeat twice, once with NEW=1.2.1, and once with
NEW=current trunk build]:
 1. install 1.0.2 and NEW
 2. Create a fresh profile using 1.0.2, install the LittleMozillaTheme from
http://themes.mozdev.org/themes/littlemozilla.html using the link
javascript:doXPIInstall('http://mozdev.mirrors.nyphp.org/themes/themes/littlemozilla_10.xpi');
 3. switch that fresh profile to LittleMozilla
 4. restart 1.0.2 using this same profile
 5. start NEW using this same profile

After step (5), if NEW=1.2.1, then the build appears in Classic, and the
substitutions in chrome.rdf described in bug 191954 are filling in classic.
However, if NEW=current trunk, then the build appears in Modern, and the
substitutions are filling in modern.

The difference between 1.2.1 and the current trunk that causes this difference
is presumably whatever the change in the removal of XBL form controls that
triggered bug 180984.

This backup should be chosen in a controllable manner, so that it can be set to
classic for Mozilla builds (and presumably modern for Netscape builds).

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(See bug 191887 comment 2 for a way to reproduce "clodern" of which this bug is
part of the cause.)

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This seems to be done in whatever random order nsChromeRegistry::FindProvider
does things in.

Comment 3

[Robert Kaiser]

IMO, this boils down to a thing I haven't been sure about for a long time now:
How do we state a default theme/locale for a package? We should fall back to
that default, but what we see as the default is quite fragile - and we should
have some better mechanism for chosing that, IMO...

Comment 4

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]