Skins (was: Re: Porting Modal UI to upstream)

Gervase Markham gerv at
Tue Dec 29 11:52:10 UTC 2015

On 24/12/15 17:33, Dylan Hardison wrote:
> Bug Modal specifically does not work with non-Mozilla (e.g. Sandstone) skins,
> and when you force it to (which I have done) it looks bad. So on top
> of this work, I've applied Ryan Wilson's Sandstone patch.

Before we do a bunch of what may be unnecessary or wrongly-directed work
here, we need to develop a skin strategy. This has come up in a few

Currently, Bugzilla ships with two skins - Classic and Dusk.

Users have the ability to choose the skin on a per-user basis. This
means that unless admins have changed Bugzilla to stop users using that
pref, any customizations admins do must be checked with both skins.

Skins, AIUI, do not generally provide additional functionality. They
just look different. I was to suggest that the high cost to us as
Bugzilla developers and to admins of maintaining multiple skins is not
worth it for the user value this generates.

I think we should:

* Keep a skins system
* Ship a single skin
* Remove the user preference for selecting a skin
* Add an admin param to define the skin on a per-installation basis

This preserves UI customizability for admins who want to make Bugzilla
fit in with their environment, but removes the maintenance and
customization burdens for us and for admins who are personally happy
with the default.

So if that logic seems good, which skin should we ship?

1) Dusk. This ships in the contrib directory, and yet became the default
for new installations in bug 259723, nine years ago.

2) Classic. This ships in the "standard" skin location but has not been
the default for a very long time.

3) Sandstone (Mozilla's skin; see )

Classic seems obviously wrong - we moved to Dusk 9 years ago, why go

Remember, we can take a skin and change the colours very easily. We
could ship a Sandstone which looks quite a bit like Dusk; there's no
need to keep the Sandstone colour.


More information about the developers mailing list