Don't show view options in vertical pane in the message viewer

[Danielle Foré]

The vertical "view switcher" thing in the message viewer feels out of place and the functionality it provides isn't something a normal user should be asked to decide.

If this functionality is really needed, I would suggest that it be placed in the context menu of the message itself. As in, Right click > View as... > Plain Text

[Bernd Prünster (jesusmccloud)]

this is not a switcher, this lets you select which part of the message to view
for attachments it shows a nice message in the messageview that lets you save or open the attachment (or view it directly if it it can be displayed like images for example)

[Danielle Foré (danrabbit)]

Well, IIRC, it does show "plain text", "html", "multipart" whatever. So at least this part of the bug report is valid in that direction. I will file a separate report for attachment handling.

[Bernd Prünster (jesusmccloud)]

well not really, it just lists all the parts there are. i have emails that do have a plain text part which mentions the html part (a preview of a catalog in that case) so just removing plain text is a bad idea, we cannot judge if a html part will always be the same as a plain text part based on 5 emails we looked at. also i remember sending some html files back and forth (this was related to university stuff) where html was an attachment.
also just checking if there is a filename or not to identify if the html message is an attachment or a pretty version of the plain text part is also not a doable, because even very popular email clients like thunderbird violate the corresponding RFCs for multipart messages. and the filename is only one piece of the puzzle :'-(

we cannot dictate stuff like this on the user, because microsoft email clients, thunderbird, some webmail services do not comply with RFCs, and i do not think a 99% success rate is good enough if we can do 100% (btw postler complies with the RFCs for creating multipart messages IIRC ;-))

i do understand your point of view thoug, but sadly there is more to it ...including major corporations and organizations that simple dont care about RFCs.
we already have some magic in the code to handle faulty email clients, also in the multipart handling code... if this magic kicks in (when it has to) then there is no way to identify if the html part is a more beautiful version of the plain text part or an attachment, some of this magic was specifically added when checking some test-emails because >50% of the sample emails used did not comply with the RFCs.
they were sent from thunderbird, outlook/windows mail, claws-mail, ... depending on the type of the message and type of attachments, those messages either complied, or not.

we need to keep in mind that we need to function in the real world, where email clients in general not only suck from a usability point of view, but also regarding the messages they produce.

[Bernd Prünster (jesusmccloud)]

i think we can try to handle certain types of multipart messages differently (mixed, alternative,,,) should give us a 99,9% success rate

[Cris Dywan (kalikiana)]

I accidentally removed a check for multipart/ earlier, meanwhile I added it back so these internal parts won't show up as buttons.

I also doubt we can do much about "redundant" parts. It is not always clear which parts are identical. If we do find cases which are reliable, suggestions are welcome of course.

[Cris Dywan (kalikiana)]

So meanwhile the vertical buttons were replaced with an attachment view.

I now added a View as plain text/ HTML link to the extra headers that shows up if alternative parts are available, so I consider this done.