Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Please make themes compatible by default as well

147 views
Skip to first unread message

solc...@live.com

unread,
Nov 17, 2011, 2:15:05 AM11/17/11
to
Bug #693901 introduces a boolean pref to make addons compatible-by-default. However, its functionality currently does not extend to themes by design, with the rationale being that: "Because of the way themes currently work, they are more susceptible to breakage due to changes in the application. Given that each new application version will involve some change in the UI, themes that haven't been updated are very likely to have *something* broken." (quoted from https://bugzilla.mozilla.org/show_bug.cgi?id=698653#c7)

To gather some data regarding this issue, I visited the Most Popular Themes page on AMO (https://addons.mozilla.org/en-US/firefox/themes/?sort=users) using Nightly on Win7 and installed every theme on the first page that was marked as compatible with Firefox 8 but not with Nightly. These themes are:

Blue Fox - http://i42.tinypic.com/b698nm.png
FT Deepdark - http://i44.tinypic.com/2wejq07.png
FXChrome - http://i44.tinypic.com/sg1sgm.png
Noia 4 - http://i44.tinypic.com/2wgdd2v.png
Office Black - http://i44.tinypic.com/105y4hw.png
Silvermel - http://i40.tinypic.com/f1wj04.png
SmallringFX DARKBlue - http://i39.tinypic.com/n3mcmo.png
Walnut - http://i39.tinypic.com/w9tqq9.png

A few of the themes look slightly broken, but the same breakage existed when I installed them in Firefox 8. As far as I could tell, the above themes all appeared identical in Nightly as in Firefox 8, at least as far as the main UI is concerned. I didn't test every single aspect of the themes, nor was this meant to be some sort of comprehensive or representative test, but hopefully someone who has the data or the means to obtain them will chime in.

My opinion is that Bug #693901 should apply to themes as well. Compat-by-default addons will solve a major gripe that I have seen expressed by users on tech sites: Firefox updates break addons. This grouse is unlikely to go away, and will possibly increase in magnitude due to frustration from dashed expectations, if #693901 does not apply to themes. The wiki page for CBD addons (https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible) claims that Firefox will check AMO metadata as part of the process to determine if an addon should be CBD, among others. I'm not aware if there are any considerable technical barriers in doing so, but it sounds as though the same checking mechanisms can and should be applied to themes as well to prevent truly incompatible themes from reaching users.

Gervase Markham

unread,
Nov 17, 2011, 5:23:15 AM11/17/11
to
On 17/11/11 07:15, solc...@live.com wrote:
> A few of the themes look slightly broken, but the same breakage
> existed when I installed them in Firefox 8. As far as I could tell,
> the above themes all appeared identical in Nightly as in Firefox 8,
> at least as far as the main UI is concerned. I didn't test every
> single aspect of the themes, nor was this meant to be some sort of
> comprehensive or representative test, but hopefully someone who has
> the data or the means to obtain them will chime in.

Hi solcroft,

Thank you for backing up your suggestion with data rather than just
opinion :-) It seems to me that you have all that you need to gather the
extra data necessary. A good test might be:

- Find the 5 or 10 most popular themes.
- Find the first version of each which is marked as compatible with
Release N
- Hack it's maxversion and install it on release N+1
- See whether anything breaks

Where the releases concerned are all rapid releases (i.e. 6, 7, 8).

If you find that 95% of the time, nothing breaks, then that would be
good data in support of your suggestion.

Gerv

Peter Lairo

unread,
Nov 17, 2011, 6:51:38 AM11/17/11
to
How is that any different or better than the work and research he has
already done?

- He has looked at the 8 most popular themes.

- Are the maxversion of the themes on the page he tested significantly
different when visiting the page with a trunk build than those one would
be presented with when visiting that page with a release version of Fx?

- Trunk builds are n+1 or even n+2.
--
Regards,
Peter Lairo

Bugs I think are important:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
https://bugzilla.mozilla.org/show_bug.cgi?id=436259
https://bugzilla.mozilla.org/show_bug.cgi?id=446444

Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis

Dao

unread,
Nov 17, 2011, 2:03:02 PM11/17/11
to
On 17.11.2011 12:51, Peter Lairo wrote:
> How is that any different or better than the work and research he has
> already done?

It's different in that he only said: "the above themes all appeared
identical in Nightly as in Firefox 8, at least as far as the main UI is
concerned. I didn't test every single aspect of the themes" -- which is
obviously a far cry from "nothing breaks."

Ron Hunter

unread,
Nov 17, 2011, 5:00:39 PM11/17/11
to
I would expect that since themes have MANY contact points with a given
versions features, and UI, they would be much more likely to be broken
for each new release than extensions, which may have only one or a few
contact points. It may be that the only breakage is in something
subtle, or that a given user may never access, but it is still broken.
Testing this would be rather labor intensive.

Gervase Markham

unread,
Nov 18, 2011, 5:37:24 AM11/18/11
to
On 17/11/11 22:00, Ron Hunter wrote:
> I would expect that since themes have MANY contact points with a given
> versions features, and UI, they would be much more likely to be broken
> for each new release than extensions, which may have only one or a few
> contact points.

Without meaning to be rude, this is entirely the opposite of the
approach I commended in solcroft. This is opinion without data. We can
all guess at what we think would happen, but it's much better to test
and see.

Gerv

Robert Kaiser

unread,
Nov 18, 2011, 11:22:33 AM11/18/11
to
Gervase Markham schrieb:
> Thank you for backing up your suggestion with data rather than just
> opinion :-) It seems to me that you have all that you need to gather the
> extra data necessary.

I'll state without doing the research across other people's work that in
my EarlyBlue (SeaMonkey) and LCARStrek (SeaMonkey+Firefox) themes
compatibility with stuff used often enough _can_ break from version to
version but it rarely does. I'm using Nightly with LCARStrek on the
state of Firefox 8 right now, and even when it was at the state of 7 I
didn't see anything really broken, most changes just make things look
better, more in line with the overall theme, etc. Sometimes feature
changes like the new default favicon are only applied when the
respective theme change is done, but nothing really breaks without it.
There have been cases where a larger change messed up stuff to a large
degree but since we started the rapid release cycle, I have not yet seen
anything major there, and I have been using LCARStrek at the state of
release with Nightly all the time, i.e. being "3 versions behind".

I'm not sure if that's enough to warrant defaulting to compatible, but
so far it has worked out fine in this specific case. We'd need to look
at other themes more closely to see how they fare.

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

Ron Hunter

unread,
Nov 18, 2011, 11:57:58 AM11/18/11
to
I have no objection to the idea of testing, but abandoning simple logic
isn't indicated either. It is usually a good indication of what to
expect from test results. Part of the 'scientific method' is hypothesis.

solc...@live.com

unread,
Nov 18, 2011, 12:07:37 PM11/18/11
to
I've spent the last two days testing the first 4 themes I listed.

As mentioned by another poster, themes have a huge amount of contact points, and I can't say with certainty that "95% of the time nothing breaks". What I can say is I spent ~20 minutes on each theme flipping through every part of the Firefox UI I could think of, and I can observe no difference between Nightly and Firefox 8 on all 4 of them.

My main Nightly profile has the Australis theme by SoapyHamHocks installed, and since I use it heavily on a daily basis I can vouch for that theme being quite compatible with Nightly as well.

Another thing I'm interested in here is the decision made by the devs regarding bug 693901. Is there data to indicate that applying the pref for themes as well is a bad idea, and that this cannot be mitigated by the failsafe mechanisms that will be used to weed out truly incompatible extensions?

Christian Legnitto

unread,
Nov 18, 2011, 12:32:35 PM11/18/11
to mozilla.dev....@googlegroups.com, dev-apps...@lists.mozilla.org
Thanks for the testing!

Would our automated tests still work with themes installed? If so, let's slap some on the test machines and see if any tests break.

Thanks,
Christian
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

Robert Kaiser

unread,
Nov 18, 2011, 1:25:35 PM11/18/11
to
Christian Legnitto schrieb:
> Would our automated tests still work with themes installed? If so, let's slap some on the test machines and see if any tests break.

I'mm pretty sure that most tests are not affected in any kind by themes,
as we don't test how things look. And if they do, switching to the other
theme is probably what breaks stuff, and not switching different
versions of Firefox with the same theme.

I don't think we can reasonably test this automatically. Breakages with
incompatible themes are usually in the form of "this doesn't really look
right" or "this is not well-readable". Things like that are almost
impossible to catch with automated tests.

Dao

unread,
Nov 18, 2011, 2:32:45 PM11/18/11
to
On 18.11.2011 17:22, Robert Kaiser wrote:
> There have been cases where a larger change messed up stuff to a large
> degree but since we started the rapid release cycle, I have not yet seen
> anything major there

The add-on selection UI in Firefox 8 and various new developer tools
come to mind. Whenever we add or significantly modify some UI, themes
need to be updated, as long as we care about delivering a complete product.

A single user is never going to touch all aspects of Firefox, so "I've
been using ... and it seemed to work fine" is not really useful data, sorry.

Robert Kaiser

unread,
Nov 20, 2011, 10:37:32 AM11/20/11
to
Dao schrieb:
> On 18.11.2011 17:22, Robert Kaiser wrote:
>> There have been cases where a larger change messed up stuff to a large
>> degree but since we started the rapid release cycle, I have not yet seen
>> anything major there
>
> The add-on selection UI in Firefox 8 and various new developer tools
> come to mind.

The developer tools behave reasonably from what I saw, while not
perfect. The add-on selection UI is shown before a theme can be loaded
anyhow (AFAIK) and therefore should not be affected at all. Also, it
doesn't need much special theming at all, just like a lot of other
stuff. In most cases, the theme files are just needed to make things
look really right, but things usually work reasonably once the global
widgetry theming is solid in your theme.

> A single user is never going to touch all aspects of Firefox, so "I've
> been using ... and it seemed to work fine" is not really useful data,
> sorry.

I'm trying lots of different new stuff because I know it's there and I
want to see how it acts with my theme, of course.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,

Justin Dolske

unread,
Nov 20, 2011, 1:43:48 PM11/20/11
to
On 11/16/11 11:15 PM, solc...@live.com wrote:
> Given that each new
> application version will involve some change in the UI, themes that
> haven't been updated are very likely to have *something* broken."
> (quoted from https://bugzilla.mozilla.org/show_bug.cgi?id=698653#c7)

It's not an unreasonable starting point, if for no other reason than
there's been little effort to preserve theme compatibility across
releases, or to build the UI in ways that minimize risk of theme breakage.


> To gather some data regarding this issue, I visited the Most Popular
> Themes page on AMO [...]

A few problems and nitpicks:

* Nightly has only had 12 days of development since the last Aurora
uplift, so you're effectively missing most of the 6-week development
cycle. (i.e., Nightly and Aurora are effectively the same still).

* All but 3 (BlueFox, OfficeBlack, Smallring) are actively maintained
and explicitly compatible with Firefox 10 (which, as I just noted, is
basically the same as Firefox 11 right now). Testing such addons doesn't
say much about the risks of compatible-by-default.

* As we've found with many parts of the Mozilla ecosystem (including
extension compatibility), the long tail matters too. I'd have to check,
but I'd be surprised if we've shipped a release since Firefox 3 that
didn't have the Top-10 addons all compatible on release day. Recent
Firefox releases have shipped with 97+% of AMO addons compatible on
release day. So clearly that's not enough. :)


> I didn't test every
> single aspect of the themes, nor was this meant to be some sort of
> comprehensive or representative test, but hopefully someone who has
> the data or the means to obtain them will chime in.

Understandable, but that's an important part of determining if they're
really compatible. Primary UI for the main window is certainly
important, but so are functional video controls, door hangers, menus,
prompts, other windows (Places, Downloads, Dev Tools), etc etc etc.


> Compat-by-default addons will solve a major gripe that I have seen
> expressed by users on tech sites: Firefox updates break addons. This
> grouse is unlikely to go away, and will possibly increase in
> magnitude due to frustration from dashed expectations, if #693901
> does not apply to themes.

I don't agree. All the grumbling about addons that I've seen has been
about extensions, not themes. Which isn't surprising, given that
something like ~80% of users have 1 or more extensions, whereas < 2%
have a theme installed.

Justin

Henri Sivonen

unread,
Nov 21, 2011, 2:12:31 AM11/21/11
to dev-apps...@lists.mozilla.org
On Sun, Nov 20, 2011 at 8:43 PM, Justin Dolske <dol...@mozilla.com> wrote:
> I don't agree. All the grumbling about addons that I've seen has been about
> extensions, not themes. Which isn't surprising, given that something like
> ~80% of users have 1 or more extensions, whereas < 2% have a theme
> installed.

Flipping this around, doesn't that mean that the expected breakage
from making themes compatible by default would be very, very small:
peripheral parts of the UI for < 2% of the users.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Dao

unread,
Nov 21, 2011, 2:59:56 AM11/21/11
to
On 20.11.2011 16:37, Robert Kaiser wrote:
> Dao schrieb:
>> On 18.11.2011 17:22, Robert Kaiser wrote:
>>> There have been cases where a larger change messed up stuff to a large
>>> degree but since we started the rapid release cycle, I have not yet seen
>>> anything major there
>>
>> The add-on selection UI in Firefox 8 and various new developer tools
>> come to mind.
>
> The developer tools behave reasonably from what I saw, while not
> perfect.

Remove csshtmltree.css, then: right-click on a page -> Inspect Element
-> Style -> Properties.

> The add-on selection UI is shown before a theme can be loaded
> anyhow (AFAIK) and therefore should not be affected at all.

Maybe in this particular case, I haven't checked. The point is that we
often enough add UI and usually this needs theme updates.

> Also, it doesn't need much special theming at all,

Have you checked this? I'm pretty sure it's wrong.

Justin Wood (Callek)

unread,
Nov 21, 2011, 4:24:20 AM11/21/11
to Henri Sivonen
Henri Sivonen wrote:
> On Sun, Nov 20, 2011 at 8:43 PM, Justin Dolske<dol...@mozilla.com> wrote:
>> I don't agree. All the grumbling about addons that I've seen has been about
>> extensions, not themes. Which isn't surprising, given that something like
>> ~80% of users have 1 or more extensions, whereas< 2% have a theme
>> installed.
>
> Flipping this around, doesn't that mean that the expected breakage
> from making themes compatible by default would be very, very small:
> peripheral parts of the UI for< 2% of the users.
>

2% of users is still a large number.

We've done chemspills for issues that affect just that number of people.

--
~Justin Wood (Callek)

Dao

unread,
Nov 21, 2011, 5:59:38 AM11/21/11
to
On 21.11.2011 08:12, Henri Sivonen wrote:
> On Sun, Nov 20, 2011 at 8:43 PM, Justin Dolske<dol...@mozilla.com> wrote:
>> I don't agree. All the grumbling about addons that I've seen has been about
>> extensions, not themes. Which isn't surprising, given that something like
>> ~80% of users have 1 or more extensions, whereas< 2% have a theme
>> installed.
>
> Flipping this around, doesn't that mean that the expected breakage
> from making themes compatible by default would be very, very small:
> peripheral parts of the UI for< 2% of the users.

Breakage doesn't become desirable when it affects a limited number of
people. People switching to updated themes or the default theme seems
preferable over them switching browsers when Firefox becomes more and
more unpolished and partly broken with every release.

"peripheral parts of the UI" is misleading. It's random parts of the UI,
whatever we happen to touch in a given release.

Robert Kaiser

unread,
Nov 21, 2011, 8:50:22 AM11/21/11
to
Dao schrieb:
> On 20.11.2011 16:37, Robert Kaiser wrote:
>> Also, it doesn't need much special theming at all,
>
> Have you checked this? I'm pretty sure it's wrong.

I'm writing out of the memory of actually doing the theming. I'd argue
themes are not really worse off than other add-ons. But then, I'm
keeping my themes fairly up to date anyhow and adjust the versions, so I
don't really care if they are marked compatible by default.
In fact, I was never a big friend of automatic compatible by default anyhow.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the

Robert Kaiser

unread,
Nov 21, 2011, 8:51:40 AM11/21/11
to
Henri Sivonen schrieb:
> On Sun, Nov 20, 2011 at 8:43 PM, Justin Dolske<dol...@mozilla.com> wrote:
>> I don't agree. All the grumbling about addons that I've seen has been about
>> extensions, not themes. Which isn't surprising, given that something like
>> ~80% of users have 1 or more extensions, whereas< 2% have a theme
>> installed.
>
> Flipping this around, doesn't that mean that the expected breakage
> from making themes compatible by default would be very, very small:
> peripheral parts of the UI for< 2% of the users.

Also note that we expect that e.g. developer tools are used by roughly
2% of our users and we put a lot of work into them. Whatever that means
in comparison. ;-)

Ron Hunter

unread,
Nov 21, 2011, 10:51:56 AM11/21/11
to
Theme breakages don't affect security, or cause data loss, so the impact
isn't as serious. They also tend to be in rather isolated areas, such
as new UI features/options added may not appear, or may not look just
right. Worst case, the user just switches back to default theme.

Dao

unread,
Nov 21, 2011, 11:32:10 AM11/21/11
to
On 21.11.2011 16:51, Ron Hunter wrote:
> Theme breakages don't affect security, or cause data loss, so the impact
> isn't as serious.

It can easily affect such areas, namely if and when we implement some
new UI there. E.g. if the identity box color was missing or some data
migration wizard rendered incorrectly, I'd consider this serious.

> They also tend to be in rather isolated areas, such as
> new UI features/options added may not appear, or may not look just
> right. Worst case, the user just switches back to default theme.

No, worst case is users abandoning Firefox when it starts to look and
behave unexpectedly. People don't necessarily realize that add-ons could
be causing problems, let alone that disabling non-essential add-ons
would be the simplest solution; they may have forgotten that they have
random add-ons installed in the first place.

Robert Kaiser

unread,
Nov 21, 2011, 12:11:18 PM11/21/11
to
Dao schrieb:
> No, worst case is users abandoning Firefox when it starts to look and
> behave unexpectedly. People don't necessarily realize that add-ons could
> be causing problems, let alone that disabling non-essential add-ons
> would be the simplest solution; they may have forgotten that they have
> random add-ons installed in the first place.

By that argument, having any add-ons compatible by default is a bad
idea. We decided to go the other way, though, so I'd call your argument
not more valid for themes than "normal" add-ons.

Dao

unread,
Nov 21, 2011, 1:06:01 PM11/21/11
to
On 21.11.2011 18:11, Robert Kaiser wrote:
> Dao schrieb:
>> No, worst case is users abandoning Firefox when it starts to look and
>> behave unexpectedly. People don't necessarily realize that add-ons could
>> be causing problems, let alone that disabling non-essential add-ons
>> would be the simplest solution; they may have forgotten that they have
>> random add-ons installed in the first place.
>
> By that argument, having any add-ons compatible by default is a bad
> idea. We decided to go the other way, though, so I'd call your argument
> not more valid for themes than "normal" add-ons.

Sigh. No, it's not the same argument. Extensions hook into random parts
of our code base, most of which are stable enough such that most
extensions aren't affected by rapid releases. Themes written for older
versions are _guaranteed_ to become outdated and incomplete.

Robert Kaiser

unread,
Nov 22, 2011, 12:16:43 PM11/22/11
to
Dao schrieb:
Whatever. We both seem to not agree with the other in principle, so
there's no use in continuing this. Themes are probably on the way to
being dead anyhow, given that mobile is the future and we're using
non-themable UIs there now (and stuff like Windows 8 Metro might even
force us policy-wise to do the same on desktop at some point).

solc...@live.com

unread,
Nov 22, 2011, 2:05:04 PM11/22/11
to
On Tuesday, November 22, 2011 4:36:01 AM UTC+10:30, Dao wrote:
> Sigh. No, it's not the same argument. Extensions hook into random parts
> of our code base, most of which are stable enough such that most
> extensions aren't affected by rapid releases. Themes written for older
> versions are _guaranteed_ to become outdated and incomplete.

And your data to back up your claim would be?

Ron Hunter

unread,
Nov 22, 2011, 3:42:55 PM11/22/11
to
On 11/22/2011 11:16 AM, Robert Kaiser wrote:
> Dao schrieb:
>> On 21.11.2011 18:11, Robert Kaiser wrote:
>>> Dao schrieb:
>>>> No, worst case is users abandoning Firefox when it starts to look and
>>>> behave unexpectedly. People don't necessarily realize that add-ons
>>>> could
>>>> be causing problems, let alone that disabling non-essential add-ons
>>>> would be the simplest solution; they may have forgotten that they have
>>>> random add-ons installed in the first place.
>>>
>>> By that argument, having any add-ons compatible by default is a bad
>>> idea. We decided to go the other way, though, so I'd call your argument
>>> not more valid for themes than "normal" add-ons.
>>
>> Sigh. No, it's not the same argument. Extensions hook into random parts
>> of our code base, most of which are stable enough such that most
>> extensions aren't affected by rapid releases. Themes written for older
>> versions are _guaranteed_ to become outdated and incomplete.
>
> Whatever. We both seem to not agree with the other in principle, so
> there's no use in continuing this. Themes are probably on the way to
> being dead anyhow, given that mobile is the future and we're using
> non-themable UIs there now (and stuff like Windows 8 Metro might even
> force us policy-wise to do the same on desktop at some point).
>
> Robert Kaiser
>
If/when that happens, I certainly hope that whomever is designing
default themes notices COLOR. I really hate these colorless themes,
icons, etc.

0 new messages