Absolutely ridiculous of Mozilla to have swapped the menu and unified toolbars - surely you want a customisable toolbar to be the most easily accessible? Would someone from the Thunderbird team responsible for this change perhaps be good enough to explain their logic behind this change? Assuming there is logic behind the change - I can't see it...

Thanks for the tips! I agree it seems like this type of hoop-jumping shouldn't be necessary.

Unfortunately, it feels like we're ALMOST there with this solution. This moves the Menu bar back up to the top as desired, but the taskbar\fullscreen\close buttons drop down with the Unified Toolbar, instead of at the far upper corner of the window, like you'd expect. When the tabs bar opens, it pushes those buttons even farther from the corner.

> Unfortunately, it feels like we're ALMOST there with this solution. This moves the Menu bar back up to the top as desired, but the taskbar\fullscreen\close buttons drop down with the Unified Toolbar, instead of at the far upper corner of the window, like you'd expect.

I think That's exactly the reason why they didn't implement it in Thunderbird Core under Windows. Apparently it is difficult to work around the windows desktop theming system with these sort of hacks.

The CSS code did not work for me. Searched elsewhere and found an alternate one line code which worked perfectly.

1. toolbar-menubar{order:-1 !important;}

p.s I did not write "1." at beginning of code. For some reason it chose to interpret # as "1." Why?

again... #toolbar-menubar{order:-1 !important;} ^ yes

I still have the same problem...Under windows 11, it's not working for me. I have put the userChrome.css in my profile C:\Users\<name profile>\AppData\Roaming\Thunderbird\Profiles\kcv4lv5e.default with this code: /* ####### */ @namespace html url("http://www.w3.org/1999/xhtml");

1. toolbar-menubar {

 order: 1;             

}

unified-toolbar {

 order: 2;             

}

1. tabs-toolbar {

 order: 3;              

}

I have change toolkit.legacyUserProfileCustomizations.stylesheets to true but still the same.... Any idea?

Ok finally I have downgraded to 112 so no more headache... I might do an update if they go back to a "smart" interface.

Jpmarque, on your response, you omitted the chrome profile. The css file must be in a folder named chrome,

There was an add-on named "Rise of the Tools". It's author reports that 115 SuperNova should have changed this layout and therefore the add-on is obsolete. As of today the layout still has the toolbar below the menubar. And the add-on is disabled.

Does anyone know how to get rid of the awful "unified toolbar" completely - it's an utter waste of pixels. I can blank it except the dumb "hamburger menu" (which is one of those insufferable anti-innovations from mobile devices that has no place on the desktop), but I can't kill it completely. Blank it is less of a distraction but still wastes pixels.

The existing answers seem to have minor mistakes so here's yet another answer with all the details:

The decision to put menu below the button bar is probably a known design decision by the developers of the Thunderbird. If you feel that this is a bug or a problem, you can implement a workaround.

To workaround the problem, you have to open the Config Editor (at the bottom of the Thunderbird Settings view) and search for key toolkit.legacyUserProfileCustomizations.stylesheets (just type "stylesheets" in the search entry) and set it to true. This configures Thunderbird to load custom CSS style for the UI during the startup.

Now you need to locate the profile directory. The easiest way is to use Help – Troubleshooting Information and in the first table click the link "about:profiles" which contains the button to open the "Root Directory". This opens a file manager with lots of files and directories and you can verify you're in correct directory when the directory contains file prefs.js. If this directory does not yet have subdirectory called "chrome", you have to create such a directory (all lowercase letters). Inside that directory, you should create file called "userChrome.css" (note the uppercase C and everything else in lowercase) with the following contents:

/****** start of file ******/ @namespace html url("http://www.w3.org/1999/xhtml");

toolbar-menubar { order: 1; } unified-toolbar { order: 2; } tabs-toolbar { order: 3; } /****** end of file ******/

The idea is to configure given UI elements to have non-default order using the CSS property order where the smaller number will be rendered earlier in the UI. The UI is made out of XML elements where the elements are <toolbar-menubar>, <unified-toolbar> and <tabs-toolbar>. You can obviously order the elements as you wish but it seems to me that this is the only sensible order. You can reformat the file as you wish according to normal CSS syntax.

Menu bar wil be correctly positioned the next time you start Thunderbird (the CSS file is only loaded during the startup).

Adding the CSS file to the new "chrome" folder after changing that other setting to "true" as described above worked for me.

David the top 10 contributor should be put in charge of fixing these bugs in 115 so we could just get back to the look of 102 without all this hassle. Seems like this little fix could become a menu item in a future 115 update very easily if somebody would listen to user complaints. Then we could just reverse the order of this new unified toolbar with a single click instead of tracking down a work-around on this forum.

Yep, still propagating edits to undo the UI/UX horrors of 115 in my different clients. It is very tedious and the default should be "no change" - ever. Heretical, I realize, for those who hang their hats on UX novelty and the utter "brilliance" of their UI/UX visions, but there are very, very few UI/UX changes that are forced to accommodate a security fix or critical operational flaw and while I can abide the premise that UX refreshes keep the product hip and stylish and consistent with the latest trends, existing users are not UX trend chasers.

Updates should treat UX/UI models as absolutely sacred, absolutely inviolable. Sure, make the hipster graphics accessible, even advertise the availability in the update. Default to them for new installs, go for it, but do NOT change existing UI/UX on update. Ever.

Breaking an installed plugin is the sort of change that requires positive, are you absolutely sure, please consider the consequences, this could utterly destroy your productivity modal dialog. Do not default upgrade to utility destruction. It's just rude. And awful. And crappy, self-absorbed behavior. Respect your users, just a little, tiny, itsy-bitsy bit and stop screwing up their day-to-day experience with unwanted updates that break things they rely on forcing people to jump through hoops and to undo the damage and block it until it's fixed.

I'll wait until I get a startup message saying "all your enabled plugins have been updated to work with version x+n (where I'm on x), would you like to update to x+n?"

Thing is, eventually most of the really critical functionality gets restored. People figure out how to unfornicate the UI/UX changes, plugin developers eventually get around whatever random poorly documented API changes have been left like flaming bags of doodoo on their doorsteps. Existing users should only be subjected to functionality catastrophes by opt-in. Treat an API change like an unstable, unwanted beta. Complaints would plummet and there'd be good data on how many users reject the changes.

Breaking an installed plugin is the sort of change that requires positive, are you absolutely sure, please consider the consequences, this could utterly destroy your productivity modal dialog. Do not default upgrade to utility destruction. It's just rude. And awful. And crappy, self-absorbed behavior. Respect your users, just a little, tiny, itsy-bitsy bit and stop screwing up their day-to-day experience with unwanted updates that break things they rely on forcing people to jump through hoops and to undo the damage and block it until it's fixed. I'll wait until I get a startup message saying "all your enabled plugins have been updated to work with version x+n (where I'm on x), would you like to update to x+n?"

that may not be possible - because sometimes as "experimental" Add-on author I just have to make a version that is not backward compatible, so you can't install something that would break in the existing version in order to maybe be compatible, however there is an Add-on that you can install right now which reports whether your Add-on will be compatible, here:

https://addons.thunderbird.net/thunderbird/addon/addon-compatibility-check/

This will give you all the detail before you decide to allow the app to upgrade. Of course it will not protect you from possible restrictions such as Add-ons not being allowed to modify native Thunderbird buttons, which is something I had to work around in SmartTemplates with my own a little more complicated templates menu...

That's a great tool and thank you for referencing it! It doesn't solve a core philosophical failure that blights the development process and engenders much frustration and gnashing of teeth among the loyal, long term users: the assumption that what the developers believe is progress is what the users need, it ain't Brondo.

All of us who are (or were) users of TB (or any program) became so because it did something we needed it to do. Changing that function, even cosmetically, is going to hurt some users, even if there are valid and rational arguments why it is an improvement. In an environment that embraces the concept of radical consent in so many ways, stuffing an upgrade down the throat of an existing user without even a "hey, you want this?" is inconsistent with modern social norms of enlightened behavior.

It is possible, of course, to reject upgrades, but it is a huge hassle and means blocking all updates, including security fixes, just to avoid the addonpocolypse ones like 68, 78 and 115 that utterly destroy functionality for months, even years as the still (amazingly) dedicated developer community finds ways around problematic API changes (even accepting the changes are meaningful security changes or driven by FF codebase migrations that would be unreasonable to expect to preserve without doing a waterfox kind of fork). The default is to auto-update, as we do for most programs and most of the time without the radical trauma of some TB updates.

Not every update breaks add-ons but some do (incorrectly). Add-ons generally do not self-update on unsupported versions (correctly). TB should consider add-ons first class code citizens, not trivially disposable cosmetics. They are operational modifications to a vehicle not JC Witney double stick racer mods. Users had a legitimate need to modify the base operation of the program, sought out and applied a solution and it isn't acceptable to negate that effort without warning. Every TB update should do what plugins do: check compatibility and refuse to update until the user manually disables any incompatible plugins rather than simply disabling them for the user and saying "check it out! new! Sleek!" (sorry, nothing works anymore, but looks nice, huh?). All reasonable efforts should be made to preserve compatibility indefinitely, but that's obviously not always possible to keep the code base manageable and secure, and it is fine to inform users that there are important security reasons that require breaking plugins, but never, ever to do so without informed, affirmative consent.

As for UI/UX changes, I'd argue that the philosophy should be no change, not even trivial cosmetic ones, are permitted on an existing install. Ever. If you started with TB 0.1 your 115 interface should look exactly like this: https://blog.thunderbird.net/files/2022/07/Screen-Shot-2022-07-14-at-4.51.00-PM.png unless you explicitly gave informed, affirmative consent to UI/UX changes.

Creating a chrome folder, and a userChrome.css file, fixed the problem for me. Thank you

This may help people who need a step by step with images to help show where 'chrome' folder and 'userChrome.css' need to be created. A specific question was created: Supernova 115* - How to move the 'Menu Bar' above the 'Unified toolbar':

• https://support.mozilla.org/en-US/questions/1422908

FWIW, this can also be done with just this single line:

 #toolbar-menubar { order: -1 }

Less CSS is often easier to maintain but the chosen answer is also valid.

(wow, I strongly dislike the post editor in this forum. It's quite hard to make the output look good)

FWIW, this can also be done with just this single line:

  #toolbar-menubar { order: -1 }

Less CSS is often easier to maintain but the chosen answer is also valid.

(wow, I strongly dislike the post editor in this forum. It's quite hard to make the output look good)

Your code is not displaying correctly - hence check with the link I offered which contains solution: https://support.mozilla.org/en-US/questions/1422908

As a heads up. Using the code posted as a solution in this question may cause a problem if you open a message in a new window rather than a tab. Unfortunately the menu bar is may still below the toolbar in this particular window. Using the code I posted at the link does not cause that issue.

Thanks for sharing this. this post is really helpful for me .