Product plan: remove support for heavyweight themes

RESOLVED FIXED

Status

()

RESOLVED FIXED
3 years ago
10 months ago

People

(Reporter: benjamin, Assigned: kev)

Tracking

({addon-compat})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
As part of Firefox great-or-dead, we've decided to stop support for "heavyweight" themes which can do arbitrary styling and replace chrome packages.

We may simply remove that support completely, or we may extend lightweight themes with some additional features such as changing colors or icons.

This bug tracks creating a specific product plan for themes. Expected due date 1-Dec.
Comment hidden (advocacy)

Comment 2

3 years ago
Can't an add-on just inject CSS everywhere? Also, does that affect everything using the Mozilla platform or just Firefox? How can we rectify to people that Developer Edition has a completely different heavyweight theme still (though it's implemented in a very different and probably worse way) - or are we removing that as well? Will we still support following customizable OS themes, esp. on Linux, which has very flexible theming frameworks (like the one of GTK)?

All that said, it will be a very sad day for me when my Firefox will needs to start looking as ugly and boring as the default theme, and it fell stop to feel like "my" browser - but that may be just me.

Comment 3

3 years ago
[...As part of Firefox great-or-dead, we've decided to stop support for "heavyweight" themes which can do arbitrary styling and replace chrome packages...]

"heavyweight" themes which can do arbitrary styling and replace chrome packages sounds great, who has decided that this GREAT feature is not great enough?

I mean for now advanced users can use extensions to add back the missing functionality but some of this capabilities will be removed too with webextensions.

I will like to add some words for the great-or-dead philosophy:
Even if a feature is not great enough most time some features are better than no features, this path could end with firefox being a worse version of *cough* another browser.

PS. I'm not trying to disrespect anybody by saying this I'm just concerned about the future of firefox.

Comment 4

3 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #0)
> As part of Firefox great-or-dead

Removing features that make Firefox unique for sake of making Firefox "great" is going to have the exact opposite effect than you desire. We need to give people a good reason to use our browser because frankly, the "everyday Joes" we seem to be targeting nowadays simply do not care, nor understand, nor want to understand the benefits of open source and privacy protections.

What really matters for these people when choosing a browser is - is it safe? - is it fast? - does it have the extensions I'm used to/does it have a lot of extensions to choose from?

Chrome and Firefox are more or less on par in this. We need to give people more reasons to go for our browser - and making it more like Chrome is only a reason NOT to choose Firefox. Complete themes (by the way, nice try demonizing them by calling them "heavyweight") are a feature that, quite literally, no other browser with a significant market share offers. For some, this might be the reason to use Firefox over Chrome - and you aim to take this reason from them.

Comment 5

3 years ago
At least you should add support to heavyweight theme in webExtension API before remove support of heavyweight themes based on XUL, or users will say "Mozilla is copying Chrome" or "Firefox is going to die"
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2)
> All that said, it will be a very sad day for me when my Firefox will needs
> to start looking as ugly and boring as the default theme, and it fell stop
> to feel like "my" browser - but that may be just me.

It isn't just you. The first thing I noticed in a Mozilla browser (Netscape 6, at the time) were its themes (there were hardly a dozen of "Netscape skins" by then, but it was a great idea in the making). It is my firm belief that the one thing which makes Mozilla browsers and mailers stand out in contrast to those of other software manufacturers is its wealth of add-ons of every imaginable (and sometimes even unthought-of) variety. Complete themes are an essential part of that. Eliminating complete themes would IMHO be shooting oneself in the foot, and (as there is talk of) eliminating full-fledged extensions would be shooting oneself in the other foot, leaving all Mozilla applications as good as dead by sacrificing what made their greatness. Benjamin, I have a lot of respect for you, but obviously we don't see eye-to-eye in this matter.

Comment 7

3 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #0)
> As part of Firefox great-or-dead
No chance for great with such decisions, you're making it dead

Comment 8

3 years ago
I also object to this plan. I have 7 full themes for Firefox, all with a large set of active users.
Also because of my involvement as full themer, I was able to detect and squash a large number of bugs (such as network, zip, cache, images, and rendering). One of the biggest differences of Firefox is that it is so open, removing this will close up Firefox and make it less open.

Comment 9

3 years ago
FT Deepdark alone already has over 190K users: https://addons.mozilla.org/en-us/firefox/addon/ft-deepdark/ . That's only 1 theme.

And you intend to just remove theming.

How is it not obvious to you this will be another killing blow to the userbase?

Comment 10

3 years ago
Also, just because your userbase is getting bigger by absorbing more and more "everyday joes" (aka users who just don't care, don't know anything about computers and frankly shouldn't have anything to say) doesn't mean your "advanced" (we have to call theme users advanced users now? What the hell is the point of firefox then?) users are suddenly not important anymore. They may be a smaller fraction now but they're still the same absolute number: if they were important before they're still important now.

Comment 11

3 years ago
I got into Phoenix 0.35 in 2002. I have watched you devs as you make boring, almost unseeable schwa grey bleak default themes that only appeal to your demographic. Too bad. As you age you will appreciate visual enhancements that make Firefox easier to use. 

"Great or Dead," you say. Like a Zombie, you can't tell the difference.

Comment 12

3 years ago
I'm with KaiRo and tonymec here, along with the other Nay sayers. Also, if that's Toolkit support as such, is my assumption correct that applications which are shipped with multiple themes will lose those? (thinking SeaMonkey's Modern theme as an example).

Overall, this proposal lacks any plausible justification.

Comment 13

3 years ago
Even more reasons to switch over to another browser like Vivaldi, Pale Moon or Otter Browser!

What is so wrong to support both user groups, simple users and advanced users? Google Chrome is not right in what they are doing! Minimalism and simplicity works for them, Mozilla Firefox usergroup is different. Why not acting in your own interest and supporting these users again without forcing them to lose feature after feature? What is so wrong being unique? What is so wrong of being different?

If it is because otherwise you get no Yahoo money anymore, sometimes a small rebellion helps, Anyway, stop making Firefox another Chrome, this battle with Google you can not win!

Comment 14

3 years ago
Sheesh. Talk about self-fulfilling prophecies. You minimized themes, took the focus away from them completely, practically hid the links to them in the Addons page while changing Personas to Themes and featuring them instead. Big shock, Complete Theme usage went down.

I have been a proud Netscape, Phoenix, Firebird, and Firefox user for decades. There are currently enough addons and fixes from 3rd parties to undo all the damage the Firefox 'Design team' is doing. From this point on, I will no longer install any Firefox updates. When this browser finally stops working, I will switch to Chrome, as everyone else already has.

You guys really don't seem to get why we loyal fans use Firefox. We don't want Chrome. Yet, each decision over the past few years makes Firefox more and more like Chrome. And with each change, more and more users think "Well, I may as well just switch to Chrome". So your market percentage continues to drop. 

The "Great or Dead" tagline really does read as a joke, because you're killing it. And you can't even see it.

Yes, I made a new account, just to reply here. That's how strongly I feel about this.

Comment 15

3 years ago
Sorry for one more comment... but i had some more in my mind :)

You seem to believe that Firefox must become as close as possible like Chrome to be able to stay competitive...

BUT: This is still a bad approach to survive! Especially when competing with Chrome it is of importance that you try to be unique and not more of the same. All changes so far since Australis have made users running away instead of making Chrome users switch over to Firefox. This latest idea will not change the course of what has happened so far. And i do not know ANYONE who ever wanted that Firefox is not unique anymore and is stripping itself down to the features of the competitors. Not ONE single person i do know who ever wanted THAT!

The only one who wants this are you Mozilla guys! Being unique is what makes users stay, being standard is what makes users running away. After all, the majority of Firefox users are not beginners but power users and geeks and therefor have different needs and demands from the software they are using! And why should a Chrome user switch over to Firefox? Just because it is more private and less spying than Google Chrome? If Chrome users would care for this things they never would have used Chrome in the first place.
Playing this "My product is more mainstream than yours and i beat your simple and minimalist concept with my simple and minimalist concept" game Mozilla can't win! Google has perfected that playfield since it's existence - And competing with a Browser giant like Chrome that way will not end well!

But you can't or do not want that to realize. And you want to know what is the most sad thing of this? That in the end a closed source browser like Vivaldi with it's CSS UI or Otter Browser (which is based on that **** half baken QTWebkit - and later of the for sure not less **** and bugfree QTWebengine) is in the end more customizable than Firefox when you guys are done!

Comment 16

3 years ago
Cutting off one of the best features only to avoid some bugs while no other method replacing heavyweight without xul,not wise.
object.

Comment 17

3 years ago
Note, these themes are generally not heavy-weight, but less-weight, as they are better optimized, use less images and use more tighter css styling (than the default which is bulky and messy).

Comment 18

3 years ago
If you do that, Firefox will die! Our browser has already lost many users because you don't fix Flash hangs and rather add Firefox Hello and redesign Add-ons Manager. Customizability is one of the main reasons why some people insist on Firefox, and we'll lose them too if we do that.

Please stop making useless changes to Firefox, there are many other bugs to focus on. Just read some Firefox reviews on Download.com and you'll see I'm right.

Comment 19

3 years ago
(In reply to Marko Glad [:upwinxp] from comment #18)
> If you do that, Firefox will die! Our browser has already lost many users
> because you don't fix Flash hangs and rather add Firefox Hello and redesign
> Add-ons Manager. Customizability is one of the main reasons why some people
> insist on Firefox, and we'll lose them too if we do that.
> 
> Please stop making useless changes to Firefox, there are many other bugs to
> focus on. Just read some Firefox reviews on Download.com and you'll see I'm
> right.

Not to mention there are also bug tickets to work on, some of which have literally existed for OVER A DECADE without being fixed while dealing with basic usability. Trying to scroll with the mosue while highlighting text comes to mind: it works upwards but not downwards, and the ticket is many years old IIRC. There are plenty of others but I CBA to remember them anymore, I'm fed up with mozidiots firebollox.
I would just like to point out that this bug is not just about removing support for heavyweight themes. It's also about coming up with a plan what kind of theming support we want to add to replace them. Constructive comments on that subject would be *extremely* useful, so I'd really appreciate it if you could keep the conversation on topic, and take the rants about how Firefox should be killed with fire to another forum.

The basic fact of the matter is this: heavyweight themes, in their current form, are not sustainable. They require a complete reimplementation of the Firefox front-end CSS for every theme. They require significant, painstaking updates for every release (which happen *much* more often now than they did when the feature was designed). They require a massive amount of energy by both Firefox developers and third-party theme developers to keep alive. Most themes fall by the wayside after a couple of years (and that's being optimistic).

We simply need to do better. That's all there is to it. So if you have any comments on *how* we should do better (again, aside from comments about us dying by fire), now would be the time to add them.
Comment hidden (abuse-reviewed)
(In reply to Tony Carlito from comment #21)
> You know you are quite funny.

I don't think so. I try to be funny from time to time, but all I generally get is disapproving looks.

> Full themes are not heavyweight ones!

I'm sorry, but they are, unambiguously, heavyweight. FT DeepDark, for example, has about 40,000 lines of CSS, 282 CSS files, 1095 images. Those numbers are not unusual. It's possible for heavyweight themes to be smaller, but not small.

> That is just a try to make a feature YOU dislike to make disappear!

As it happens, I rather like heavyweight themes.

> http://forums.mozillazine.org/viewtopic.php?f=18&t=2972129 - There  is a
> nice comment from Frank Lion about you MOzilla guys faking and freezing
> numbers until the amount was low enough to be able to kill them.

We don't fake numbers. If you want to accuse us of lying, please take it to another forum. If you want to have an actual discussion about the topic of this bug, then by all means continue, but there's not going to be any kind of productive discussion if all you want to do is accuse us of outright malice.

Comment 23

3 years ago
(In reply to Kris Maglione [:kmag] from comment #20)
> The basic fact of the matter is this: heavyweight themes, in their current
> form, are not sustainable.
What about lightweight "heavyweight" themes (they use "style" in chrome.manifest)? Add-ons developers can use this way to do many things that users want to see. And without "be broken after every Firefox release".

> We simply need to do better. That's all there is to it. So if you have any
> comments on *how* we should do better (again, aside from comments about us
> dying by fire), now would be the time to add them.
For ex., "browser/devtools" can be moved into separate package (like "browser-devtools"). That will save many time for theme developers. Not too many as removing themes, though.

Comment 24

3 years ago
(In reply to Kris Maglione [:kmag] from comment #20)
> They require a complete reimplementation of the Firefox front-end CSS for
> every theme. They require significant, painstaking updates for every release
> (which happen *much* more often now than they did when the feature was designed).
> They require a massive amount of energy by <...> and third-party theme
> developers to keep alive.
You know, all modern themes is just a "patchset" for the default theme. So, we talk about 1-4 hours per Firefox release to update. Not sure that is a good reason to remove feature too early.
Comment hidden (abuse-reviewed)
Comment hidden (abuse-reviewed)
Comment hidden (abuse-reviewed)
(In reply to Alexander Seleznev from comment #23)
> What about lightweight "heavyweight" themes (they use "style" in
> chrome.manifest)? Add-ons developers can use this way to do many things that
> users want to see. And without "be broken after every Firefox release".

That's a possibility. At this point, I think the most interesting question is what are the most important features themers want the most, and why. I don't think we're going to be able to let themes apply arbitrary CSS to the browser, because we want themes to continue working even if we make major changes to it. So until we answer the question of what we need most, we can't answer the question of how to implement it.


(In reply to Alexander Seleznev from comment #24)
> You know, all modern themes is just a "patchset" for the default theme. So,
> we talk about 1-4 hours per Firefox release to update. Not sure that is a
> good reason to remove feature too early.

That still adds up to quite a lot of hours. Too many for a lot of people to invest every 6 weeks, which is why so many themes stop being updated. And even if themes are implemented as a patch set, and updated regularly, many themes fail to make the changes necessary to support new features that the authors aren't aware of.

This is also assuming that we make minimal front-end changes in Firefox. Which is the other part of the problem. It takes much, much more time than you might imagine for Firefox developers to continue supporting heavyweight themes. Not just in maintaining the code that implements them, but also in limiting the front-end changes we make so that we don't regularly break them all to pieces.

Comment 29

3 years ago
(In reply to Kris Maglione [:kmag] from comment #28)
> Too many for a lot of people to invest every 6 weeks
 That means literally: the Mozilla devs decided to update the browser every 6 weeks AND they make some minor changes every release => it's hard to maintain full themes (what a surprise).
 You haven't mentioned that you can reduce time required to maintain full themes by enabling them only on ESR. I'm not even talking about slowing down the "rapid release" which causes a lot of regresses
> limiting the front-end changes we make so that we don't regularly break them all to pieces
 I don't see Deep Dark theme breaking much things. ✱Every✱ extension I used was somehow broken, even the firefox itself (the most broken thing in my install), even the firefox default theme.
 It's completely OK to break some things if user is OK with it and installs an extension himself.
Comment hidden (advocacy)
(In reply to Frank Lion from comment #30)
> Kris, how about not deliberately doing 'an Asa Dotzler' on us and stop
> calling Complete Themes 'heavyweight themes'? If you want to be treated with
> any respect then how about you show some?

The terminology we use internally very often not the terminology we use
publicly. Internally, and in bugs, we've always called what we now call
"background themes", "lightweight themes". For symmetry, many of us who deal
with lightweight themes naturally call "complete themes" "heavyweight themes".

There's nothing more to it than that. This isn't a formal announcement, or a
blog post. It's a technical bug, and it uses the terminology we tend to use in
technical bugs.

> As for the rest of the above quote, then all of it is incorrect in the case
> of my own Firefox themes. 

That is undoubtedly the case, but it's the case only because you happen to be
exceptional. You implement themes more like extensions than as they were
designed to be implemented. The way that most complete themes are implemented
is much more fragile, and that's exactly what we're trying to fix.

If at all possible, I'd like whatever solution we come up with to allow
implementing themes like yours, which is why I'm here asking for input.

> Incidentally, could I just give my sincere thanks to Mozilla for leaving a
> solid wall of around 400 old themes on AMO (out of a total of 491) that any
> new Firefox themes have to break through in order to get noticed at all? I
> didn't realise that Mozilla still cared so deeply about the needs of users
> still using Firefox 2, Firefox 3.6, etc.

It's no secret that AMO has been badly understaffed for the past 4 years.
Believe me, you're not the only one who's been unhappy about the state of
things. Fortunately, we're finally fully staffed again, and no longer
developing in maintenance mode, so if you're having problems, please file
bugs.

> I'll leave you guys to it here, but when you finally realise that you don't
> know that much about Complete Themes, you'll find my Gmail address at the
> head of every .css file I write.

I'm not going to pretend to be an expert on complete themes. But I've spent
more hours of my life than I care to recount reviewing them, developing tools
to find common problems with them, digging through the code that implements
them, from the chrome registry, to the UI, to the add-on manager, to the
validator, to the AMO interfaces. To say nothing of the time I've spent as
complete them user, starting from the early days of Phoenix. There are
probably very few, if any, people in the world who have as broad a perspective
on complete themes as me.

So if you want to dismiss me, feel free. But I'm here because I'd like this to
be a productive discussion, not to start arguments.

Comment 32

3 years ago
(In reply to Kris Maglione [:kmag] from comment #31)
> (In reply to Frank Lion from comment #30)
which is why I'm here asking for input.

Doing the usual trick of making a bugzilla ticket in which you already seem to have made up your mind about the ticket long before it was posted and then clapping the dust off your hands as things settle is not "asking for input". Mozilla claims to have user interests in mind but I have seen 0 outreach over the years to the grand public to ask for input on major decisions.

Comment 33

3 years ago
Entire top paragraph of comment #32 is supposed to be a quote of comment #31

Comment 34

3 years ago
(In reply to Kris Maglione [:kmag] from comment #28)
> the most interesting question is what are the most important features themers
> want the most
Just open manifest.json of any theme for Chromium and you will know what to do.

> and why.
You didn't need to know it. Personally, I need tabs-on-bottom feature because OS doesn't have design for apps that use tabs-on-top interface, so Firefox looks out of place. And to implement it I need XBL in the theme! But... nobody care. :) And every theme developer can tell you about too many things like this.

You want to find a "compromise" (or trying to look like you want), but we will not agree. All or nothing! Sounds like "great-or-dead", is it? Firefox is the most customizable browser and with Servo (?) you have an ability to do it right.

---

Another question is simple - are you sure that you can to do stable interface, that will not be changed over years? So, you can try to make a checklist like (what you want to add in personas):
- icons
- background for about:newtab
- tabs
... but you realize that all elements was changed in past (and multiple times).

For example, I use theme for Chromium that was made 4 years ago. And it's still works a well (but looks as shit). Are you _really_ ready for this?

---

> many themes fail to make the changes necessary to support new features that
> the authors aren't aware of.
You have review process on AMO.
(In reply to marnick.leau from comment #32)
> Doing the usual trick of making a bugzilla ticket in which you already seem
> to have made up your mind about the ticket long before it was posted

Please read comment 0 again. The decision to remove complete themes has already been made, but what the replacement will look like is still an open question. I'm sorry if the discussion so far hasn't been as public as I would have liked, but that's just the way it stands.

Comment 36

3 years ago
(In reply to Kris Maglione [:kmag] from comment #35)
> (In reply to marnick.leau from comment #32)
> > Doing the usual trick of making a bugzilla ticket in which you already seem
> > to have made up your mind about the ticket long before it was posted
> 
> Please read comment 0 again. The decision to remove complete themes has
> already been made, but what the replacement will look like is still an open
> question. I'm sorry if the discussion so far hasn't been as public as I
> would have liked, but that's just the way it stands.

That's how *everything* the last few years seems to have gone. You guys just have your internal chitchats, probably looking at charts comprised of 90% average joes who frankly wouldn't know what they wanted if you spelled it out for them to base your decisions on, ignoring everything that isn't a percentage-wise major use case (regardless of the absolute size of the case, like the hundreds of thousands of theme users), and then tell us the glorious news about whatever annoying decision was made that time with 0 input beforehand.
(In reply to Alexander Seleznev from comment #34)
> (In reply to Kris Maglione [:kmag] from comment #28)
> > the most interesting question is what are the most important features themers
> > want the most


> Another question is simple - are you sure that you can to do stable
> interface, that will not be changed over years?

No. I expect and hope that it will be changed over the years. But I also hope it will be possible to write relatively complex themes that can be used for several releases without worrying that the browser will fall apart.

> Just open manifest.json of any theme for Chromium and you will know what to
> do.
> ...
> For example, I use theme for Chromium that was made 4 years ago. And it's
> still works a well (but looks as shit). Are you _really_ ready for this?

I'm not sure how much of this is genuine and how much is sarcastic. What about Chromium's theming do you like? What do you think could be done better?

> > many themes fail to make the changes necessary to support new features that
> > the authors aren't aware of.
>
> You have review process on AMO.

We do, but even we can't always keep up with all of the changes necessary to keep full themes working. When a new, hidden-by-default developer tools panel is added, for instance, we may not know to check it. And, again, this is more of what makes the process draining and time consuming for everyone.

Comment 38

3 years ago
(In reply to Kris Maglione [:kmag] from comment #37)
> > Just open manifest.json of any theme for Chromium and you will know what to
> > do.
> > ...
> > For example, I use theme for Chromium that was made 4 years ago. And it's
> > still works a well (but looks as shit). Are you _really_ ready for this?
> 
> I'm not sure how much of this is genuine and how much is sarcastic. What
> about Chromium's theming do you like? What do you think could be done better?
Themes for Chromium is a best example of themes that doesn't need to update for every release. I doesn't like them but technically they are perfect.

> No. I expect and hope that it will be changed over the years. But I also
> hope it will be possible to write relatively complex themes that can be used
> for several releases without worrying that the browser will fall apart.
Well, background image of #navigation-toolbox it's maximum of you can allow to change for users.

Comment 39

3 years ago
(In reply to Kris Maglione [:kmag] from comment #31)
> So if you want to dismiss me, feel free. But I'm here because I'd like this
> to
> be a productive discussion, not to start arguments.

Thanks for the reply. I never dismiss anyone, Kris. But, I do have one question - what is the point of this bug?

In comment 35, you state that 'The decision to remove complete themes has already been made, but what the replacement will look like is still an open question' and we know from this - https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ which was written back in August 2015, that Mozilla intend to deprecate XUL and XPCOM on a timescale of 12 -18 from back then. So why are you looking for any sort of proper replacement for conventionally written Complete Themes, when that replacement will stop functioning the moment XUL does?

I have to tell you, Kris, I'm not seeing many (any?) UI changing WebApps in the Chrome store, you know. 

If I can see a point to it, then my Gmail offer still holds, but I don't 'do' Bugzilla type stuff and never will.

Comment 40

3 years ago
If you are going to ditch the Complete themes (thanks Frank) and are going to replace them, then I will have to stop what I'm doing and re-learn CSS. Make it worth my while. I hope you guys come up with a real simple UI for making themes. I will admit that you can still find code in my themes that goes back to 2004. I would like to see simple coding for theme-making, so you could get lots of theme-makers. 

For one thing, I would like you to keep all your boxes elastic, stretching to the size of the content. I would like you to acknowledge that lots of us can't see your tiny type. You should be incorporating the Theme Font and Size Changer extension into your basic UI -- or at least the size part. I would also like you to implement icon sizes. I maintain several Aeon themes just to present four different icon sizes. For the record: 24px, 32px, 48px and 64px. Would I like to be able to have svg icons? Of course! But I doubt we'll see  them.

It would be nice to hope that I can reduce my theme count.
(Assignee)

Comment 41

3 years ago
(In reply to Frank Lion from comment #39)
> Thanks for the reply. I never dismiss anyone, Kris. But, I do have one
> question - what is the point of this bug?

The point of this bug is to start to lay the groundwork for what themes support will be in the future, with the goal of making them simpler to create and maintain. This bug isn't meant to say "we're killing Complete Themes in Firefox", it's the starting point for planning what happens with them moving forward, and scoping what we can support and how.

We need feedback on what people would like to be able to do with Complete Themes, and how we make those changes accessible via an API to reduce dependencies on things like platform-specific modifications and XUL, and make them easier to maintain for everyone. Forcing a user into using "the one true UI" is not something we're not particularly interested in, but we'd like to enable those changes to Firefox with methods that make themes simpler to develop and support from both a Theme developer and Firefox maintenance perspective, and to avoid subjecting users to things like compatibility issues and other bustage on updates (and subjecting theme developers to having to track them down and fix them where we can avoid it).

We'll get a post up tomorrow on the forums with some more detail why theme support is changing along with a call for feedback on what theme developers look for, what pain points exist with the current framework, and what changes to theme support they'd like to see considered.
Comment hidden (off-topic)
(In reply to Frank Lion from comment #39)
> in August 2015, that Mozilla intend to deprecate XUL and XPCOM on a
> timescale of 12 -18 from back then. So why are you looking for any sort of
> proper replacement for conventionally written Complete Themes, when that
> replacement will stop functioning the moment XUL does?

That timescale applies specifically to extensions. Deprecating XUL and XPCOM
in Firefox as a whole will take much longer. When we actually start that
project, we'd like themes to continue working with it, which current complete
themes certainly will not.

Comment 44

3 years ago
(In reply to Kev Needham [:kev] from comment #41)
> (In reply to Frank Lion from comment #39)
> > Thanks for the reply. I never dismiss anyone, Kris. But, I do have one
> > question - what is the point of this bug?
> 
> The point of this bug is to start to lay the groundwork for what themes
> support will be in the future, with the goal of making them simpler to
> create and maintain. This bug isn't meant to say "we're killing Complete
> Themes in Firefox", it's the starting point for planning what happens with
> them moving forward, and scoping what we can support and how.
> 
> We need feedback on what people would like to be able to do with Complete
> Themes, and how we make those changes accessible via an API to reduce
> dependencies on things like platform-specific modifications and XUL, and
> make them easier to maintain for everyone.

Ok, so to replace this "heavyweight" themes which can do arbitrary styling and replace chrome packages i want a way to have "Complete" themes which can do arbitrary styling and replace chrome packages.

Also i want to know who decides what is "great" and what is "dead" cause i think mozilla needs to take users into account before killing major features one after another.

*Panorama will be removed: This function was pretty hidden and the shortcut was uncomfortable most users don't know it exists, maybe panorana is a great feature but mozilla has failed to advertise it but nobody knows, it could be replaced with an addon but there's nothing similar enough yet.

*Themes will be replaced with a more restrictive less powerful less flexible api.

*Permissive addons will be replaced with a more restrictive less powerful less flexible api.

This changes will create a more restricted less powerful less flexible browser, Is like adding to firefox all the cons of chrome without any of the benefits, and everything is done without taking the users into account.

Comment 45

3 years ago
(In reply to Kev Needham [:kev] from comment #41)
> (In reply to Frank Lion from comment #39)

> We need feedback on what people would like to be able to do with Complete
> Themes, and how we make those changes accessible via an API to reduce
> dependencies on things like platform-specific modifications and XUL

Thanks Kev, but I think you already know what people would like to be able to do with Complete Themes, because we are already doing it and are not complaining that we want to be able to do more.

As for the rest of that, I reckon you'd have to be pretty desperate to want to learn an entire new skillset just to make Complete Themes for Firefox. Especially when there is so much other stuff around that can be made to look good using the existing set. Still, perhaps the guys who make Personas can help you out on that one.


In reply to Kris Maglione [:kmag] from comment #43)
> That timescale applies specifically to extensions. Deprecating XUL and XPCOM
> in Firefox as a whole will take much longer. When we actually start that
> project, we'd like themes to continue working with it, which current complete
> themes certainly will not.
Well, I'm sure that's right, Kris, but I'm a simple soul and I like my mixed messages plain and consistent. 

So, when Kev Needham writes the following on an official Mozilla blog - 'Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now.' 

.... and I know that the term 'add-ons' includes Complete Themes and I know that they heavily depend on XUL, I think you can see why I was puzzled.

Thanks for the clarification.

Comment 46

3 years ago
(In reply to Kev Needham [:kev] from comment #41)
> The point of this bug is to start to lay the groundwork for what themes
> support will be in the future, with the goal of making them simpler to
> create and maintain. This bug isn't meant to say "we're killing Complete
> Themes in Firefox", it's the starting point for planning what happens with
> them moving forward, and scoping what we can support and how.

Unfortunately, the way this bug was filed with its comment #0 without further explanation, and the way the topic was mentioned in even internal strategy meetings made it feel like exactly what you're saying we didn't mean. Let's try to do better in the future.

Thanks to you and Kris for getting into a way more constructive tone. I think everyone here wants to have a Firefox that is highly customizable so people can make it their own and be in control of their experience, and also wants a way of creating themes that is as simple and at the same time as powerful as needed to get the look and feel that a theme targets. And that reaches from the simple wallpaper style of current "lightweight" themes via complete color scheme and icon set changes to a whole different look of the browser like e.g. my own LCARStrek theme is doing (which is extreme enough that some hate it and some love it). I think we also pretty much agree that right now, it's complicated to support full themes for developers as well as for us theme designers to create and maintain them, so if we find something that's easier and also more future-proof while maintaining how powerful you can be, that's awesome.
We know that when we move more and more to standard HTML for our UI (which I think of as the actual goal, and XUL going away should be a delayed side-effect), there will need to be changes. That said, CSS applies to HTML just as well as to XUL, so it's a technology we can continue to use - even if we make heavy use of things like CSS variables to make some things much easier to achieve.
(In reply to Frank Lion from comment #45)
> Thanks Kev, but I think you already know what people would like to be able
> to do with Complete Themes, because we are already doing it and are not
> complaining that we want to be able to do more.
> 
> As for the rest of that, I reckon you'd have to be pretty desperate to want
> to learn an entire new skillset just to make Complete Themes for Firefox.
> Especially when there is so much other stuff around that can be made to look
> good using the existing set. Still, perhaps the guys who make Personas can
> help you out on that one.

That's sort of the basic problem, though. The learning curve for making
complete themes is extremely steep. They are mostly CSS and images, but
they're mostly Mozilla-flavored CSS, for XUL, with added bits of XBL, and lots
of arcana on top of that. And maintaining them against changes in Firefox
requires a lot of additional skills, and tracking, especially if you use the
standard method of providing an entire theme package rather than adding styles
on top of classic.

A new kind of complete themes may mean a new set of skills to learn for you
(though hopefully it won't), but it also means a whole new set of skills that
do not have to be learned by people just getting started with theming.

We think we can do better. Maybe doing better means just providing the ability
to load CSS stylesheets into certain documents, with selectors for a certain
set of well-documented IDs and classes. Maybe it means a JSON file specifying
a few particular styles for a few particular kinds of elements (hopefully
not). But it definitely means not getting bogged down with a lot of arcana
that isn't relevant anywhere outside of Firefox front-end UI development.

> So, when Kev Needham writes the following on an official Mozilla blog -
> 'Consequently, we have decided to deprecate add-ons that depend on XUL,
> XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most
> likely it will take place within 12 to 18 months from now.' 
> 
> .... and I know that the term 'add-ons' includes Complete Themes and I know
> that they heavily depend on XUL, I think you can see why I was puzzled.

We've never been very consistent about that terminology. Officially, 'add-ons'
mean everything from extensions to themes to search plugins. In practice, it
tends to mean extensions.

That blog post, and timeline, is specifically about extensions. The effort for
themes is related, but is a completely separate project.

(In reply to Sergio from comment #44)
> Ok, so to replace this "heavyweight" themes which can do arbitrary styling
> and replace chrome packages i want a way to have "Complete" themes which can
> do arbitrary styling and replace chrome packages.

The ability to replace chrome packages is definitely going away, for both
themes and extensions. I'd personally love to keep the ability to do arbitrary
styling, but I don't know if that's going to be possible.

> *Permissive addons will be replaced with a more restrictive less powerful
> less flexible api.

That's not entirely true. The stock WebExtensions API will definitely be more
restrictive. I'm not sure about less powerful. With the exception of the
add-on SDK (which never really took off), there previously wasn't any kind of
add-on API at all, which meant that doing a lot of simple things was
incredibly complicated. And adding new features even for the benefit of
extensions has been extremely difficult, because of all the places add-ons put
their hooks into the browser, meaning that even many simple changes tended to
break many of them.

That said, even if the stock API will be more restrictive, we're committed to
keeping it possible for add-ons to do complicated things that we hadn't
thought of, which is where things like native.js (bug 1199718) come in. It
won't be possible for every add-on to easily reach into Firefox internals
anymore, but it will still be possible for them to reach into Firefox
internals if they do it in carefully-engineered, maintainable ways.

> This changes will create a more restricted less powerful less flexible
> browser, Is like adding to firefox all the cons of chrome without any of the
> benefits, and everything is done without taking the users into account.

I don't think so. I think that, if anything, it will create a more powerful,
more flexible browser, because we'll be able to make bigger changes, faster,
without having to worry as much about breaking all of the add-ons that people
depend on.

I do think that it sucks that there's going to be such a sharp transition for
add-on developers, and I say this as the developer of one of the largest, most
complex extensions for Firefox power users. But I also think that it's
necessary, and in the end will make things better for just about everyone.

Comment 48

3 years ago
/Please/ don't do this if you can help it!  I use one of those "heavyweight themes" you mentioned, and I'd rather not lose it.

If you guys /must/ do this, then I hope there's still a way to create space-saving themes like LittleFox or MicroFox.*  These are very useful on my 1440x900 desktop screen or on a 1366x768 laptop screen, and better for me than having the top menu bar hidden.  (I like to have options out in front of me, and I have a few things shoehorned in next to the top menu -- http://imgur.com/2mrtafZ)

* I've been using MicroFox since Classic Compact stopped working a few years ago.

-- Links --
MicroFox - https://addons.mozilla.org/en-US/firefox/addon/microfox-for-firefox/
LittleFox - https://addons.mozilla.org/en-US/firefox/addon/littlefox-for-firefox/
Classic Compact (broken since FF 29) - https://addons.mozilla.org/en-US/firefox/addon/classic-compact/

Comment 49

3 years ago
(In reply to Kris Maglione [:kmag] from comment #47)
> That's sort of the basic problem, though. The learning curve for making
> complete themes is extremely steep. They are mostly CSS and images, but
> they're mostly Mozilla-flavored CSS, for XUL, with added bits of XBL, and lots
> of arcana on top of that. And maintaining them against changes in Firefox
> requires a lot of additional skills, and tracking, especially if you use the
> standard method of providing an entire theme package rather than adding styles
> on top of classic.

This is exactly right. The biggest issue I've come up against in the past is just figuring out what things are supposed to do. The amount of prerequisite knowledge required is slightly absurd. That, and the lack documentation gives theme development a huge barrier to entry.

Has any thought gone into what the replacement model will be yet, or is that what this bug is for? I have some thoughts as to what kind of model I'd enjoy working with, but some context is always helpful to understand it better.

Comment 50

3 years ago
(In reply to Kris Maglione [:kmag] from comment #47)
> (In reply to Frank Lion from comment #45)
> > That's sort of the basic problem, though. The learning curve for making
> complete themes is extremely steep. 

No, Kris, the sort of basic problem is that no new people want to make themes for Firefox any more and that's before they would know how hard or easy it is to do. Ask Jorge at AMO, ask anyone in the mozillaZine Theme Dev forum. No one is even asking to be able to make them.

But even if 'the basic problem' was as you say, what difference would it make how steep the learning curve was, when both Benjamin and yourself are on record here as stating that Complete Themes are being removed? 


(In reply to Kris Maglione [:kmag] from comment #47)
> (In reply to Frank Lion from comment #45)
> > So, when Kev Needham writes the following on an official Mozilla blog -
> > 'Consequently, we have decided to deprecate add-ons that depend on XUL,
> > XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most
> > likely it will take place within 12 to 18 months from now.' 
> > 
> > .... and I know that the term 'add-ons' includes Complete Themes and I know
> > that they heavily depend on XUL, I think you can see why I was puzzled.
> 
> We've never been very consistent about that terminology. Officially,
> 'add-ons'
> mean everything from extensions to themes to search plugins. In practice, it
> tends to mean extensions.
> 
> That blog post, and timeline, is specifically about extensions. The effort
> for
> themes is related, but is a completely separate project.

Kris, do I look like some of mug to you? 

We have 3 posts by 3 Mozilla related guys all making 3 contradicting statements and that's all down to an inconsistency of terminology? -

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #0)
> As part of Firefox great-or-dead, we've decided to stop support for
> "heavyweight" themes which can do arbitrary styling and replace chrome
> packages.
> 
> We may simply remove that support completely, or we may extend lightweight
> themes with some additional features such as changing colors or icons.


(In reply to Kris Maglione [:kmag] from comment #35)
> Please read comment 0 again. The decision to remove complete themes has
> already been made, but what the replacement will look like is still an open
> question. 

(In reply to Kev Needham [:kev] from comment #41)
>This bug isn't meant to say "we're killing Complete
> Themes in Firefox", it's the starting point for planning what happens with
> them moving forward, and scoping what we can support and how.


Benjamin clearly states that Mozilla are stopping arbitrary styling and replacing chrome packages and you already know that any replacement will not be able to either, so why bother asking when you already know we want precisely that?


Look Kris, how about we stop dancing on the head of a pin and actually do something. Here's a plan -

#1. As it has already been decided to whack existing Complete Themes, then make an announcement stating that on a /specific/ date in the very near future, Mozilla is going to stop/disallow/depreciate/whack Type=4 Complete Theme jars. 

#2. Don't bother asking existing Complete Themers about what they would like to see or want, when you already know that policy will prevent any of it coming to fruition. You really shouldn't deliberately  waste people's time, just to fulfill an internal 'outreach' policy remit. 

#3. Instead ask the guys making Personas what they want, as you may actually be able to fulfill some of their wants. Mozilla also still has some creditability with them and could come out of this looking like the good guys (usual care and concerns about the needs of our users yadda, yadda, stuff)

#4. Code up a simple interactive InContent Mozilla Theme page for users that gives them the ability to colorize their toolbar buttons, greyscale stuff, etc. Just use .svg filter coding for that. It's quick, it's simple, it will never break anything, users will love it and the big plus for Mozilla is that Mozilla will be in total control of it....but obviously the feature can be marketed as putting users in total control of how their browser looks.

See? Concise, quick and effective.....just like me. :)


I didn't want to come on this bug, I came because I was specifically asked to and now you have my views on this subject, I'm off.
Keywords: addon-compat
(In reply to Kev Needham [:kev] from comment #41)
[...]
> We need feedback on what people would like to be able to do with Complete
> Themes, and how we make those changes accessible via an API to reduce
> dependencies on things like platform-specific modifications and XUL, and
> make them easier to maintain for everyone. Forcing a user into using "the
> one true UI" is not something we're not particularly interested in, but we'd
> like to enable those changes to Firefox with methods that make themes
> simpler to develop and support from both a Theme developer and Firefox
> maintenance perspective, and to avoid subjecting users to things like
> compatibility issues and other bustage on updates (and subjecting theme
> developers to having to track them down and fix them where we can avoid it).
[...]

This is a reasonable question, but not an easy one to answer. Of course, "what people would like to be able to do with Complete Themes" will vary somewhat from one user to the next, so of course no two users will answer the question exactly alike. I can only answer for myself, so let's try to mention a few things that I feel important. Of course, other people's MMV.

* I'd like _both_ SeaMonkey themes (Classic and Modern) to go on working and to require as little manpower for it as possible. They are part of a Mozilla app after all, albeit a community-driven one; but "administratively" supported by MoFo last time I checked.

* Unlike some other commenter, I'd like complete themes, or whatever replaces them, to go on working on all code branches, even on Trunk. This may go without saying but maybe it goes even better if said.

* I'd also like the few complete themes still actively maintained (KaiRo's for one thing, but there are other serious theme authors among the commenters of this bug) to go on working with a minimum of hassle for their maintainers. Themes which haven't seen even one update in, oh, let's say a year and a half for good measure, those are IMHO as good as dead anyway; let's take care of the "alive and kicking" ones first.

* I'd like to keep it possible in the future for themes to use significantly less screen real estate than the default theme by using smaller fonts, toolbars and icons. Some of them already do it.

* On the other hand, I don't want Firefox, Thunderbird and SeaMonkey to stop working for people who need large type and large widgets because they are half blind. (And BTW the blind people I know prefer to be called "blind", which to their mind is a positive qualifier, rather than "visually impaired" which is inherently negative. But let's close the parenthesis.) This kind of large-type and/or high-contrast themes also exists already; I have a feeling that the a11y team would tear you to shreds if they stopped working.

* When no theme is available for exactly what is desired, I'd like "technical-minded" users to be able to go on tweaking what they see with userChrome.css and userContent.css like they always did. This implies themes written in a language supporting CSS stylesheets; for chrome, IMHO XUL would be ideal, but HTML (I'm including HTML5 and XHTML in the same category) might be acceptable if it has the right functionality for what is felt needed in browser and mailer chrome (menus, submenus, buttons, throbbers, input boxes, checkboxes, radio buttons, tree hierarchies, toolbars, tooltips, dialogs, whatever).

* I'd like it to be easier to marry a lightweight theme and a non-default complete theme without too much hassle. At the moment it is possible, but just barely: in the general case three restarts are necessary, as follows:
    (1) Select a lightweight theme. If your current complete theme is other than Default, you need to restart in order to apply it (1st restart), and it will come up with the look & feel of the default theme.
    (2) Select your favourite complete theme again. You need to restart in order to enable it (2nd restart), and that will disable lightweight themes.
    (3) Go to about:config and filter on "htth". Depending on your code branch, one of two possible different actions is necessary to marry, er, not yet: to betroth both themes together:
        (3a) On current Trunk and aurora (I'm not sure about beta and latest release), set the string pref lightweightThemes.selectedThemeID to the ID (as found in lightweightThemes.usedThemes) of the theme you selected at step 1. I expect that theme to be the first (leftmost) one but I don't expect it to stay that way forever (i.e., ten years from now).
        (3b) Or on slightly older branches, toggle the Boolean pref lightweightThemes.isThemeSelected to true.
    (4) The canonical "marrying" step is to restart the app (3rd restart). I think it might be possible to replace this third restart by just hovering the mouse over any lightweight theme's preview image at AMO but I'm not 100% sure.
    I feel like it ought to be possible to change the lightweight theme on any complete theme without the need to restart: hovering the mouse over a preview image already does it temporarily. But the add-on manager developers seem to have put the parking brake on that development (bug 520124).

* Oh, and one thing which is not for me to decide: I'd like lemon_juice (michal-ok@o2.pl) to be listened to more, he has superb ideas to put grease into the cogwheels between Firefox and AMO OT1H, (Thunderbird too but it doesn't need it as much) and SeaMonkey OTOH. If he got a job with Toolkit and/or AMO I would jump to the ceiling in joy. But he may have other priorities. This is unpaid advertising: I never met him except via Bugzilla and his user site. "He" might even be a "she" for all I know. But his converter site http://addonconverter.fotokraina.com/ and his "AMO browsing for SeaMonkey" extension http://addonconverter.fotokraina.com/amo-browsing/ are just the kind of things which made me think, when I saw them, that that's what I had been hungering for all along and never getting it from Mozilla.

* Well, on rereading, maybe that last bullet paragraph above is just a tiny wee bit overenthusiastic. But please check it before you decide that it is "only" poetic exeggeration.

Of course there's only one of me; but you asked for feedback. I hope that not too many of the above will end up thwarted.

Comment 52

3 years ago
Guys, for a mere user like me this would be another nail in the coffin.
I fiercely loved Firefox exactly for its unlimited capabilities of styling and addon enrichment.
This is where my absolute loyalty comes from - I didn't leave FF even when everybody fled from it because it leaked memory like hell, before the MemShrink project started.
And now I see how all the stuff I loved in Firefox is gradually going away with every new release and nobody cared to ask users how'd they felt about losing features.

(To give an example - my favorite feature "All tabs" (grid-like on Ctrl+Shift+Tab) was silently removed, then restored by someone with an addon "All Tabs Restorer" (thus showing how great FF is as missing functionality of any complexity can be added back as addon, btw), and now it's dead completely after FF42 update. This was the feature I used A LOT, many many times a day; now I feel like I'm in a foreign country where nobody cares about me and my needs rather than being inside my "internet home" - my favorite tailor-customized browser.
Another example is the removal of text zoom in FF for Android - must have for phone users).

To me, the removal of themes will be the saddest day and it will really undermine my loyalty, as I use the Walnut theme from the very beginning (I guess even since Netscape) and this is how *my* browser should look. *My* browser is not default theme, not Personas - it's the one and only Walnut.

You say it's a great burden for theme developers to keep up with FF changes - but the very developer of my favorite theme, Alfred Kaiser (comment #8) is against this, and I guess he knows about the burden of owning a theme much more than most of the people here.
If you want to remove some aspects of implementation - fine, as long as you provide alternatives and major themes migrate to them with no loss. But please don't delete things leaving users with no replacement.

I don't want another Chrome. I want my Firefox to be really "mine", and this definitely includes themes.
(In reply to Frank Lion from comment #50)
> No, Kris, the sort of basic problem is that no new people want to make
> themes for Firefox any more and that's before they would know how hard or
> easy it is to do. Ask Jorge at AMO, ask anyone in the mozillaZine Theme Dev
> forum. No one is even asking to be able to make them.
>
> But even if 'the basic problem' was as you say, what difference would it
> make how steep the learning curve was, when both Benjamin and yourself are
> on record here as stating that Complete Themes are being removed?

I'm not sure what you're arguing for here. In any case, I personally think
that customization of Firefox is extremely important, which is why I've spent
a huge chunk of my life working on it over the past ten years. I think that
a lot of people are interested in making and using themes that do more than
just change background images, like personas.

I don't know for certain why so few people are interested in making complete
themes, but I do know that the learning curve is a huge part of it. I've heard
people complain about how hard it is to get started. I've heard second hand
complaints through other theme designers, like KLB of Compact Classic fame,
that people don't like how hard it is to get started or to maintain their
themes. *I* thought the learning curve was too high, and I'm someone who's
plowed through an entire semester of calculus in 3 weeks of ordinary class
time, while taking a full course load.

I'd like to see more people making themes, but given the difficulty involved,
it's been hard to do anything to promote it. Which is exactly why I want us to
have some way to do more comprehensive theming in a way that we can thoroughly
document, and that's more approachable to anyone with a web developer
background, or even to people just starting out.

> Kris, do I look like some of mug to you?
>
> We have 3 posts by 3 Mozilla related guys all making 3 contradicting
> statements and that's all down to an inconsistency of terminology? -

I don't really have anything to say to that. The blog post in question was
specifically about extensions, from start to finish. The paragraph about the
deprecation of XUL certainly has implications for complete themes, but none of
the specifics had anything to do with them.

Feel free not to take me at my word on this, but the facts are the same: the
timeline for deprecation of XUL and XPCOM is going to be much longer than 18
months, this is a completely separate project from the deprecation of
XUL/XPCOM extensions, and it has a completely separate timeline (which is yet
to be determined).

> Benjamin clearly states that Mozilla are stopping arbitrary styling and
> replacing chrome packages and you already know that any replacement will not
> be able to either, so why bother asking when you already know we want
> precisely that?

As I've already said, replacing chrome packages will definitely have to stop.
"Arbitrary" styling will also certainly have to stop, but in this case,
arbitrary means literally every bit of CSS and XBL everywhere in the browser.
We're certainly going to have to draw the line short of that, but exactly
where we draw it is still an open question.

> #1. As it has already been decided to whack existing Complete Themes, then
> make an announcement stating that on a /specific/ date in the very near
> future, Mozilla is going to stop/disallow/depreciate/whack Type=4 Complete
> Theme jars.

We will certainly do that. But before we can do that, we need to decide when
that date will be, and before we do that, we need to decide what our future
plans for theming are outside of complete themes.

That is exactly the purpose of this bug.

> #2. Don't bother asking existing Complete Themers about what they would like
> to see or want, when you already know that policy will prevent any of it
> coming to fruition.

I'm not really sure how to respond to this, because I don't agree with the
accusation in the second part of your sentence.

> You really shouldn't deliberately  waste people's time, just to fulfill an
> internal 'outreach' policy remit.

I'm not doing any of this for any sort of internal outreach policy. I'm an
engineer, not a community manager. I can tell you with complete conviction
that my manager would be extremely unhappy if he thought I was wasting my time
here. I'm having this discussion because I think it's important that we get
this right, not because of some vague ideas about "outreach".
(Thanks for all of the suggestions so far. I haven't replied to many of them, but I'm taking notes.)

Comment 55

3 years ago
(In reply to Tony Mechelynck [:tonymec] from comment #51)
> * I'd like _both_ SeaMonkey themes (Classic and Modern) to go on working and
> to require as little manpower for it as possible. They are part of a Mozilla
> app after all, albeit a community-driven one; but "administratively"
> supported by MoFo last time I checked.
> * ...
> * I'd also like the few complete themes still actively maintained (KaiRo's
> for one thing, but there are other serious theme authors among the
> commenters of this bug) to go on working with a minimum of hassle for their
> maintainers. Themes which haven't seen even one update in, oh, let's say a
> year and a half for good measure, those are IMHO as good as dead anyway;
> let's take care of the "alive and kicking" ones first.

That's definitely one of the most important aspects of this discussion. Yes, there is a learning curve for writing themes, but those who went through all thee hoops, wrote a nice theme and maintain it on a regular basis despite the fast pace of changes in the Firefox UI, they shouldn't be penalized by forcibly retiring their themes and them having to learn a potentially entirely different set of mechanisms to apply styles (which apparently will be "easier" but also substantially less comprehensive). The SeaMonkey Modern theme is a special case of this, given that it's maintained as an integral part of the application, and patches for the Default theme would usually have corresponding fixes for Modern as well.

(In reply to Kris Maglione [:kmag] from comment #53)
> As I've already said, replacing chrome packages will definitely have to stop.
> "Arbitrary" styling will also certainly have to stop, but in this case,
> arbitrary means literally every bit of CSS and XBL everywhere in the browser.
> We're certainly going to have to draw the line short of that, but exactly
> where we draw it is still an open question.

The motivation/justification for this restriction is not clear. Is there a security concern or is this another attempt to "protect people from themselves" or any other rationale? I like applying userChrome.css changes for re-styling small things, is this going away too? 

Back to comment #51, tonymec is arguing for retaining and more integrating the concepts of complete themes and personas. It appears logical to have complementing high-level (basic) and low-level (advanced) mechanism in place, thus I'd certainly agree with such an effort.

You state that the current complete-theme mechanism puts additional load on the Firefox developers. What is the actual "cost" of the current complete-theme mechanism in terms of implementational effort which would be eliminated by removing that piece of code? Obviously, UI elements will still need identifiers to be addressable from CSS, etc.

Comment 56

3 years ago
I personally always find the most valuable and influential information in replies/comments. I usually read every single one whether it be here, or posts like the "The Future of Developing Firefox Add-ons" one with its 471 comments, or, on sites around the Web.
People have, and always will complain about change no matter what it pertains to, but, the (fairly) recent announcements that have come from Mozilla regarding the changes surrounding add-ons have been huge, baffling, not fully thought out and planned, life changing for some people, but angering to nearly all.

Loyal, long time Firefox users and (mostly veteran) add-on developers are frustrated, they feel pushed out, not appreciated, and more than anything, like outsiders because most of the decisions have seemingly been made behind closed doors so to speak. 
That's a Mozilla that we do not recognize and it isn't the one that we have dedicated so much of our time and lives to.

Perhaps a lot of the problems have been simple messaging ones (it happened here initially), or, a lack of invitation for input before these final decisions were made, but as one of those loyal long time users and veteran contributors, and one speaking for others, I'll just say that it's all uncool, unnecessary, and wrong.

Mozilla is making the mistake of using numbers and metrics for everything when that doesn't always paint an accurate picture.

Mozilla can say that -only- X amount of users use complete themes so the needs of the many etc, etc, and so it doesn't justify the extra work etc, etc, lets dump them. What the numbers don't tell them is that one individual uses a (complete) theme (for whatever reason), he makes add-ons that retains Firefox users and those users get other people to use Firefox so that one full theme user has maybe 50-100 or a thousand users under him. 
The same goes for individual users in general and add-on users and developers. The numbers do not include what they don't include. And they don't include users with disabilities who are a tiny fraction of Firefox users. Firefox being the most customizeable browser empowers users by equipping them with tools that gives them the ability to see, use, and interact with the Internet and in ways that no other browser does. You never lose just a single user. You lose a countless amount that includes potential future users.

It isn't brilliant marketing or the (non-existent) billion dollar advertising budget that gets people using Firefox. It is still what it has always been. Individual people getting other individuals to use it. Mozilla is **** people off one by one, and enough so for them to stop contributing and even using Firefox instead of them adapting, but that's mostly because they haven't had their say before something is final, only after and when it's a this is the way it is, live with it or not deal, and, because a fair and decent alternative has not yet been provided.

I say all of this in the hopes that this is remembered the next time that someone says only so many people use X so it doesn't justify the man hours, cost, and trouble.

Up until now, I haven't commented in the places that I mentioned and this might not even be the proper venue for my rambles, but, as a nearly 11 year user and contributor myself, I worry that Firefox may cease to meet my own needs and liking, I don't like the closed door sessions, I may not even recognize Firefox soon, and so I may not be able to contribute in say, a year from now. I will have lost my faith in it and the belief that it's the best available. That would lead to me not using it, not creating add-ons for it, not getting others to create add-ons, not getting others to use it, not running a site dedicated to helping its users with the greatest needs and so on. I will - always - be a Mozilla supporter and contributor, but for the first time, I can't say the same for Firefox.
I promote Mozilla and hopefully get them to it (contributing, etc), through Firefox, which I believe is/was the initial plan. At least now, Mozilla has way more than just Firefox and its software going for it.

Before this comment is marked as abuse or whatever, I actually do want to contribute and say what is needed for complete themes as I see it.

1. The ability to change fonts and font sizes globally. 
It's practical, not just aesthetic and personal choice.
Theme Font & Size Changer is my concept. It took me 5 years to find someone (Baris Derin) who thought that it was a good idea to develop it and who was willing to develop it. 
I came up with it for users with disabilities, but it just so happens to be very useful for users with high resolution settings and large monitors too. It has always maintained between 80 thousand, and 100 or more thousand users and it's frequently a Featured add-on. Point is, the feature is useful and used.
https://addons.mozilla.org/en-US/firefox/addon/theme-font-size-changer

2. The ability to change backgrounds, buttons and icons globally.
For the same reasons as above. Disabilities (visual, cognitive, etc), high res settings.

3. Simplified coding that doesn't change with (basically) every cycle.
Abandoned themes have been mentioned. Nearly all of them were abandoned because of the constant changes despite the requests made by themers to work with devs and come up with basic templates, etc (see past mozillazine forum posts). People couldn't keep up, it took too much time and work, the exact changes were not clearly documented and so themers couldn't just go to those sections and write for them. Of course, they were extremely and unfairly cast aside too when Personas fully came out but that's a different story.

I have a very basic add-on that offers 64x64px toolbar buttons. I haven't updated it in well over a year because it became too time consuming and too tedious to address the constant changes for a 19 icon (at the time) png and the coding that powered it.
Now I'm in a tough spot. There are only around 1,000 users. But those users rely/relied on my add-on to easily/clearly see the toolbar buttons. I have gotten at least 7 emails asking when it will work again. I'll have to start from scratch for one, but two is, as it stands, in 12-18 months, I won't be able to even fix it as it is. So should I even bother? Yes. I have to. Out of guilt and obligation. It helps people, so I have to.

Ed Hume probably feels the same. He created the very first theme specifically for persons with visual impairments, and there are others who do what they do for similar reasons. To help people out.

So, please help us so that we can continue to help and retain users.

Comment 57

3 years ago
Your #3 request is very very doable even with the current setup.  It requires a few hours of work, and active diligence on that part of developers, and a willingness to actually do something positive for the user instead.  It's all that's been required to fix 99.999% of the complaints theme developers and wanna-be theme developers have had for the last decade.  The big problem with theming Firefox is all of the junk that developers have been throwing into the browser skin and constantly changing.  How do you fix it?  

1. Create a new skin that contains ONLY the styling for the primary UI buttons and tabs.  NOTHING ELSE.
2. Move the icons and CSS for buttons and tabs into that new skin.
3. Put a moratorium on cluttering up the new skin and on randomly changing the names of elements in the primary UI without a damn good reason and enforce it.  

Done.  It took me about 2 hours to do this one afternoon a few years ago.  After that you can build new themes in a few minutes and never have to worry about if the wackadoos in Devtools decided to subtly change the names of everything for no reason.  But Mozilla would rather spend weeks and months and years making up excuses for why they decided to pursue a development path that alienates developers and **** off users than spend 2 hours just fixing the damn thing.  Hope you guys enjoy the hate mail over the last few months.  Us theme developers got plenty of it over the last 4 years for our failures to keep up with your ridiculous development strategies, so I say it's well deserved.

Comment 58

3 years ago
I don't understand why support for full themes need to be killed.
Firefox itself has two full themes: default and "developer edition" (which is poorly done/supported/etc).
Killing full themes because it is hard to maintain is not the valid reason, because it is not hard for Mozilla/Firefox, but for theme authors. It's like, I am killing your babies, because you find it hard...
All the infrastructure for full themes is basic standard functionality (css, images, etc). The only specific part is chrome.manifest/install.rdf which are also used by extensions.
In fact, themes are a trimmed down version of extensions, so these will also be killed then because of the same reasons?

Comment 59

3 years ago
You remove themes, but there is still no real tab on top support(no title bar) for linux users(chrome does, opera does, even vivaldi does)...A 3 or 4 years old windows-only "feature"...Something that only "heavyheight" themes provides us.. Good jod...

Comment 60

3 years ago
Alfred, (In reply to Alfred Kayser from comment #58)
> In fact, themes are a trimmed down version of extensions, so these will also
> be killed then because of the same reasons?

Killing off Themes (as well as Panorama) is step 1 towards migrating Firefox over to Servo.  Because Servo doesn't support XUL at all, Mozilla is going to also have to completely remove the existing XUL-based extensions support, and then after that completely rewrite all of the UI in HTML.  Which means all new CSS to force HTML to act like XUL and all new JS to carry around all of those properties HTML elements aren't allowed to have, as well as rewriting everything that uses XBL or expects UI elements to act like XUL.  And on top of all of that they are merging Chrome WebExtensions into Firefox.  They expect to do all of this in about a year, which frankly is laughable.

Comment 61

3 years ago
I'm a designer of full/complete/"heavyweight" themes and I agree it's extremely painful and complicated to maintain them. If we find a good way to make things simpler yet as powerful, I'm all for it. If we just kill them with fire, I'm opposed. It really depends on the phrasing.

The move from XUL to HTML does not by itself deprecate complete themes at all, as CSS works fine on both XUL and HTML (actually the only reason why I started theme hacking was because it was CSS, which is a technology I knew from doing websites, even 16 years ago). What is an argument against the current way we are doing complete themes is that every theme necessarily needs to duplicate a lot of CSS that is in the default theme. Instead, complete themes should only need to augment (or even replace) those pieces that they actually need to change. We should still be able to do as powerful themes as we have right now, though - just like GreasMonkey can change anything on a website and Firefox OS add-ons can change anything within an app, a Firefox complete theme should be able to completely change the styling, even as drastically as my LCARStrek theme does. That said, not every theme designer should need to go that far, as many just want *some* changes and not *complete* changes to the look of Firefox.

I have some ideas on what we can do and I will make a write-up, but I have been traveling the last few days, need to catch up and I have a very busy job. I'll need to find some time to collect my thoughts and make something congruent out of them. I'm also open for discussions in person with someone at the Orlando work week if you're interested, all from first-hand theme design experience to ideas and issues/problems.

Comment 62

3 years ago
I don't know exactly what constitutes "complete themes", but when I saw "tab placement" as being part of that feature set, I recoiled in horror.  I am completely dependant on Tree Style Tabs.  If an update is going to make it impossible for this feature to exist, then I need to block all future updates on my work computer, like right now.  If I have to null-route every IP address owned by Mozilla to do it.

Please tell me that Tree Style Tabs is not going to be killed by this.

Losing Tree Style Tabs would have a cataclysmic impact on my productivity.

Comment 63

3 years ago
Why is Moz desperately trying to follow chrome?  Just focus on being good at what you're good at.  You will lose the game just trying to keep up with chrome, so don't play that game - DIFFERENTIATE!.  Be better at what you do best and give people a reason to use your software.  

I've been a loyal user of FF for a decade, but because you were the best and most flexible option.  If you become just a chrome wannabe, and drop all the things I NEED, why shouldn't I just cut out the middle-man and jump to chrome?

My point is, I stay with FF because it provides me something IE & Chrome don't, not because it's a knock-off.  Ruin that major selling point as you're on the path to do, and you'll also alienate your very loyal user base.

Comment 64

3 years ago
I agree Mozilla's actions have created a self-fulfilling quagmire.

FT DeepDark is a theme I use in both FF and Thunderbird (along with addons to control the brightness of pages) to reduce glare and overall nighttime light exposure, which is becoming a serious public health issue. Using the theme is necessary because (surprise!) Mozilla does not give a hoot about my chosen theme/colors in the operating system.

I'm not very confident Mozilla will "do the right thing" to supply an alternative. Its hysterical messaging about self-signed certs is a major impediment to the kind of self-administered security that SSH does so well... and its decision to move hover-over link address displays into tooltip-like boxes strips the UI of important security context (tooltips can be faked, status bar cannot). Although the highlighting of domain names in the address bar was a positive step, the other iconography there has no unifying rhyme or reason (adding a KEY near the address just because FF detected a login looks like a damaging move) so the advice I give people about browser security gets misinterpreted or disregarded.
My 2¢ from user POV. I use Pentadactyl and SimpleWhite (+ Classic Theme Restorer and Tabs on Bottom) – this setup makes my browser really minimal and with only most needed interface elements visible (top to bottom): OS titlebar, bookmarks bar (with extension's icons positioned there too), tabs, page content, and dactyl's status/command bar. But when I need to interact with other parts of the browser, my experience is consistent – the look and feel is the same everywhere.

So, that's what I'd like to still have in the future – to retain minimal look with my chosen layout of elements, with consistent look and feel in every part of the browser.

I've tried to approach making my own theme, after Whitehart, Le Breeze and Silvermel reached update–limbo, but the learning curve and lack of documentation turned me away.

If there was an solution to providing simplicity in developing new theme, consistency in l&f and flexibility of positioning interface elements for theme designer and/or end users – I'd love to see it.

Comment 66

3 years ago
Chiming in as a Thunderbird add-on developer, I'm very worried about what I'm hearing here - but it's mostly about the underlying processes: Loss of flexibility in favor of whatever it is a new implementation offers. Claiming that themes are "heavyweight" and calling backdrop images "themes" sounds like NewSpeak to me; and I'm thinking forward to the day I see a similar bug about extensions in general. Maybe I'm wrong and that won't happen, but, really - what'll our extensions be without XUL and XBL? I dunno. Since the corporatization, and even earlier I guess, I've learned to mistrust Mozilla - especially in making sea changes and transparency about process and motivation for them. Things are broken and messy enough for us with Thunderbird without needing to be trounced on again.

Comment 67

3 years ago
noise
(In reply to Mike Van Pelt from comment #62)
> Please tell me that Tree Style Tabs is not going to be killed by this.
Don't worry, Mike, it wouldn't be killed by this... Tree Style Tabs will be killed by other Mozilla decision in next 12 months :D (XUL deprecation)

Comment 68

3 years ago
advocate
If I wanted to use Chrome, I would've switched to Chrome already. I think Firefox should focus on being the best Firefox possible, not the next best Chrome possible.

- A LittleFox user for at least the past 10 years

Comment 69

3 years ago
advocate
(In reply to asim from comment #68)
> If I wanted to use Chrome, I would've switched to Chrome already. I think
> Firefox should focus on being the best Firefox possible, not the next best
> Chrome possible.


So much this.
Comment hidden (metoo)

Comment 71

3 years ago
Just a user chiming in here with another perspective...

Microsoft had actual solid usage data showing that many people never even clicked the Start button on a daily basis. Even fewer actually used it to launch programs on a regular basis. And almost nobody bothered to rearrange things on the start menu. They used desktop shortcuts, they used the Win7 "super task bar", and they used the search feature to find their stuff.

This data resulted in key design changes for the product that would become Windows 8

I'm not saying that removing these themes is quite as huge of a change as the above, but rather that the themes are part of Firefox's identity. Be very careful how much you read into the telemetry on large feature changes, it can backfire.

Comment 72

3 years ago
I can't help but feel that it would be better for Mozilla to put up a "Firefox is Closed for Remodeling" sign and just provide security updates until all that will be removed and changed and replaced is removed and changed and replaced. The Firefox that we all know today and have always had access to may not be the same in a year or so. I think that depends on how customizeable it will be and what can still be done with it. If add-on developers are not able to do what they've always been able to do which is pretty much everything and anything for the sake of the users desires and needs, then Firefox will just be another browser but with better privacy and security options and a better company behind it. 
I do believe that the Firefox devs intentions are all good, it's just that the process is and will be terribly bothersome and frustrating for users and add-on developers.

As far as themes, if themeing will be able to be done in a similar way that Vivaldi is doing it, then there's nothing to worry/complain about. Granted, I just browsed through Vivaldi's files and read some posts, but it looks dead simple. 
https://vivaldi.net/forum/all/3073-vivaldi-ui-customisations

If anyone wants to check it out, you can extract and run Vivaldi as a portable app (of course as opposed to installing it) from the exe. 

(In reply to Ed Hume from comment #40)
> You should be incorporating the Theme Font and
> Size Changer extension into your basic UI -- or at least the size part.

Vivladi is offering a UI scaling feature (default one) which is one of the features of Theme Font & Size Changer. Their implementation is actually better and smoother. It's really cool, and they're using some svg's in their UI. Perhaps Mozilla devs will look into it.
Comment hidden (metoo)

Comment 74

3 years ago
Firefox is my favourite browser, and I will explain why I need a heavyweight theme.

I run two Firefox profiles: development and production. I use standard for production, and DT DeepDark theme for dev. This allows me to immediately see which environment I'm working in, which prevents me from applying dev changes in my prod environment. This is really useful for me.

I see bubbleguuum@free.fr also likes DeepDark, so I had a look at that add-ons page. There are 180,847 users FOR ONE THEME. Surely there must be at least a million users who have installed one of the heavyweight themes available?

Please reconsider this idea!!!

Comment 75

3 years ago
(In reply to Duff from comment #69)
> (In reply to asim from comment #68)
> > If I wanted to use Chrome, I would've switched to Chrome already. I think
> > Firefox should focus on being the best Firefox possible, not the next best
> > Chrome possible.
> 
> 
> So much this.

Agreed. Where can I upvote this?

Comment 76

3 years ago
What effect, if any, will this have on GTK+ integration?
Comment hidden (abuse-reviewed)
(Reporter)

Comment 78

3 years ago
Kev has moved the feedback/discussion of this change to the proper addons forum at https://discourse.mozilla-community.org/t/planning-the-future-of-complete-themes/ so that this bug doesn't become an advocacy forum and we can do sensible moderation. I've restricted the comments in this bug to core Mozilla community (people with editbugs).
Restrict Comments: true
If I believe bug 384084 comment #42 (and I have no reason to disbelieve it), AMO download figures for themes (and according to the comments after that, for extensions too) are about 10% of what they ought to be.

That comment was written in November 2007, i.e., /in tempore non suspecto/.

Comment 80

3 years ago
So, Kev, 3 months later, was you able to find *any* theme developer who is happy with provided plan?
You know, for new "great" extensions at least Giorgio was found, any persons for new "great" themes?
Complete themes are now unsupported. A basic theming API is available from 57 onwards, that is planned to be developed even further over the course of 2018.
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED

Comment 82

10 months ago
I would rephrase that last comment as:
Complete themes are killed. A very limited theming API is available from 57 onwards, that is planned to be developed hopefully into a real theming API over the course of 2018
You need to log in before you can comment on or make changes to this bug.