+++ This bug was initially created as a clone of Bug #1553427 +++
+++ This bug was initially created as a clone of Bug #1535265 +++

In bug 1535265 the message header toolbar was removed in TB 68. In bug 1553427 it was restored for TB 68 during the 69 cycle, leaving TB 69 and later without customisation facility for the message header.

There has been some discussion about how to replace the customisability in bug 1553427 comment #23 and subsequent comments, so here is the bug to implement something.

One thing worth thinking about here: in addition to the message header toolbar, there's also the multimessage header toolbar (it's the thing you get when you select multiple messages, and shows "Archive" and "Delete"). If we make a new customization widget, it'd be nice if we could support customizing both the regular message header toolbar as well as the multimessage version. See also bug 519671 which requested this and has a very old patch and somewhat-hacky patch I wrote.

This would have the side benefit that we could move the "Tag" button from the main toolbar to the message/multimessage toolbar if we wanted to. Putting the "Tag" button in the main 3pane toolbar always seemed like a weird fit to me, since it's designed to operate on selected messages, and every other button like that is in the header toolbars. Since the multimessage header toolbar isn't currently customizable, I never pushed very hard to make this change; it would have just taken up extra space without a way to get rid of it.

Using the CompactHeader addon, you can add different buttons, normally only available in the main toolbar, to the header pane toolbar, e.g. the tag button.

But of course, this requires the header pane toolbar to be customizable at all. So at the moment, it does not work with the daily builds (Thunderbird 69)

(In reply to Jim Porter (:squib) from comment #1)

This would have the side benefit that we could move the "Tag" button from the main toolbar to the message/multimessage toolbar if we wanted to. Putting the "Tag" button in the main 3pane toolbar always seemed like a weird fit to me, since it's designed to operate on selected messages, and every other button like that is in the header toolbars. Since the multimessage header toolbar isn't currently customizable, I never pushed very hard to make this change; it would have just taken up extra space without a way to get rid of it.

The same applies to the star toolbar button.

Let's call this a regression since it's still working in TB 68 (via backout). Magnus & Alex, we're at TB 76 now, is this bug on the radar?

Hey, thanks for the heads up on this bug.
What's the objective on this? Do we all agree that having a customizable toolbar in the message header is the proper solution?

I personally don't have a strong opinion on this and I understand both point of views of having a customizable message header area, or having a more polished and optimized static area that doesn't require customization.

Well, see comment #0 and the bugs and comments referenced there.

I think we shouldn't make it customizable.
There is the https://thunderbird-webextensions.readthedocs.io/en/latest/browserAction.html add-ons can use to add buttons
We should make sure the More button works better, maybe like the toolbar overflow in Firefox (the >>>).

Compact header was brought up above: seems to me it doesn't really make a difference to it what we do wrt customizability. I guess it wanted customizability since that worked well with overlays, but overlays are now also gone. Going forwards it would have to touch the DOM manually, e.g. just remove the nodes that are there and add it's own and then customizability something to worry about.

I'd like to take this to do some mock-ups to refresh the UI and properly reorganize the buttons.
If you guys agree I can kick off the conversation on the UX topicbox so this change won't come as a surprise and we can collect feedback to satisfy the needs of everyone (high hopes).

(In reply to Alessandro Castellani (:aleca) from comment #11)

I'd like to take this to do some mock-ups to refresh the UI and properly reorganize the buttons.
If you guys agree I can kick off the conversation on the UX topicbox so this change won't come as a surprise and we can collect feedback to satisfy the needs of everyone (high hopes).

I agree.

I would like to be able to see icons only, remove Archive, Forward, Reply (when Smart Reply is already in the email header), Reply (when Followup is already in the newsgroup post header) and probably Junk from some accounts.

Users have been able to do that since I can remember and still can using version 68.8.0.

It's also important to be able to 'restore default set' - I have often had to advise people to use this in the support forum - or choose whether you want text and icon or either. Personally, I want to see both text and icon, but others may want to customise otherwise.

Whilst 'Tag' is a per message and I have seen support forum requests asking to be able to set a 'Tag' whilst composing an email, I usually tag something that is in the 'Thread Pane', so Tag in it's current location works well for me. But, I can see 'tag' would be useful option in the Message Header area and also when composing a new/reply email. So adding 'tag' to the 'Customise' would be a good option.

I agree with the common sentiment on this bug that we should continue to offer message header customization, because different users have different needs.

• On small screens or using TB side by side with another app, having "Icons only" (vs. Icons and Text) is important.
• Removing buttons which I'll never use is important.
• Adding buttons which are important for my workflows is important.

(In reply to Anje from comment #16)

It's also important to be able to 'restore default set' - I have often had to advise people to use this in the support forum - or choose whether you want text and icon or either. Personally, I want to see both text and icon, but others may want to customise otherwise.

+1

Whilst 'Tag' is a per message and I have seen support forum requests asking to be able to set a 'Tag' whilst composing an email, I usually tag something that is in the 'Thread Pane', so Tag in it's current location works well for me. But, I can see 'tag' would be useful option in the Message Header area and also when composing a new/reply email.

Please check if there's a bug for tagging when composing (assuming that's technically feasible), otherwise pls file it.

So adding 'tag' to the 'Customise' would be a good option.

For message reader of TB 68, Tag button is available from toolbar customization of msg header toolbar (implemented by bug 456169).

User in Support Forum is requesting a need to Customise the buttons in the Message header.
https://support.mozilla.org/en-US/questions/1297459

Indeed there have been quite a few requests. We'll see more once auto update is enabled. Is this in some ways a duplicate of bug 766295?

However, in some cases (and they may not articulate this) it's more about wanting shorter headers ala bug 634831 (I'm in that camp).

There are also bug 466025 and bug 543954

Please note that bug 1658559 is not about reinstating and redesigning the Customise Message Header which is missing in 78.

It is about reimplementing the option to 'Add new toolbar' to the Mail Toolbar Customise in 78. This option is suddenly missing , perhaps forgotten to get added and needs putting back.

Not sure if this is also effecting the TagToolbar addon, as that used to have option to add new toolbar and this no longer works or cannot be added either and addon has been updated to work with 78.

Being able to 'Customise' is the biggest bonus that thunderbird offers because it is all about what the user wants. Kudos.

For TB 68 we simply backed out bug 1535265 in bug 1553427 to gain one year time. Sadly that time wasn't used to implement a new solution. IMHO the toolbar should just be restored until an acceptable replacement arrives.

(In reply to Jorg K (CEST = GMT+2) from comment #22)

For TB 68 we simply backed out bug 1535265 in bug 1553427 to gain one year time. Sadly that time wasn't used to implement a new solution. IMHO the toolbar should just be restored until an acceptable replacement arrives.

That sounds like common sense.
Implement the old until the new is ready.

I cannot fathom why it was removed in the first place. There have been many many occasions when I have had to help on support forum to reset to default because something had gone wrong.

Can the old be pushed forward to be on next update until a suitable new model is finalised ?

While one could get to an agreement that customizability of the header pane (without Add-ons) is probably just another piece of clutter, we definitely need the "Icon only" mode. Because the header area is very small in 3pane view and some of the real-estate is needed for additional tools (such as DispMua).

So my proposal is at least make the text removable (icons only mode), and, to be even more minimalist, I would not display the labels as a default setting - the tooltips are sufficient for Newbies - just look at many webpages and apps that use icons, with well-designed Icons they often do not have labels either. There are many users who have additional functionality in the main toolbar (a wider area) and do not understand that they are MISSING FUNCTIONS because the buttons are hidden in overflow because the labels take up so much screen space and buttons start to go missing to the right.

imho it makes little sense to have even more labels in the header area - the header area should be mainly about the headers! And imho that area of the screen (right half - center of the screen) should not distract from the messages list/message preview - that's where the reading should happen.

I detest only icon. Text is a must. There is nothing more of a pain than being presented with a bunch of icons and needing to constantly hover to locate tooltips. But if you like that then it should be an option for you.

There is nothing more difficult than trying to explain to someone via a Support Forum or over a phone what a particular icon looks like, but if you say click on button that says 'Reply' then they know what to do. We are talking of coping with an extensively wide range of skillset and abilities and needs. Thunderbird needs to incorporate it into it's very fabric. So saying newbies can use a tooltip is not understanding someone elses situation at all.

Nothing is cluttered on my view - far from it I have plenty of space, so everyone obviously has different needs.
The logical conclusion is to offer options to cope with differents needs.
Adding back the ability to add a new toolbar onto the 'Menu Bar' for anyone requiring additional space for any reason should be considered especially as it would solve more issues than being considered here. Then those who do not want the Message Header being further cluttered can use it. It is a perfect solution for those who actually use the Message Pane and do not open in a new tab or window. This also should not have been removed in the first place.

This customise option in the Message Header should never have been removed, it's not just about a few icons with or without text. I cannot think if one reason to make it impossible to reset to default when it all goes wrong and it does.

Thunderbird is the tool that offers flexibility for everyone, we should be proud of that and enhance it, but there are some who appear to dismiss this hence why there is no customise option currently in 78 - no ability to reset to default if there's a problem ; no ability to add a toolbar to cope with those people who have a load of additional icons and options like tags which they want separate with easy access to enable.

Please just apply some common sense and just add the old version back and it will solve a bunch of problems in one fell swoop.
Then work out what additional elements need to be applied in an upgrade.

Please make it clear in the release notes for versions 78.* that this feature has been removed. It is not simply a regression in the sense of an error that will be fixed for the user in the short term.

re : It is not simply a regression in the sense of an error

It would seem to have been removed by accident or oversight or probably because the person who made the decision to remove it, does not actually use it and therefore does not or cannot comprehend why others require it. In the same way that it is no longer possible to create additional toolbars Or why virtually all Options/Preferences are now lumped into one General scrollable heap. Someone is making what allegedly appears to be some very unreasonable decisions despite there being an obvious support to this bug.

There exists an add-on to customize the buttons: https://addons.thunderbird.net/thunderbird/addon/msghdr-toolbar-customize.

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

There exists an add-on to customize the buttons: https://addons.thunderbird.net/thunderbird/addon/msghdr-toolbar-customize.

Thanks for pointing that out, but sorry that is blanket add-on that applies to all types of accounts.

I had/like different buttons for different types of accounts and removing customization broke that capability.

Just to add another reason why this is an important feature: When forwarding an address from GMail, Google sneaks in list headers. On the one hand, this allows any third party mail server to send from the original address through Google, on the other hand when it is not needed, it leaks sent messages to Google.

As such, it would be very useful to replace the smart-reply button with reply-all to avoid accidentally compromising privacy.

(In reply to WaltS48 [:walts48] from comment #30)

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

There exists an add-on to customize the buttons: https://addons.thunderbird.net/thunderbird/addon/msghdr-toolbar-customize.

> Thanks for pointing that out, but sorry that is blanket add-on that applies to all types of accounts.

> I had/like different buttons for different types of accounts and removing customization broke that capability.

After using this extension and becoming more familiar with it, I can do everything I did before, but having the original feature back would be nice.

Why are we removing basic functionality that has been available for eons, to replace with an Add-on ?

It is not an improvement to deliberately and willfully create situations, by removal of code, where addons become vital for basics or required because they fix a bug as in this instance.

Removal of customise showed a complete ignorance and lack of deference for language and the impact of spelling variants; not all languages have words that are short. eg: German where the button labels are much longer than in English.

bug 1670934 -Reduce width of Message Pane to the point where the Message Pane buttons 'Reply, Forward, Archive,Junk, Delete, More' start to occupy full width, then as you further reduce the width, the vertical scrollbar will disappear completely and Buttons and Header and text/Body content of message becomes truncated. Cannot get access to full content.
So the addon is now required to get around this bug which previously could be remedied via Customise.

I'm one of those 'helpers' who sees the impact of this in the Support Forum and it gives me no pleasure in taking the backlash from users who now find basic usability preferences being removed for no good reason. Especially when they can be implemented so easilly.

When is 'Customise' going to be implemented properly again ?........because in the Support Forum users are asking.
Removal of customise was blatantly a poor decision. But who has the gumption to acknowedge it and fix it.

At least the flag thunderbird_esr78 = affected is set. But I think it's unrealistic that it will be fixed for 78 ESR. So we will wait 1 year for Thunderbird 90 and put people off for a long time.

It is good that Thunderbird is being developed significantly again. And in the long run it is certainly a good thing that the internal code is modernized. You know, I've been with @mscott since before version 0.1 as a german translator. But Thunderbird 78 has unfortunately become the biggest disaster. And I don't mean the development towards MailExtensions.

Version 78 is also now with version 78.4.0 at best a beta version with still so many unforeseen problems with light / dark theme, certificates, OpenPGP and support of CalDAV / CardDAV.

It is sad to see this. I strongly recommend a more stable release for Thunderbird 90. We currently have too many construction sites on the program at the same time. This can not go well.

I'm getting a load of not very happy people in the Support Forum now that 78 has been made available as an auto update.
Removing a customise option that has been around for eons is not being well received.

There should also be an option to move the toolbar to the left or right, as the old CompactHeader extension allowed for. Usually there is more space on the screen in horizontal direction than in vertical direction, at least in classic and wide layout.

Still not planned ?

(In reply to Florent from comment #43)

Still not planned ?

See comment 29 and comment 34.

(In reply to WaltS48 [:walts48] from comment #44)

(In reply to Florent from comment #43)

Still not planned ?

See comment 29 and comment 34.

But the downside of relying on plug-ins such as Message Header Toolbar Customerize is highlighted by user Bob's review comment of Feb 22, 2021, where he notes that it stopped working with the release of Thunderbird 78.7.1. Synchronization cannot be guaranteed. Basic fucntionality, especially that which already existed prior to v78 really should stay with the core product. Please restore.

For me extension not work correctly. Button "Reply for all" or "reply to the list" not show.
I know it's not mozilla problem but regret removal of this simple personnalization :(

(In reply to Florent from comment #46)

For me extension not work correctly. Button "Reply for all" or "reply to the list" not show.
I know it's not mozilla problem but regret removal of this simple personnalization :(

Did you file a bug report or look for one on the extensions Issue Tracker?

Are the messages where you don't see the buttons list or multiple recipient emails?
The buttons in the message headers change for me depending on the message.
List and multiple recipient messages show those buttons. Single recipient messages don't show them.
Next to the Delete button is a down arrow with "Customize Toolbar" at the bottom when you view the menu items.
Open it to get the extensions options. You may just need to show or hide the buttons.

We have restored this feature in the upcoming release of Betterbird in August 2021. Our patch can be found here (pending some fine tuning):
https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/1556261-header-button-customisation.patch
Mostly based on what was done in bug 1553427. This makes it necessary to remove bug 1669063 first:
https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/1556261-backout-1669063-header-toolbar-responsive.patch

Are there any plans when this will be re-implemented in Thunderbird? I don't use Betterbird (even don't know what this is), I only use Thunderbird. it would be nice if this feature can be reimplemented there.

12 duplicates should be a clear indication that users want this back.

I'm taking this bug and giving it a P1, I'm gonna start working on this from next week.
I won't be re-implemeting the customizable toolbar as we had before, that's gone and we won't put it back, BUT, we're gonna do something better.

This is the plan:

• Update the message header to use a semantically accurate HTML5 structure.
• Clean up the layout by leveraging CSS grid and flexbox, therefore dropping XUL .
• Implement options in the more button to show/hide the preferred buttons.
• Implement option to toggle between icons + label, only label, or only icons view.
• Make it properly responsive to avoid annoying overflows.

Little mock-up of what's coming

(In reply to Alessandro Castellani [:aleca] from comment #51)

I'm taking this bug and giving it a P1, I'm gonna start working on this from next week.
...we're gonna do something better: This is the plan: [snip]

That's awesome; go for it, Alex!

Random quick notes on the screenshot (interesting stuff, looks nice and modern):

• Your "long" subject line isn't very long at all. I bet having the subject next to the buttons has been tried before and dismissed for good reason: This won't scale well at all with really long subjects, or with icons + label. Also, it'll cause unnecessary layout problems for limited-width Thunderbird windows, e.g. half-screen: A narrow subject width will cause extra vertical churn to accomodate the full subject. Instead, having the sender next to the buttons and the subject below that (next do date, as currently) scales much better for the latter and also avoids that space-wasting gap between sender and date.
• What happened to the recipient stars which allowed fast adding to AB and also indicated the AB status of a recipient?

Looks awesome Alessandro. Once there is a beta I would like to test to see if I can still add my Smart menus (which load external templates) or whether I need to do changes - at least until we find an API compliant way of doing something similar.

As regards running out of space for the subject - should the font size scale if it gets too long or are you considering wrapping vertically?

That looks nice indeed!

Adding to what Thomas mentioned, WebExtensions can add buttons next to those header buttons as well, so the space available for the subject line can be even less.

I'm looking forward to an improvement. But I'm of the opinion it is already a pretty good design - it just needs a few tweaks to make it awesome.
But can the changes be mindful of the following issues and ideas.

'From' needs to be at the top not Subject.
The From is always the first thing you check - who is this email from before you do anything else.
It's not so important if you have a folder for filtered emails eg: Thunderbird forum emails because they are all from the mozilla thunderbird forum. But I think it would be rare for people to have all their folders designed to cope with one 'From' per folder.

Some subjects can get stupidly long especially if people start to insert a load of emoji etc.

Not so sure about the far right 3 dot icon - one of my personal hates - I just detest it. It's not so easy to see and does not fit well with all the other icons - it looks out of place and the 'v' downward pointing arrow is extensively used in Thunderbird, so it is generic - I would prefer to keep it for drop down menus.

What happened to the recipient stars which allowed fast adding to AB and also indicated the AB status of a recipient?

Agree - the Address Book star icons need to be included.

Idea/request for enhancement:
It may be handy to include whether email has been 'starred' as this information is not visible in email header - only visible in Thread Pane, so if viewing in eg: new tab, you would discover this only after using Message > Mark > Add Star to see if it is starred.
Unfortunately - if message has already been starred and you use the shortcut 'S' without checking first, it actually removes the star.
So I'm asking to include whether starred in the same way tags are displayed.
Can a large yellow star be displayed if starred?
Also asking would it possible to be able to add star to email by clicking on a large outline of yellow star to get an infilled yellow star like you do in the Thread Pane starred column?

If user chooses the 'Text buttons+icons' option.
Currently, select email in Thread Pane.
If the 'From' is too long:
The text button & icon remain in that state AND the 'From' is auto moved to next line to facilitate this. - That is ok. But....
If the 'From' is not too long:
FRom and text buttons+icons are shown on same top line - this is ok.
However, if you reduce the width of Thread Pane/Message Pane area, the text buttons+icon disappear and become icons only, - Not ok
It would be improved if the 'From' were to drop a line and the 'text button+icon' be still visible. In other words same as if the 'From' was too long when initially opening email.

Then a tiny bit more reducing of width forces the From to jump back onto the top line and all the text buttons+icons suddenly become icons only - Not ok - nothing should have occurred because there is sufficient space for the 'Text buttons+icons' on one top line.

The From jumping up and down as you reduce/increase window width is wrong and visually disturbing.
Either there is sufficient space for From and the 'Text buttons+icons' on one top line or there is not.

The change to icons only should only occur if the width has been reduced, From is already on next line and there is insufficient space for the text buttons+icons to be displayed on their own on the top line OR the user selected the icon only option.

Finally, please note : Currently, if the Thread Pane/Message Pane width is too narrow then you lose the vertical scroll bar and the horizontal bar is unable to show fully to the right, so email content on right is not visible. In addition the 'Text buttons+icons' OR 'icons only' (as is the current situation) simply get cut off with no access to them.
Whilst you or I may not use Thunderbird with such a narrow reading area, some people do and they come across this defect in display.
Query: should there be a minimum allowed width which is just wide enough to show all selected icons ?

What about being able to adjust the order of the toolbar buttons? That was the real problem for me. Having the Smart Reply button after the Reply button completely breaks my muscle memory and has always resulted in my sending replies to the wrong destinations. My deeply-ingrained habit over more than a decade has been to hit the first button labeled “reply” in the toolbar, which used to default to replying to a mailing list in a list message, to all recipients in a group message, and in the case of simple messages the first button was just the standard Reply button. All of these actions are what I want the vast majority of the time. Having the Smart Reply button first is the only way this continues to work for me, and this is why I needed the customization ability. Otherwise, having to remember to stop and think about which button to press every single time I want to send a reply requires an excessive amount of cognitive load because the toolbar button I want to use in the most common case constantly changes position. Such a UI is a huge nuisance.

Your "long" subject line isn't very long at all. I bet having the subject next to the buttons has been tried before and dismissed for good reason

Yeah I know :D, that's why what I shared was just a quick mock-up for the styling direction.
Moving elements in different location will be trivial with a new HTML structure and CSS grid.

What happened to the recipient stars which allowed fast adding to AB and also indicated the AB status of a recipient?

Nothing to fear, I just forgot to add it to the mock-up. No current functionality will be removed. (I'm attaching a slightly more refined mock-up to show what we can do).

Looks awesome Alessandro. Once there is a beta I would like to test to see if I can still add my Smart menus (which load external templates) or whether I need to do changes - at least until we find an API compliant way of doing something similar.

Hey Axel, maybe this would be worth exploring in a dedicated bug, something like "Create message header API for..." with a list of all things you'd like to be able to access to. Overall, those buttons will remain as they are, so there shouldn't be any issue with your add-on, other than maybe some styling tweaks.

As regards running out of space for the subject - should the font size scale if it gets too long or are you considering wrapping vertically?

Wrapping yes, automatic font scaling I don't think so as it might introduce some strange edge cases, but we want to implement the ability to control font scaling across the entire app, so users can change that as they need. (see new attachment next)

wow, that was a tiny export.

Not so sure about the far right 3 dot icon - one of my personal hates - I just detest it. It's not so easy to see and does not fit well with all the other icons - it looks out of place and the 'v' downward pointing arrow is extensively used in Thunderbird, so it is generic - I would prefer to keep it for drop down menus.

Yeah, that's something I can explore when working on it. It if makes sense keeping the down chevron, I'm okay with it.
We will start using the 3 dots icon for things like context menus in list rows, but in this situation I think you're right.

Can a large yellow star be displayed if starred?

It's already there in the mock-up, to the left of the message title.

Also asking would it possible to be able to add star to email by clicking on a large outline of yellow star to get an infilled yellow star like you do in the Thread Pane starred column?

That's exactly how that's gonna work :D

The change to icons only should only occur if the width has been reduced, From is already on next line and there is insufficient space for the text buttons+icons to be displayed on their own on the top line OR the user selected the icon only option.

Yes, this will need a lot of goo media queries and careful tweaking to make it happen correctly. That's why I need to first rebuild this section because the current structure if a mix of XUL, custom elements, and HTML which don't play nice together.

Query: should there be a minimum allowed width which is just wide enough to show all selected icons ?

We can explore that for sure.
Identifying extreme edge cases and finding good and simple solution for those it's absolutely part of this bug.

What about being able to adjust the order of the toolbar buttons?

This is slightly out of scope for now, but I think we can explore adding this feature in a follow up bug after this one lands.

What about being able to adjust the order of the toolbar buttons?

This is slightly out of scope for now, but I think we can explore adding this feature in a follow up bug after this one lands.

As a heads up, that question is still being asked in the Forum.
https://support.mozilla.org/en-US/questions/1354127
They would like to remove icons they do not ever use or improve positioning as they have a habit of clicking on wrong buttons.

Hiding specific buttons is pretty simple using a userChrome.css though

And there are extensions that can do this.

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

And there are extensions that can do this.

If Message Header Toolbar Customize will still work.

Are there others?

Confirm, the Message Header Toolbar Customise still works in 91*
This bug topic is also still current in Support Forum.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/ac7b5c17861a
Rebuild the HTML structure of the message header view. r=mkmelin

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/82ca3f9bd732
Add the flagged state to the message header. r=mkmelin

Weirdly, it looks like this is what broke mail/base/test/browser/browser_mailContext.js on Windows. I backed it out (on Try) and the error went away. The error message is:

Uncaught exception - [Exception... "Component returned failure code: 0x80550013 [nsIMsgFolder.createSubfolder]" nsresult: "0x80550013 (<unknown>)" location: "JS frame :: chrome://mochitests/content/browser/comm/mail/base/test/browser/browser_mailContext.js :: testMessagePane :: line 158" data: no]

That's....weird indeed.
I'll take care of it.

+message-header-msg-is-flagged =
+    .title = Star marked message
+
+message-header-msg-not-flagged =
+    .title = Not star marked message
+

This is poor en-US and does not follow the other buttons' tooltip phrasing, or the menuitem for Read/Unread. Please change to
Mark this message Starred
Mark this message Unstarred

(In reply to Geoff Lankow (:darktrojan) from comment #71)

Weirdly, it looks like this is what broke mail/base/test/browser/browser_mailContext.js on Windows. I backed it out (on Try) and the error went away.

This is the code causing the test failure: https://searchfox.org/comm-central/rev/1471a7836a2abc68c373e51b739407ce151d84fd/mail/base/content/msgHdrView.js#223-227
Locally, it only happens when using the --verify tag, which fails when running rootFolder.createSubfolder("test", null); during a second pass.

I'm not sure if the issue is due to the gFolderDBListener not de-registering properly, or the fact that we're creating an identically named subfolder and that is making the folder db listener freak out.

I'll keep investigating.

EDIT: Try run to confirm that by removing the initFolderDBListener from the folder selection method fixes the test: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=49c1b764dafd56ed031bfc63c915a9324e9c08cc

(In reply to alta88 from comment #73)

+message-header-msg-is-flagged =
+    .title = Star marked message
+
+message-header-msg-not-flagged =
+    .title = Not star marked message
+

This is poor en-US and does not follow the other buttons' tooltip phrasing, or the menuitem for Read/Unread. Please change to
Mark this message Starred
Mark this message Unstarred

Regarding the title. Its not obvious if the star button should describe the current state that the icon represents, or if it should describe the button's action. This is a button whose image content describes the current state, rather than an action. Moreover, in Thunderbird, we use title attributes for both icon descriptions and button action descriptions, which in this case are not the same thing.

In this case there is an unfortunate situation where "Star" can be used as both a verb and a noun, so the state description can seem like an action description (especially "Star marked message" can be interpreted as both "this message is marked with a star" and "apply a star to this marked message"). So if you stay with the state description, you might want to change them to something like

message-header-msg-is-flagged =
    .title = Message is Starred
message-header-msg-not-flagged =
    .title = Message is not Starred

NOTE: For the addressbook star I put the action description in the button title and the icon description in the image alt text.

<button title="Edit Contact">
  <img alt="Address is in the Address Book" />
</button>

See https://searchfox.org/comm-central/rev/93d0b46cabf00697767cce8026a7651f1689a055/mail/base/content/widgets/mailWidgets.js#464-483

In the accessibility tree, the alt text becomes the button's accessible name, so the user will get the state description rather than the action description. I'm not sure this was the best approach for either screen-reader users or visual-only users. In any case, we should try and use the same approach in both places.

Maybe it would be better to change the <button>'s role to checkbox:

<button title="Mark message as Starred" role="checkbox" aria-checked="false" aria-label="Starred Message">
  <img alt="" src="not-starred-icon">
</button>

<!-- switches to -->

<button title="Unmark message as Starred" role="checkbox" aria-checked="true" aria-label="Starred Message">
  <img alt="" src="starred-icon">
</button>

This way the binary nature of the 'button' is clear. And the current state and the action can both be inferred. At least for screen-reader users. For visual-only users, hopefully the icon is recognisable or at least the "Mark as Starred" title (which is not currently accessible to keyboard-only users, see bug 97223) would imply that the message is not currently starred, and vis versa.

My only issue would be that for the addressbook star, 'unchecking' the button opens an "edit" contact popup, which may remove the contact or not. So it isn't quite the same as a normal checkbox.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/9e43bc3f94ec
Improve msgHdr DB listener and fix alignment of date label. r=mkmelin,darktrojan

@:henry - Thanks for a well reasoned overview and display of advanced html concepts, esp accessibility (which sadly was ignored).

(In reply to Henry Wilkes [:henry] from comment #75)

Regarding the title. Its not obvious if the star button should describe the current state that the icon represents, or if it should describe the button's action. This is a button whose image content describes the current state, rather than an action.

But no, user actionable widget behavior is always first an action, even if it changes a state. The result of that action, on a button, may be indicated by a depressed styling, or menuitem checkmark presence, or color/icon change. The correct (and well known but no longer it seems) way to convey to the user that an action is being performed, which results in a changed state, is styling representing the combination of :hover and :active selectors. Just like in a standard toolbar button when you mousedown but not yet up. It is more correct to use title language that describes the action rather than the state.

So this star 'button' now looks strange, unlike its neighbors. It is a ui feedback regression. Changing a paradigm for this one single button widget, on a whim, without changing all other widgets with similar behavior, is just sloppy.

My only issue would be that for the addressbook star, 'unchecking' the button opens an "edit" contact popup, which may remove the contact or not. So it isn't quite the same as a normal checkbox.

I would suggest using something other than a star. A star is known to be a flag, or a favorite. Presence in an addressbook should have...a blue person icon...?

Further, it's really disappointing that something like this lands and it has not been verified that all row text lines up on all platforms, for all message types, both normal and full header views. The added margin items in the most recent patch regress on linux; it's not been understood that the line-height rule is wrong and should be removed.

and fix alignment of date label

Nope. The dates in From vs Subject are not the same. There should be no top/bottom/block margin or padding on any descendant element of the headers box.

The first row is special, slightly, due to the buttons. But the bottom text distance between it and the next row and all other rows must be the same. This project doesn't have a pixel level perfectionist designer, or an html/css heavy, and it shows.

I would suggest using something other than a star. A star is known to be a flag, or a favorite. Presence in an addressbook should have...a blue person icon...?

That sounds a perfectly reasonable suggestion and offers a better visual context for the purpose of that icon.
The contacts within an address book use a 'person icon'.

(In reply to alta88 from comment #79)

@:henry - Thanks for a well reasoned overview and display of advanced html concepts, esp accessibility (which sadly was ignored).

Why was it ignored?
The button has been updated with Henry's suggestions.

So this star 'button' now looks strange, unlike its neighbors. It is a ui feedback regression. Changing a paradigm for this one single button widget, on a whim, without changing all other widgets with similar behavior, is just sloppy.

Nothing sloppy here, and definitely not done on a whim.
The star icon has been used to mark messages as favorite for a very long time, so maintaining that visual paradigm is correct.
We definitely need a different icon for the addresses saved in the AB, as using a star for those is not a great visual paradigm.

Further, it's really disappointing that something like this lands and it has not been verified that all row text lines up on all platforms, for all message types, both normal and full header views. The added margin items in the most recent patch regress on linux; it's not been understood that the line-height rule is wrong and should be removed.

Can you share a screenshot with your issue? The labels and fields are properly aligned and they perfectly match 91.

The first row is special, slightly, due to the buttons. But the bottom text distance between it and the next row and all other rows must be the same. This project doesn't have a pixel level perfectionist designer, or an html/css heavy, and it shows.

You're more than welcome to propose a patch to fix these visual inconsistencies.
Keep in mind that this is a work in progress which is slowly updating the message header with small targeted patches, so more UI changes are getting introduced and none of these are landing in the current ESR.

In general, I'd like to kindly ask you to keep a more positive and respectful tone.
Using words like disappointing and sloppy doesn't create a good engagement outcome.
We're all here to improve TB and make it better, we're not here to fight with each other to see who's the coolest kid on the block.

Opened bug 1743496 for the recipients AB icon.

Comment on attachment 9243994 [details]
message-header.png

What would the tab ordering be in this image?

In particular, I'm curious since currently the button toolbar comes before the "From" field in the document ordering, even though it can appear afterwards visually (if the view is wide enough). The flex-direction: row-reverse rule can be confusing when using a keyboard since moving the focus forward would move it from the end of the 'line' to the start of the same 'line'.

My idea for the focus cycle via TAB keypress on the header is this:

• From recipient
• Toolbar button (The first button should be focused and each button should be cycled through with the Arrow keys)
• Other recipients (Cc, Bcc, etc)
• Subject
• Date
• Other fields, encryption button, etc.

Each recipient should be focused in its entirety and the focus shouldn't move to the "Contact in Address Book" indicator.

I'm not super opinionated on this ordering since it will need to hijack the natural focus ring and force it with JS, so if something better and more natural is proposed it's definitely welcome.

Nothing lines up well, in either normal or all headers view. On linux.

If someone would mock up a visual of the screen layout options, it would help

What do you mean with screen layout options?

A lot of the visual changes implemented in the various sections of TB are shared and discussed beforehand the ux mailing list or tb-planning.
For the message header, this is the message with the mock-ups and user feedback: https://thunderbird.topicbox.com/groups/ux/Tc2dd3360e51195d5

We're also working on a design system and building a location where all the mock-ups and visuals can live for users to see.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/f95df0a38c41
Add pixel perfect alignment of labels and fields in message header. r=Paenglab,Henry

This is how the message from attachment 9253649 [details] looks like on Linux with the latest Daily. Doesn't look pixel perfect.

Thanks for the screenshot and for the check.
Very strange, I'll continue working on it to improve it.

Hardcoding min-height and line-height is wrong. You haven't tested for responsive design, nor taken Density settings into account, nor considered that multi nodes might mean multi items, nor tested for the permutations already mentioned above. New: do people like tags?

The cargo culted de xbl changeset created custom elements extending XULElement. This needs to be ripped out as most if not all of those are unneeded complexity, and have produced a mess of xul/html. This whole widget should be done in pure html/css grid/flex. Otherwise it's just whack a mole and death by a thousand bug reports.

This needs to be ripped out as most if not all of those are unneeded complexity, and have produced a mess of xul/html

Yeah, I totally agree with this as a lot of problems come from that mess of nested XUL and HTML in those Custom Elements.
I'm working on those, it's a slow process and it'll take a lot of work, but the goal is to clean this whole area and remove all XUL elements in order to guarantee a proper alignment without relying on hard coded height attributes.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/4de43eacb30f
Set line-height to message header rows.r=henry

Tags and mailnews.headers.showUserAgent which I have set to true for seeing what a user has used to post to a support group.

No longer seeing the UA in 96.0b1, or 97.0a1.

Now seeing tags and the UA after resetting toolbars and controls when using Troubleshoot Mode.

PLEASE, AVOID COMMENTING WITH "YES, I USE "ADD-STUFF-HERE" A LOT SO PLEASE DON'T REMOVE IT

No one is removing Tags, and I'm working on re implementing the customization options to manage those toolbar buttons.
This bug passed the 100 comments mark and it's getting out of hand with comments completely unrelated to the scope.

Please, keep the discussion exclusive to the technical implementation and the patches.

Next steps for the upcoming patches

• Implement a better and intuitive keyboard focus ring. Comment 85 has an initial overview of what that might look like.
• Let the UIDensity feature affect the header area.
• Move the extra headers generated from the "All header" view into a doorhanger.
• Implement customization options to:
  • Show/Hide buttons text and icons. DONE
  • Show/Hide rows labels (recipients lists like To, Cc, etc will show those labels inline) DONE
  • Increase the font size of the Subject line. DONE
  • Option to show the email address of the sender on the second line. DONE
  • Option to show the profile picture, or a placeholder if not available. DONE

Currently there are 2 message header rows without ID's, the first row, holding the expandedfromRow, and the row holding the expandedsubjectRow.
Is it possible to add ID's to these rows, so that I can more easily move/show/hide them with my Compact Headers extension?

(In reply to Michel from comment #104)

Currently there are 2 message header rows without ID's, the first row, holding the expandedfromRow, and the row holding the expandedsubjectRow.
Is it possible to add ID's to these rows, so that I can more easily move/show/hide them with my Compact Headers extension?

Sure, I'll do that in a follow up patch.

Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/db760eba6687
Add IDs to subject and from rows for add-ons usage. r=mkmelin

Not sure, if this is right in here: The messageDisplayAction buttons added by addons should at least be moved to the left side of the "More" button.

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/7df125ad05ed
Implement a simple customization panel for the Message Header. r=mkmelin,Paenglab

(In reply to Alex Ihrig [:Thunderbird_Mail_DE] from comment #108)

Created attachment 9272521 [details]
Proposed alignment for additional buttons

Not sure, if this is right in here: The messageDisplayAction buttons added by addons should at least be moved to the left side of the "More" button.

Pinging John to see what he thinks about this.
I don't have a strong opinion.

Pinging John to see what he thinks about this. I don't have a strong opinion.

We can do that. Alex, can you create a new bug for that? The patch is a one-line change.

After customization of header bar to icon view, From address should jump to icon line[see yellow space]. instead it is still jump to first after icon and text size.

Yellow colour shows empty area

(In reply to Jaise from comment #112)

After customization of header bar to icon view, From address should jump to icon line[see yellow space]. instead it is still jump to first after icon and text size.

I can't reproduce this.
Are you using any add-on that manipulates your message header?
Does it stay like that if you change message?
Does it happen every time or only with a specific message?

That whole section is pure HTML with flexbox wrapping, so everything should stack and align automatically when there's available space.
Would you be able to share a screenshot showing the whole header? You can put black bars on top of addresses.

view Just before wrapping

icon on wrap

addons installed

(In reply to Jaise from comment #115)

Created attachment 9273969 [details]
icon only view 1.png

view Just before wrapping

This is very odd.
The fact that the From, To, and Subject labels are left aligned and don't have a min-wdith for that column it means that your layout is somewhat thinking that it's smaller than 768px wide, which it doesn't seem like it.
https://searchfox.org/comm-central/rev/5e4def2a2afe978ffeeed96e2f3c0d4a8a80d816/mail/themes/shared/mail/messageHeader.css#771-794

Can you try to restart in troubleshoot mode with all add-ons and custom styling removed?

It is due to experimental option mail.useNewMailTabs enabled.
When disabled, it is working as intended.
Thank for your support.

Depends on D147236

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/865d5d6a47ee
[Message Header] Allow hiding the labels column through customization. r=henry

Once the last bug lands, this can be closed as plenty of customization has been added back, with more options and features than before.
Not every point of Comment 102 has been addressed, but those can be handled in dedicated bugs.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/aec43dd75f64
[Message Header] Customize the aspect of the sender row. r=darktrojan

(In reply to Alessandro Castellani [:aleca] from comment #123)

Once the last bug lands, this can be closed as plenty of customization has been added back, with more options and features than before.
Not every point of Comment 102 has been addressed, but those can be handled in dedicated bugs.

It's surprising that the feature requested in the bug summary wasn't implemented:
Re-Implement message header toolbar customisation to add and remove buttons
Being able to remove unneeded buttons was the original idea of the toolbar customization.

Is that planned?

(In reply to newsfan from comment #126)

(In reply to Alessandro Castellani [:aleca] from comment #123)

Once the last bug lands, this can be closed as plenty of customization has been added back, with more options and features than before.
Not every point of Comment 102 has been addressed, but those can be handled in dedicated bugs.

It's surprising that the feature requested in the bug summary wasn't implemented:
Re-Implement message header toolbar customisation to add and remove buttons
Being able to remove unneeded buttons was the original idea of the toolbar customization.

Is that planned?

Yes, as an original bug submitter, I'd love to understand how the reported regression (ability to remove the [triple-redundant!] header button menu) has been overlooked. Can someone PLEASE restore this ability?

(In reply to newsfan from comment #126)

Re-Implement message header toolbar customisation to add and remove buttons

There's currently no hidden button that can be added, and "new" buttons can be added via the web extension API.

Being able to remove unneeded buttons was the original idea of the toolbar customization.

Which unneeded buttons do you think should be possible to remove?
The header buttons change depending on which message you visualize (reply, reply all, reply list, etc).
Wouldn't allowing removing buttons cause some unexpected results with the inability to properly handle replies?

See my button set in attached pic. It is totally different. I hide Junk & delete & then added conversion view & tag button over there[using message header bar customization]. We can keep No of button say 6 numbers. I feel customization is very useful.

I remove the "Archive" and "Junk" buttons since I don't use that functionality in TB. Now it needs to be done via userChrome.css:

#hdrArchiveButton { display: none; }
#hdrJunkButton { display: none; }

IMHO, independent of all the nice new configurability, the removal of the configurable toolbar in bug 1535265 was a mistake. The summary of that bug was: Reduce the number of unnecessarily-customisable toolbars.
Well, for the header pane, the customization was clearly not unnecessary and should just be restored. There are other customizable toolbars in the system, so clearly the product depends on customizable toolbars and removing one of them doesn't reduce the technical debt.

(In reply to Alessandro Castellani [:aleca] from comment #128)

(In reply to newsfan from comment #126)

Re-Implement message header toolbar customisation to add and remove buttons

There's currently no hidden button that can be added, and "new" buttons can be added via the web extension API.

Being able to remove unneeded buttons was the original idea of the toolbar customization.

Which unneeded buttons do you think should be possible to remove?
The header buttons change depending on which message you visualize (reply, reply all, reply list, etc).
Wouldn't allowing removing buttons cause some unexpected results with the inability to properly handle replies?

Thanks for your questions.

The key point is that all of the Message Header Toolbar button actions (Reply, Replay All, etc.) are also available in both the Menu Bar and in the highly configurable Mail Toolbar. So the user has three ways to trigger any of these actions. And they will likely settle on one method as their preferred gesture, considering one or both of the other options as "unnecessary". More than unnecessary, they could be considered noise and a distraction, and thus removing them can be significantly more desirable than simply ignoring them.

Personally I strongly prefer the Mail Toolbar. Why? No joke--because it is configurable with lots of options! As for the Header Buttons, their location (right-justified) is undesirable, the options are limited, and I'd rather not have the header area cluttered with non-header junk.

So to answer your first question, it seems clear to me that ALL of the buttons are "unneeded", and thus all are candidates for user configuration, as was the case prior to v69. For me personally, making the Message Header Toolbar simply disappear, without granular customization, would be a sufficient customization option!

You ask about possible unexpected results, but I don't understand. If for example the user decides to remove all the Reply buttons, they have no one to blame but themself! But seriously, in that case the missing Reply would not be unexpected, just unusual. And any undesirable or mistaken changes could easily be reversed.

It is perhaps amusing to note that the user has the option to completely remove both Menu Bar and the Toolbar (via right-click options), leaving no obvious way to restore them (since you can't right-click on them any more, and must use Alt-F10 instead). I don't think that restoring customization of the Header Button Menu would change any of this. But using this right-click menu to enable/disable the Message Header Toolbar would be a natural resolution.

(In reply to Alessandro Castellani [:aleca] from comment #128)

(In reply to newsfan from comment #126)

Re-Implement message header toolbar customisation to add and remove buttons

There's currently no hidden button that can be added, and "new" buttons can be added via the web extension API.

Being able to remove unneeded buttons was the original idea of the toolbar customization.

Which unneeded buttons do you think should be possible to remove?
The header buttons change depending on which message you visualize (reply, reply all, reply list, etc).
Wouldn't allowing removing buttons cause some unexpected results with the inability to properly handle replies?

I could use the ability to remove the Archive button in all headers.
The header in newsgroup posts has a Reply button I could remove, because the Followup button has a drop-down with Followup, Reply All and Reply selections.

Well, for the header pane, the customization was clearly not unnecessary and should just be restored. There are other customizable toolbars in the system, so clearly the product depends on customizable toolbars and removing one of them doesn't reduce the technical debt.

Customizable toolbars are XUL reliant and we're moving away from that. The message header is now fully plain HTML and the customization implemented is very simple and mostly done via CSS.
We're using this area as a testing ground for more personalized customizable widgets that don't rely on XUL, so, please, let's stop with the "restore the previous toolbar" repeated request.

The old (current) toolbar customization is also not accessible for keyboard users, so it's a feature that only able mouse users can leverage, and we should overcome that limitation.

Thank you all for the overview and info
I see the point in showing and hiding some specific buttons, or even removing all buttons if those actions are available in the main toolbar, so I will open a follow up bug to implement this feature with a new mechanism, offering an overview of the implementation strategy and expected behavior.

I'm opening a new bug because this one surpassed 100 comments and the scope became a bit wider with time.
No need to keep commenting in here.

In new header bar, add to address book(by right click or press icon) has no immediate feedback. We can do multiple time & address book filled with duplicate address.
Add to address book icon is very light colour[blue]. We will not feel, address added to address book.

(In reply to Jaise from comment #134)

We can do multiple time & address book filled with duplicate address.

That's impossible. How did you arrive at that state?
As soon as you add a contact to the address book the icon click and right click change behavior change immediately.

Also, please open a new bug if something doesn't work properly and avoid commenting on closed bugs.

(In reply to Alessandro Castellani [:aleca] from comment #135)

(In reply to Jaise from comment #134)

We can do multiple time & address book filled with duplicate address.

That's impossible. How did you arrive at that state?
As soon as you add a contact to the address book the icon click and right click change behavior change immediately.

Also, please open a new bug if something doesn't work properly and avoid commenting on closed bugs.
Opened new bug report
https://bugzilla.mozilla.org/show_bug.cgi?id=1773611

Alex, see comment #91, the alignment is still not correct on Linux.

(In reply to Alessandro Castellani [:aleca] from comment #133)

The message header is now fully plain HTML and the customization implemented is very simple and mostly done via CSS.

That's not 100% correct, the From/To/Subject are still XUL labels (at least on beta). Shouldn't that become a 2-column grid?

Please, open a new bug to report issues.
Nevermind, I'll take care of it.

(In reply to newsfan from comment #137)

That's not 100% correct, the From/To/Subject are still XUL labels (at least on beta). Shouldn't that become a 2-column grid?

For the record: The removal of the XUL labels is covered in bug 1745796, it was actually already done and later backed out:
https://hg.mozilla.org/comm-central/rev/356cbd061296#l3.12 (see bug 1745796 comment #24).
Maybe some of that work can be recovered to help bug 1773783.

I'm still using 91.10.0
I've just seen an image showing Message Header here:
https://support.mozilla.org/en-US/kb/new-thunderbird-102#w_focus-on-what-matters-redesigned-message-header

Here is my feedback and perhaps you can enlighten me on whether there are options to fix these observations.

The image of person is too small- in reality that icon is going to rendered so small as to be useless and it is round which means it is always going to be clipped. Image needs to be square - like the generic theme to prevent clipping or did you really create the image as a circle, so that's how it naturally displays, meaning a square or portrait would display as square or portrait?
It also needs to be 100% larger and use space below it - currently occupied by a misaligned 'To'.

It looks wrong to have TO field immediately aligned to far left below image when From and Subject are inset.
It is all visually out of sync - The three From To and Subject all need to be in alignment.

If the words 'From' and 'Subject' are not displayed how does this effect those who use a program to read info aloud to user ?

All the text seems to be different sized fonts.
Some users will find the Subject is large enough, but the From and To font is too small. If they make generic font (pixels) larger so the smaller font is now readible then the Subject could end up massive.
How does the user get all the font in that Message header the same size?

The 'More' 3 dot icon on far right does not look like an icon of the set used. That icon is vertical dots which means it is not as easily visible as a V chevron drop down icon which is generically used in Thunderbird. The only place that uses dots is in the addon and themes area and then they are not vertical. If it is a drop down then use the V chevon.

None of the eg: reply, forward icon buttons look like buttons or does that only occur when you hover over them ?
They would look better if there was some evidence of a square type button. Eg: like used in addon & themes area.

The star icon has been used to mark messages as favourite for a very long time, but does that yellow star look like a greyed outline of star if not set as a favourite ? Is that icon going to be something people can click on to set as favourite ?
If it is not clickable to set/unset then does it have any purpose in a confined space?
If it is clickable then it looks good.

The blue star icon - If there is no image then it would look better on the left side above the yellow star. I also thought the star was going to change to look like a 'person' icon as used in address book. - maybe I got that wrong.
What is the alternative when no image is used ?
In my case there is never going to be an image as it is superfluous and I have the text saying who it is From.

The From starts on top left, so are we going to see this appearing to jump down to next row when the icons are converted to text or if window is reduced/increased in width ?

Basically how would I do the following :
Remove image.
Set all fonts to same size.
Align From, To, Subject
Place blue star icon on left above yellow star.
Replace the 3 dot icon with a V icon.

Are these options in the Customise section?
I'm going to get asked questions on how to alter parts of this so can you offer code which can be used in a userChrome.css file?
Many thanks.

Sorry, but BugZilla is not a discussion forum.
This is a closed bug and no new messages should be written in it. Also, please don't NI me for support questions.

You should first try the feature and then reach out in support forums or open dedicated bugs if something doesn't work properly.