"skin" vs. "content" stylesheets after Complete Theme removal (Fx57+)

Benjamin Smedberg benjamin at smedbergs.us
Thu Mar 23 20:44:39 UTC 2017

On Thu, Mar 16, 2017 at 7:48 PM, Matthew N. <MattN at mozilla.com> wrote:

> Once we remove complete themes in 57
> <https://wiki.mozilla.org/Add-ons/Themes/FAQ#What.E2.80.99s_going_to_happen_to_existing_themes.3F>
> I think this should change since the primary factor for the separation will
> be gone.

> I think the reasons are obvious (e.g. duplication of selectors between
> files, confusing for new contributors, etc.) so I won't go into those now.
> I think there are two high-level paths forward:
> A) Consolidate all styles in one package (I think it would be "content"
> but see discussion below¹)
> ** We can still use a preprocessor in CSS or in jar manifests to vary
> OS-specific styles

I support this model, and it dovetails with my desire to get rid of all the
skin-selection code in the chrome registry. I would like to end up in a
state where chrome://package/skin/ doesn't exist.

> ¹ The "content" package is chrome-privileged whereas the "skin" package
> isn't (even though they both use chrome URIs). The chrome privileges are
> sometimes necessary with our style to avoid cross-origin issues related to
> SVG and possibly other examples I don't know off-hand. Is there any
> practical security benefit to using "skin" for everything (if possible)?
> What do others think about changing/removing the "skin" vs. "content"
> distinction?
> I personally think (B) is simplest to transition to while still providing
> a clear separation for OS-specific styles so I lean towards it but if we
> can come up with a good convention for handling OS-specific styles with
> option (A) then that's also fine with me.

If it's possible to do this using CSS selectors optionally @importing
OS/OSversion specific stylesheets, I'd much prefer this version.

The reason we have in the past removed chrome privileges from skin packages
is so that Firefox themes can't pwn users (or can't pwn users as easily).
If it worked it would be a nice risk mitigation technique, but in practice
it doesn't work and so let's not worry about that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20170323/3134b7cb/attachment.html>

More information about the firefox-dev mailing list