523544 - With multiple messages selected, many command buttons are missing on thread summary's header toolbar and contextual menu (junk, reply[-all], forward, tag, etc.)

Status: RESOLVED WONTFIX

(Thunderbird :: Mail Window Front End, defect)

Description

[Thomas D. (:thomas8)]

str

1 select multiple messages
2 look at header bur

actual

- be surprised you can only "archive" or "delete" multiple messages from header bar (just 2 buttons out of 6 show up)
- notice that delete button is too big (needs other bug)

expected

- probably show same header buttons as for single message, since all actions are also possible for multiple msgs
- this is a regression, since in tb2 we were showing all buttons on main toolbar, now we're not showing them
- in particular, we need "forward" and "junk" button here (that was mentioned somewhere)
- full customization, please!
- we should also offer most or all possible message-related commands in the contextual menu (especially "Save as (files)..." which now works, but also "Reply to selected messages")

Comment 1

[Ludovic Hirlimann [:Usul]]

Is this in our new Thread summary view ?

Comment 2

[Thomas D. (:thomas8)]

Attachment: Screenshot: Missing buttons and context menus when multiple msgs selected (main win, same thread)

(In reply to comment #1)
> Is this in our new Thread summary view ?

I'm not sure what exactly "Thread summary view" is, but yes (see screenshot). The problem occurs both in the main win and in "show all as list" mode of faceted search.

Looking at it with the eyes of a new user, with the added visual oddness that the delete button is significantly bigger in height, this really creates the impression as if someone didn't get round to finishing this off properly.

Comment 3

[[e-mail]]

Seeing the same problem when threaded views are collapsed.

Comment 4

[Jim Porter (:squib)]

(In reply to comment #2)
> Looking at it with the eyes of a new user, with the added visual oddness that
> the delete button is significantly bigger in height, this really creates the
> impression as if someone didn't get round to finishing this off properly.

The button height is fixed by bug 519688 (or it should be - check the latest nightlies). Bug 523252 is for adding a "junk" button, and I also discussed methods in that bug to make the thread- and multimessage-summary buttons customizable.

Comment 5

[Jim Porter (:squib)]

Incidentally, for some of the other actions, like "Reply", those don't appear when you select multiple messages in TB2 either. The only difference is that now, clicking the root of a collapsed thread means "select the whole thread", when it used to mean "select the root message".

Comment 6

[Thomas D. (:thomas8)]

(In reply to comment #5)
> Incidentally, for some of the other actions, like "Reply", those don't appear
> when you select multiple messages in TB2 either.
That's only partly true: Reply etc. don't show in the context menu of multiple selected messages in TB2, but both in the main menu and on the main toolbar you can use reply and all the other commands on multiple messages. Which will just trigger the action for every single message (e.g. 2 reply windows for 2 selected messages), since we don't have combined replies etc. yet.
I am failing to see why we are treating multiple messages as a different animal. All buttons should be available, and of course they should also be customizable, separately from the single mail header.

Comment 8

[[e-mail]]

I'll add that another thing that's grayed out that maybe shouldn't be is the Create Filter from Message menu item under Message. It could easily assume that the user is referring to the top message, or even make a guess regarding what the messages in the thread have in common.

Comment 10

[KitchM]

Is this a similar issue to 523252?

Comment 11

[Joachim Herb]

Wouldn't it make sense to just use the same toolbar in the header of multimessageview as in "single message view" and grey out (aka disable) buttons not applicable.

At the moment, if you select more than one message the "mail toolbar" (the toolbar below the menu) buttons reply, reply all (and probably also others) just apply their action an each selected message (exception for forward as attachment: all selected mails are attached to one new one).

I would suggest, that button in the header pane behave in the same way as to "mail toolbar" buttons.

Would it be an acceptable solution to "move" the toolbar form the single message view to the multi message view (and back)? In the CompactHeader add-on there is js code which does this when switching between compact and expanded header view mode. Then all settings like text/icon would also be set consistently.

P.S. I think bug 523252 is a special case of this bug.

Comment 12

[KitchM]

Good ideas.

However, make no mistake, the whole interface, as it has to do with any buttons, needs a complete re-work.  The logical progression of the button actions is all out of whack.  In fact, I can't make any sense of what is there now.  Does anyone understand the thinking behind the current layout?

This is another example of a case where the software has become patched, and has diverged from a well-planned approach.  I don't know why, but that's how it is.  Very odd.

My strong suggestion is for the Thunderbird team to gather together all these issues under one brainstorming location where we can cut and paste pieces to arrange a good interface between all contributors' ideas.  IMHO, we could in that way better visualize the issue and more easily reach consensus with the coders.

Comment 13

[Joachim Herb]

I think this bug is about the layout of the header pane. The internal handling of buttons actions should probably covered elsewhere?!?

What do Thunderbird team members think? Is there already such a place for brainstorming?

Comment 14

[KitchM]

Yeah, good question.

With regard to programming, AFAIK there are variable settings and/or prebuilt libraries of information, followed by code to use that information in some process, and then some GUI to display that info in a particular manner.  Of course that is very simplified.

In our case, the program code processes and/or directions, along with the basic information, already exists.  Therefore the only issue is connecting the existing information to the right inputs and outputs.  These I/O devices on the GUI would include the buttons.  Since the information exists, then creating and placing buttons in the right place is the harder part.  The easy part should be tying a particular button's action to a particular instruction set that already exists.

For instance, a button exists to junk messages, whether a single message or a group of messages.  We know this because, while the junk button may disappear in the message header area, the junk button exists in the button bar.  Since they do the same thing (unless someone actually duplicated the junk function code for some weird reason), the only issue appears that there is a flaw in the program code that makes a particular button appear or disappear at the wrong time.  If the button is there, the instruction behind it's action also exists.

This is so simple to fix.  Turn off the process that makes that button disappear.

This is an example of code bloat that is totally unnessary.  Since the space for buttons is already reserved, use it all the time.  That's my two cents.

Comment 15

[Jim Porter (:squib)]

(In reply to comment #14)
> This is so simple to fix.  Turn off the process that makes that button
> disappear.

In general, it's inadvisable to assume that a patch is simple just because the UI appears to be simple. Your understanding of the toolbar internals isn't quite right; the junk buttons for the multi-message summary and for single messages are separate, but as I recall, they use the same code for the onclick event. In any case, comments like this aren't very helpful, since the people who are in a position to fix this bug already know (or can easily find out) what the internals look like.

The main thing that needs to be decided on is whether the message header toolbar should just be reused here, or if it's more complicated than that (e.g. should the multi-message summary toolbar and the message header toolbar be separately customizable?).

Comment 16

[Joachim Herb]

This is a proposal for a possible implementation to copy the toolbar around between single and multi message (header) view:

Starting at http://mxr.mozilla.org/comm-central/source/mail/base/content/messageDisplay.js#242 there is the logic to decide if we are in single or multi message view. 

So either:
- add function calls here to check if the view mode changed and move the toolbar around
or
- dispatch an event, like it is done at http://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#340 and handled in http://mxr.mozilla.org/comm-central/source/mail/base/content/multimessageview.xhtml#64. Then the move code would probably reside somewhere in multimessageview.xhtml or a new multimessageview.js. What would be the correct (window.)event to use?

Any suggestions, examples, hints?

P.S. I think a special configurable toolbar for the multi message mode is not very user friendly: You configure the toolbar in single message mode, then you select more than one message, get a new toolbar with different buttons. You might change the buttons again, but when you go back to single message view your changes are "somehow lost". You might get it, after changing between single and multi message view several times. Also what happens, if you change between single and multi message view during configuring the toolbar (which is actually possible at the moment: The single message view toolbar dis/reappears)???

Also are there any buttons you only need in multi message view? Probably not. If there were buttons only usable in single message view, then disable them in multi message view.

Comment 17

[KitchM]

Apparently there exists a confusion about the internals of the programming of the application.  Please allow me to clear it up.

First, programs are created for the user.  As has been pointed out many times, there is a serious useability problem.  (If any reader doubts that fact, just read herb's good comments above to get on the right track.)  Whether it be a toolbar or a buttonbar or a menu item, there is an inconsistent methodology employed in the application of various features.

Second, poor program interface design usually is indictative of confused underlying coding.  This implication is supported by the discovery that the coders actually created two separate header toolbars plus a main button bar, and thereby created a difference without a distinction.

Third, the admission that code is reused only confirms that the use of said code can be applied as desired, and in more than one place.

These things prove that I was correct in stating that the code for the header bar and the button bar were two separate things, but that they re-used the same commands for their respective buttons.  So, to say that one code segment did something that actually turned off the associated button is correct, and reversing that to not turn it off is a viable option at this stage.

Now we should all see and understand that the real issue is that someone decided to do away with a useful button in a particular mode.  It is extremely helpful to simplify the fix as asking these unknown programmers to please undo what they did.  Not only does that fix the problem, but it focuses the discussion on the very spot that needs attention.

The real helpfulness at this stage would be to use whatever inside knowledge and influence one might have to encourage the clearly define solution as a patch to be applied right now, rather than confusing the issue with a discussion of a poor programming choice that should have never existed in the first place.

An analysis of this issue clearly indicates that the junk button requested is missing because a programmer decided to turn it off, not because it doesn't exist or cannot function in multi-select mode.

By the way, the simply solution to the underlying program snafu would have been to simplify the code by having only one header button bar that stays the same (or is user-customized like the main button bar), with a button grayed-out when not applicable.

Why in the world would anyone think that selecting more than one piece of mail against which to apply some action would in any manner act different than when selecting just one?

So, there's the simple patch we need now, and the fix for the bad programming direction, all in one post.

Thanks, and your welcome.

Comment 18

[Jim Porter (:squib)]

In the interest of moving this bug along, I'm going to refrain from discussing the existential nature of bugs in a software application. This really isn't the place for it.

(In reply to comment #16)
> P.S. I think a special configurable toolbar for the multi message mode is not
> very user friendly: You configure the toolbar in single message mode, then you
> select more than one message, get a new toolbar with different buttons. You
> might change the buttons again, but when you go back to single message view
> your changes are "somehow lost".
[snip]

This is pretty much what I think, though when I suggested this a while ago I met with some resistance (see bug 523252 comment 11). I still think a single toolbar is plenty, though. Bonus points if we can keep *all* the same buttons on the multi-message version, though this would probably mean we need better handling for replying to multiple messages.

As for implementation, is it possible to create a toolbar with the same id in the multi-message summary and have it automatically use the configuration from the message header? That seems like the easiest way, though it might require some organizational changes to the message header too.

Comment 19

[KitchM]

Actually, get rid of the header area button bar altogether.  That real estate is too precious.  Instead use the main button bar with all buttons showing all the time.  Only grey-out those that don't apply.

Simple, elegant, standard and expected methodology, more compact,........

(Imagine what it would be like if a word processor or other type of application used the odd Mozilla method.  Each section or paragraph would have it's own button bar.)

Comment 20

[Joachim Herb]

What is the opinion of mozilla staff about this topic? Should there be a "complete" rewrite of the buttons code or could this bug be fixed by a "copy/move around" solution, i.e. use the same toolbar for single and multiple messages header pane?

Comment 21

[Joachim Herb]

I tried to add the code to move the toolbar between the single and multi message view. But I have ran in some difficult problems:
The multi message header pane is codes using xhtml and displayed inside a browser tag:
http://mxr.mozilla.org/comm-central/source/mail/base/content/multimessageview.xhtml

This seems to mean that all overlays for the message window are not applicable to the multi message header pane. Which results in missing styles for the buttons (after the toolbox has been copied to the multi message header pane) and missing javascript references, e.g. to the functional code for the buttons.

Does this mean, that a solution which moves the normal header pane toolbar to the multi message header pane is not possible? Or is there a way to somehow clone the overlays to the multi message header pane?

Any ideas or help?

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

It might be possible to do it that way, but I suspect it would be fragile.  Adding bwinton, as he may have some ideas (or be better informed about the advisibility of cloning-based soloution).

Comment 23

[Blake Winton (:bwinton) (:☕️)]

Yeah…  So…  I think I would eventually like to see both message headers re-written in xhtml, but that seems like a lot more work than we really want to do to fix this bug.

Adding the buttons that make sense in the xhtml seems like the easiest thing to do, and will probably be good enough for most people.  We still won't be able to customize the multimessage-toolbar, nor will we automatically show any buttons that extensions might have put in the normal toolbar, but I think that's life.

Don't forget to throw together a mockup of what you're trying to do, and get a ui-r from clarkbw before you get too far into the coding, okay?

Thanks,
Blake.

Comment 24

[Joachim Herb]

I am trying to get this working within the CompactHeader addon. But at the moment, it don't get it to work.

Comment 25

[KitchM]

As I commented at 523252, here's a partial workaround for this problem.  Install the CompactHeader extension. Set it to display two lines in compact view.  Then customize the header buttons by removing them all.  Go to the button bar and add the ones you'd like to have.

This has the added advantage of cleaning up the too-busy header area, and
making it smaller.  And also it puts the buttons back on the button bar where
they belong.

Comment 26

[Matthew Atkinson]

It's not quite as simple as buttons just disappearing. My mail header only has two buttons, Reply and Forward, as I don't use Archive or Junk, and I have a button on the keyboard for Delete. However, when I select multiple messages, a Delete button appears by itself. So, it's removing my Reply and Forward, but also adding back Delete. 

I don't know the internals to explain this. I first thought it was reverting to the standard set, but then why is Archive not there? 

It would be good to fix this. It was broken in version 3, and is still broken in version 11! That's quite a long time to fix a regression.

Comment 27

[Thomas D. (:thomas8)]

I haven't done a systematical search yet, but here's a start to find matching reports on getsatisfaction.

Comment 28

[[e-mail]]

Bump.

This seems to be long-standing bug. Are there any plans to implement these buttons?

I am happy to test, but unfortunately TB programming is out of my league...

Comment 30

[Wayne Mery (:wsmwk)]

The message reader is being largely rebuilt for version 115. So this issue is will not be fixed for the current version 102.

When 115 becomes available in July please file a new bug if the problem exists in version 115. You can also evalute the changes in 3-4 weeks by trying a beta build.