We've got way too many toolbars and many of them are not even used as a bar of tools.

The message header toolbar is an odd place to begin since it actually has things that someone might customise, but that's where I began.

In this patch nine toolbars have been converted away from <toolbar>.

• Task actions toolbar
• iMIP toolbar
• Folder pane toolbar (removed completely)
• Content tab toolbar
• Chrome tab toolbar
• Gloda tab toolbar
• Attachments toolbar
• Message display toolbar (single-message and multi-message)

Richard, please check the toolbars listed in comment 2 and see if they still look alright. I've removed a lot of fluff from the CSS that I don't think is used any more after this change.

Wait, what? Dow do you determine which toolbar is no benefit over vbox? Also why is the folder pane toolbar removed? How are users then supposed to put items there?

(In reply to :aceman from comment #6)

Also why is the folder pane toolbar removed?
How are users then supposed to put items there?

They are not. Why on earth would anyone do that?

Maybe some background is useful here. One of the problematic xbl removals still to do is related to toolbar.xml. This is all code that didn't over the years move to do similar things as what Firefox does. Like how Thunderbird's customization is very very different (and for many things buggy) compared to the Firefox one.

We have a bunch of things that are customizable toolbars "just because". There is no end use value in being able to customize e.g. the attachment bar. Even the main toolbars do not really give much customization value: look at compose - what you can add from there is just nonsense.

So I think the direction should be toward customizable toolbars more like what Firefox has (not sure if it can be exactly the same). But for the UI it should also be more about providing sensible buttons and focusing on providing real features, not keeping back developments by keeping too much distraction code such as letting people add Copy, Paste, or a Print button.

As for the header view toolbar, that I can imagine someone wanting to customize - but I still think providing sensible defaults there will keep almost everyone happy.

(In reply to Magnus Melin [:mkmelin] from comment #8)

(In reply to :aceman from comment #6)

Also why is the folder pane toolbar removed?
How are users then supposed to put items there?
They are not. Why on earth would anyone do that?

Because it was specifically added for the purpose. It is empty by default, but you can put e.g. folder mode picker there.
See bug 700976.

So I think the direction should be toward customizable toolbars more like what Firefox has (not sure if it can be exactly the same). But for the UI it should also be more about providing sensible buttons and focusing on providing real features, not keeping back developments by keeping too much distraction code such as letting people add Copy, Paste, or a Print button.

OK, but then make that technical decision publicly and in wider group, not in a random cleanup bug falsely claiming they are unused. They are used and useful. If we have to drop them, at least make it clear where the blame lies.

I told you there'd be complaints. :-P

(In reply to Richard Marti (:Paenglab) from comment #7)

• the header view toolbar is no more customizable and now tooo tall with
  icons above text.
• the attachment toolbar is also too tall. Please set text beside icon like
  before the patch.
• the multimessage header buttons are too tall too.
• the IMIP bar buttons are also too tall.
• the task actions toolbar buttons have the same issue.

Huh. I had them looking as expected. Maybe I screwed something up again afterwards.

Okay, it's a platform thing. I did think a lot of that CSS was oddly in platform-specific folders.

Now with the styling applied to all platforms, and actually passing mozmill.

(In reply to :aceman from comment #9)

Because it was specifically added for the purpose. It is empty by default,
but you can put e.g. folder mode picker there.

Talk about non-intuitive UI. I would not have figured this out.

OK, but then make that technical decision publicly and in wider group, not
in a random cleanup bug falsely claiming they are unused.

Haven't the follow-Firefox-as-much-as-possible policy been in place forever? I don't think this bug ever said unused. Unneeded is something else.

Now with the folder pane toolbar hard-wired.

If you remove the disabled tests in test-header-toolbar.js, you will lose the ability to reproduce the crash from bug 1530207.

Let's see if we get that fixed first.

I've just worked out that the changes to mail/test/mozmill/message-header/test-header-toolbar.js remove all of the tests from that file, so the file itself might as well be removed too.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/806cef92b2a0
Stop using <toolbar> where it provides no benefit over <hbox>; r=mkmelin

https://hg.mozilla.org/comm-central/rev/220013624fc6ff0751026eec71c6dad2a55585bd
Backed out 2 changesets (bug 1535265) for test failures. r=backout

Sorry, but this made the tree real colourful. I'd say the Z3 is certainly caused here, maybe the Z2 too. That failed before on Windows, and that might be related to M-C action:
2ccc66480643 Andreea Pavel — Backed out changeset 643f81697dae (bug 1444447) because it causes graphical corruption in menus, see bug 1444447 comment 25 a=backout

In chronological order:
Push without this patch:
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=13e57aaba5a0119ca8658b1f22202bf7e3d02b39
Push with this patch:
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=e72379771e3f31c9099175254bdde76d48458556
Push without this patch after backout:
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=220013624fc6ff0751026eec71c6dad2a55585bd

I don't see a try run for this bug and you weren't available on IRC, it's Good Friday after all, hence the backout.

That returned the tree to the "usual" failures.

Okay, I fixed the brokenness. Now with a recent Try run instead of the out-of-date one that had me thinking there was a recent one.

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/3bdcf6d1a445
Stop using <toolbar> where it provides no benefit over <hbox>; r=mkmelin

Is there a reason the message header toolbar in particular was rendered non-customizable in this patch? It's probably the single most important toolbar to customize, since it has all the buttons for operating on a single message, and is in a much more space-constrained environment than, say, the main toolbar. This is especially important for non-English locales, where the button text is often longer than English. Previously, you could switch to "icons only" or remove some buttons you don't need, but with this patch, there appears to be nothing you can do. Even in English, it causes problems the Vertical 3-pane layout unless you make the message pane pretty wide.

I can understand removing some of the other toolbars (though I don't like it, since part of the reason for those being customizable was for easy extension hooks), but not the message header toolbar. Since Thunderbird still has one customizable toolbar - the main one - it's not like we can totally get rid of the <toolbar> element anyway. The additional cost/pain of keeping 2 <toolbar>s around seems pretty minimal compared to keeping 1 around.

So given Jim's comment and the discussion on the Maildev list, are we going to revert some of this stuff?

I have no preference either way, and so I'm leaving this debate to the person who requested the change in the first place.

It's true the message header toolbar is more of a toolbar than the other ones.

Let's continue over in bug 1553427.