Planning the Future of Complete Themes

Add-ons Themes
#1

A few days ago, a product planning bug was filed to document the removal of support for Complete Themes in Firefox. The intent of the bug was to start the process of outlining how Complete Themes must evolve to make life easier for theme designers, Firefox contributors, and users. Unfortunately, this intent was lost in the brevity of information supplied and the medium of communication.

As an organization, we didn’t meet our own standards of openness and discourse for a change of this magnitude, and we’ll continue to work to improve how we communicate to ensure we make our intentions clear with everyone from the start. The bug has garnered over 70 comments to date, and needs to be moved to a more appropriate platform that can support collaboration and dialogue. Going forward, we’ll be limiting comments on the bug and moving the discussion to this thread. The bug is linked here for your reference.

It’s important to understand that we’re not “killing” Complete Themes, but we are changing how they’re implemented in the name of simplification for developers and users alike. The current model has served us well for many years, but it has become unsustainable given the current rapid pace of Firefox development. Complete Themes as they exist don’t adapt well to our nearer-term engineering plans, including the transition from the XUL technology our current front-end is built upon, and this is an opportunity to improve upon a system that has a steep learning curve and declining use.

Our goal is to continue to meet the majority of user needs for Complete Themes today, while making it easier to develop and maintain them independently of technology platforms. Complete Themes must evolve, and we’d like to understand from everyone that has an interest in developing and using themes what they expect from Complete Themes as we continue to evolve Firefox.

We’re looking for feedback on what the supported customizations should be, and this is where you can influence the direction we take. We want Firefox to continue being the most customizable browser available, and we’d like to ensure we’re meeting as many of the needs everyone has as is possible. It is a complex task, and we don’t claim to know all the answers. It will take collaboration and discussion, and we want to be able to continue to support Complete Themes as Firefox evolves. Let’s start it in this thread, and see where it takes us over the next couple of weeks.

Thank you for your patience, and we’ll make additional information available on what changes are being made, why they’re being made, and when they’re being made. That information is still a work in progress, and we’ll post it here and the Add-ons blog as we develop it.

#2

The bug in question, https://bugzilla.mozilla.org/show_bug.cgi?id=1222546 , has (alas, but maybe expectedly) got more than its share of trolling and flamethrowing comments, but (happily) not only. I would still recommend reading, or at least skimming, the comments on that bug, quite a number of which made IMHO valid points about how to evolve complete themes and whether to altogether drop support for them (as the bug Summary still says as of this writing).

#3

Absolutely. There’s good feedback and points made, and I’ve read all of them. We can modify the Summary as well to make intent clearer, as well.

#4

The only reason I’m still using Firefox despite the noticeably poorer performance is because I can make it look exactly the way I want. If XUL has to go because it kills performance or is easily abused, fine, but a better alternative would be to disable the performance-killing features only, and retain everything else that XUL is so good at.

Keeping everything stylable using CSS would be the best option, but failing that, at the very least, we should have control over the following:

  • colours
  • borders
  • fonts
  • padding and margins
  • border-radius and border-width, with zero being an option
  • hiding elements we don’t need
  • adding elements we do need
  • displaying elements as icons, text or both
  • custom icons, including status icons
  • styling of addon elements, e.g. progress bars, text elements, etc.
  • (for animated elements) animation speed, with zero being an option

Firefox desperately needs not to be a wannabe-clone of Chrome, but a better Firefox, with all the features that made people like me Firefox enthusiasts in the first place. If Firefox goes the way of Chrome, with menus and features hidden away and someone’s misguided aesthetic decisions being forced on me, there wouldn’t be one good reason to keep using Firefox.

1 Like
#5

Firefox desperately needs not to be a wannabe-clone of Chrome, but a better Firefox, with all the features that made people like me Firefox enthusiasts in the first place. If Firefox goes the way of Chrome, with menus and features hidden away and someone’s misguided aesthetic decisions being forced on me, there wouldn’t be one good reason to keep using Firefox.

Indeed, trying to ape whoever is leading the field is always a losing proposition, and not only in personal computing. Firefox won its reputation by being (at least in the eyes of its users) better than IE, and to be better you need first to be different.

Chrome is best at being Chrome, IE is best (or worst :wink: ) at being IE, and so on. Firefox’s wealth of available extensions and themes, and their power at tweaking the browser’s functionality and its look-and-feel respectively, has always been a strong point, which went a long way toward making Firefox best at being Firefox. Let’s avoid jeopardizing that, even if it means that the underlying set of APIs and chrome elements cannot be turned upside-down every other day.

5 Likes
#6

As a Firefox complete theme author, I would really appreciate if in future it could be still possible to use CSS to style the Firefox UI and that complete themes creators could still have control over:

  • any colors of the UI;

  • all icons (included animated icons such as loaders, sync icons, etc.);

  • the full appearance of: tabs + tabs bar, toolbars, urlbar, navigation bar, buttons, checkboxes + radio buttons, dropmarkers, trees (included header rows), scrollbars, progressmeters, window caption buttons, splitters, panels + popups, text boxes + all other kind of fields, list boxes (included header rows), spinners, resizers and all "in-content"pages (new tab, add-ons manager, preferences, etc.).

In addition to this, could be also nice to have the possibility to:

  • add or remove animations on the customizable UI elements;

  • include “substyles” which users could apply through a complete theme options panel (this could allow complete themes authors to add specific and useful tweaks to make the complete theme appearance more flexible without the need of a companion add-on).

3 Likes
#7

I am ‘only’ a user of Firefox and have no experience in programming addons/designs for Mozilla products. I hope it is still possible to create and use the GNOME 3 theme for Firefox after the change.

#8

The main points I’d be hoping for would be, being able to implement pixel perfect themes (e.g. the oft mentioned FTDeepDark), innovative “themes” (Beyond Australis, hides the UI when not in use), minimal themes, and at least something that preserves the ability to do titlebar tabs (e.g. Hide Caption Titlebar Plus, though that might already be doing more on the Windows side rather than the themes/css side)

massive pluses would be stuff like, themeable themes (the prior mentioned substyles)

Regardless, best of luck in deciding the feature-set and implementing it, I’m really looking forwards to it.

1 Like
#9

I also use the Gnome 3 Theme for Firefox. In generall i think Themes that make Firefox look native in diffenrent desktop environments are important to have

#10

I’ve been using firefox before it was even called firefox, and this news could very well be the last straw. Ever since ff 4.x the browser has been getting worse and worse. It all started when someone at the company decided the best thing to do was to make ff less unique and more of a chrome clone. they added a bunch of useless features nobody ever asked for. they made the default theme more like chrome. they even adopted the dumb new version numbers for every minor release. but I begrudgingly kept using it, while at the same time becoming less and less happy with the direction the company was going.

then, the big change came along, I think it was ff v30? It was when they basically ruined most of the classic themes I used to love, and started to take away the flexibility that separated it from the other crappy browsers out there.

Afterward, people had to resort to using an extension JUST to get most themes to look like they used to. I almost called it quits then and there, after over a decade. But what of the alternative? I DETEST chrome with a passion. I detest how they lock you into one theme with hardly any flexibility, that bare, spartan ui. I detest the laughable attempts that they call ‘themes’. Theres a lot of other stuff I dislike, but basically what the hell happened mozilla? you guys used to be about options. about flexibility. THAT is what I loved about it. Now? they keep cutting back on the the reasons why we chose FF over other browsers, and for what?

2 Likes
#11

I’m not a developer, just an end user, and I just want to say that one of the main reasons I use Firefox is because I love my current theme. FT Deepdark and the UserStyles that go with it make my browser look great. I greatly prefer these dark themes to the boring light colored base Firefox.

#12

I would like to see a devedition theme like system, something that can style the whole Firefox UI in a restartless way, and that is painless for authors to maintain. Providing a system that exclusively allows overriding the browser CSS variables would be perfect. This is how the Developer Edition theme works (with some extra CSS code too). Of course, that would require work converting most of our UI to use CSS vars.

#13

The intent of the bug was to start the process of outlining how Complete
Themes must evolve to make life easier for theme designers, Firefox
contributors, and users. Unfortunately, this intent was lost in the brevity of information supplied and the medium of communication.

So lets take a look:

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.

So this means the decision has already been made before opening the bug (that is not a great way to do things maybe applying this new “great-or-dead” thing here will be useful).

This is being removed as part of the great-or-dead initiative and it seems that users are not the ones deciding what’s great, instead someone has decided for them that complete themes are not great but the incredibly limited lightweight ones are, it uses some pejorative language to make complete themes look bad so i did it too.

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

And now we have two options remove support completely or extend lightweight themes so we can change icons and colors.

So metaphorically It’s like replacing a car with a wheel and then adding a windshield.

Now for the constructive part of the comment:

  • Maybe something like “the alternative should be at least as powerful as the existing solution” can complement the “dead-or-death” rule, or whatever it is, it will probably make users happy.

  • Add more transparency so users can contribute before the decisions has been made.

1 Like
#14

Part of the decision has already been made. We are moving Firefox addons (themes and extensions) away from a model where you can perform arbitrary styling or scripting of the browser chrome. This is an engineering-driven decision, and it’s unavoidable and necessary for the long-term health of Firefox. Not only are we moving Firefox away from XUL, but we are likely going to make significant changes in the way the UI is structured. It is likely that some parts of the UI will be implemented using native widgets, and other parts will be implemented in HTML, but the exactly DOM structure may involve independent connected with well-defined API surfaces.

The current theming model where themes can make assumptions about the DOM structure, classes, IDs, and all that is not something we can support any more, and so we are clearly going to kill that. And we are going to do that quickly, so that we can proceed with the other necessary restructuring, including things like gofaster addons. I’d like to see this fully rolled out by Firefox 49 which ships the middle of next year.

What we haven’t already decided is the feature set of the replacement system, or what the API might lookslike. Kev, as the Firefox product lead for addons (including themes), is charged with coming up with a plan. There are a bunch of tradeoffs to make and I don’t envy his job!

I apologize that the communication didn’t work well. My goal was to file a bug to track work so that Kev could kick off a reasonable discussion and get feedback from the theming community. I’ll need to figure out a better way to provide context in the initial bug reports for each of these complex projects as we tackle them.

#15

The current theming model where themes can make assumptions about the DOM structure, classes, IDs, and all that is not something we can support any more, and so we are clearly going to kill that.

This is an excellent decision, and while the transition will be painful, it will make life easier for theme/plugin developers in the long run. “Engineering-driven decisions” is music to my ears.

It is likely that some parts of the UI will be implemented using native widgets

This is probably a bad idea, what with the arbitrary designs OS vendors may force on users in future.

I like the browser chrome to be as minimal and unobtrusive as possible, and almost fade into the background. Some people like big shiny toolbars and bright buttons all over the place. Others might want the toolbars to be toggle-able using a keyboard shortcut, or only show when they move the mouse. It should be possible to cater to all these groups using an API.

Even something a lot simpler, where users can create scalable bitmaps for buttons, toolbars, icons, etc. (Does anyone remember Winamp 2 skins, or Windows 7 visual styles?) would work well - as long as themers could define widget sizes, margins, padding and so on.

What if theme developers could export a file with all the necessary CSS selectors in it? This would save a lot of hunting around in DOM Inspector. I still break into a cold sweat when I remember trying to style tree elements in Firefox/Thunderbird.

I also really like the fact that presently I can add/modify keyboard shortcuts for commands, and add/remove items from popup menus. These things should also be configurable via an API.

There have been some really bad design decisions in the past, like a giant green animated arrow popping up whenever a download starts, that doesn’t provide any useful information and is visually jarring. (I think it was only in the nightlies, but that particular idea should never have seen the light of day). If I’d prefer to see small, styleable progress bars in the status bar for each download, I should be able to implement that. If someone wants a textual readout, they should be able to do that.

Keyboard navigation should be a first-class feature. I remember when logging in to a website for the first time, I could tell Firefox to remember the password by pressing Alt-R on a familiar dialog box. Then the dialog box turned into a fancy, non-theme-compliant popup, and Alt-R no longer worked. I remember when I could clear the download history by pressing Alt-C on the download history dialog. Can’t do that any more. Users should be able to define their own keyboard shortcuts in text-based config files.

To do something as simple as take a screenshot in Firefox, I have to either open a console and type screenshot --fullpage, or open Developer Tools then hunt-and-click on the camera icon. Why shouldn’t I be able to edit a text config file and specify, for instance, that Ctrl+PrtScr = DevTools.Screenshot ? Again, it should be easy to export all available commands to a plain text config file, like cvarlist and cmdlist in Quake.

As another example of why this is necessary, Thunderbird has some powerful keyboard shortcuts that don’t use any modifiers like Ctrl or Alt. So if I mistakenly think I’ve focused a search box and start typing, before I know it, a bunch of emails have been archived, or marked as junk, or something of the sort. This has caused me a great deal of unnecessary pain a number of times.

I should be able to enable/disable addons via user-configurable keyboard shortcuts. Presently if I want to disable, say, uBlock Origin, I need to open the addons page, then hunt for uBlock Origin, then click Disable. Why can’t I define Ctrl-Alt-U to toggle uBlock?

There’s no need to put esoteric options in the Tools > Options dialog box, about:config is fine. If a high level of configurability is a pain to provide support for, just provide a button labeled “Reset all UI changes” - like “safe mode” for the UI - and require users to click that before they ask for support.

Make configurations easily export- and import-able. uBlock Origin does this very well. One-click exports to/imports from human-readable text files.

And please, please, please make the status bar an integral component. Those who don’t want it should be able to hide it, but for some of us it’s essential.

Lastly, keep some sort of barrier to entry to being a theme/addon developer. Have a strict API, unforgiving of errors and intolerant of bad practices. That’ll go a long way towards not letting people create themes/addons that are badly designed and built.

#16

Unfortunately the decision to phase of XUL was made in a similar manner, suddenly. So, saying that the decision has already been made, is a half baked excuse. Complete theming is one of the key features of Firefox and theme combinations like vimperator and FT Deepdark are one of the main the reasons of using Firefox. Yes, you need to move forward, but the reasons provided for removing themes are unsatisfactory. Alienating the userbase worked out quite well in the past for Nokia. (It didnt) And if Firefox is to stay and you really want feedback, then where was the polling to see whether you should go with the process. Firefox tries to market itself to be open but it sure doesn’t feel like it. It just feels like another chrome follower now.

2 Likes
#17

As long as Classic Theme Restorer and FT DeepDark still work, I’ll be happy regardless of the technology underneath that makes them work. So extend the capabilities of “lightweight” themes to whatever extent is needed to make that happen. I do not want a browser that looks like Chrome, I want the Classic Firefox look plus a dark theme like FT DeepDark for reading fics on AO3 (I use AO3’s Reversi dark theme and having the browser chrome dark as well makes for a much more pleasant experience).

#18

Most of you just don’t get it do you? 100% of current complete themes will die period end of sentence.
And then any extensions using XUL will die end of sentence.

I notice Mozilla has managed to bury this “discussion” in the boonies where real themers are very few on the ground.
http://forums.mozillazine.org/viewforum.php?f=18
You know where they hang out why no “Reaching out” there?

#19

100% of current complete themes will die period end of sentence.

Well, yes, removing XUL support will break every single extension that uses XUL. But popular addons will be ported to the new API, which will be a lot of work, but after that it will be much easier to maintain addons/themes.

XUL is clearly unsustainable and needs to go if Firefox is to survive. That’s a given. The only thing that needs to be discussed is what features to support in the API and how to best implement them.

Mozilla are trying to do the right thing, let’s not crucify them for it.

#20

Sorry Mozilla have a long long history of not “doing the right thing” this is just another example of spin doctoring. Six to twelve months down the track we will still have zero theming ability and almost zero extensions. I will wait for the not enough man hour excuse and the limited resources excuse plus the old the developer has moved on chestnut.