All users were logged out of Bugzilla on October 13th, 2018
If I have as default to not compose HTML messages but needed to write one as exception it's impossible to know that Shift+"Write" will create a HTML composer window. I would like to suggest to add a menu item for composing HTML messages. Maybe only in the "Message" folder and only as option if HTML is not the default but PlainText. I could implement it, but it's a question of UI policies.
this might be also interesting for SeaMonkey. Adding Neil to CC
From the SeaMonkey point of view, overlaying File/New would be tricky, as you'd want Ctrl+M to be associated with the current default. That would mean that the only obvious available UI point is to convert the Compose toolbarbutton into a dual menubutton, much as bug 17796 does for the reply, forward and next buttons.
Created attachment 207163 [details] [diff] [review] TB patch v1 This is a basic patch as proposal how it could look like for TB. (I think seamonkey would basically the same) Unfortunately I can't hide the menu-item easily depending on the account. (AFAICS this would need some functions copied from mailCommands.js) @Neil: do we need a short-cut at all? And if yes, we could use a free one, couldn't we?
(In reply to comment #3) >(AFAICS this would need some functions copied from mailCommands.js) Well that's easy enough in TB because you already have access to mailCommands.js but in SeaMonkey the mailOverlay.xul is also applied to other windows, so you'd end up loading the mail back end just to find out the default compose format. >@Neil: do we need a short-cut at all? And if yes, we could use a free one, >couldn't we? I'd use Ctrl+Shift+M except that it's currently the GTK2 "Mark All Read" key. Note that as per shift+clicking the Compose button I'd want it to compose a message in the opposite to the default format.
(In reply to comment #4) >I'd use Ctrl+Shift+M except that it's currently the GTK2 "Mark All Read" key. Oh, and Accel+Shift+M is also our normal "Compose" key on the Mac, because its OS decided that people want to use Cmd+M to minimise the window.
(In reply to comment #4) > I'd use Ctrl+Shift+M except that it's currently the GTK2 "Mark All Read" key. > Note that as per shift+clicking the Compose button I'd want it to compose a > message in the opposite to the default format. That's the same in TB but it isn't visible enough for me, therefore this enhancement request. I'm not really a UI designer so I could try to implement something if we know how it should work. (Personally I can live with something in the menu w/o any shortcut because the feature is not needed often. But w/o any text (the shift-hack for the button) it's not possible to find it.
I don't think that hacking around the invisibility of the shift+click is worth the effort - what we need is a way *in* the composer to switch between HTML/plain text composition...
(In reply to comment #7) > I don't think that hacking around the invisibility of the shift+click is worth > the effort - what we need is a way *in* the composer to switch between > HTML/plain text composition... Karsten, I second this. The HTML editor allow switching to plain-text editing in the window. But the plain-text editor doesn't allow this. Either this is a "bug" in the UI of the plain-text composer or (as someone told me) there are two composers where the HTML composer is able to create plain-text while the plain-text composer is (obviously) not capable of creating HTML messages. If this is the case we would have to fire up another composer window. I don't know how easy this is.
(In reply to comment #7) > what we need is a way *in* the composer to switch between > HTML/plain text composition... Bug 216132 (Seamonkey bug 140800). (In reply to comment #8) > The HTML editor allow switching to plain-text editing > in the window. Not exactly. The HTML compose window "plain-text only" hides the HTML- specific menus and toolbar, but it's still composing as HTML; you can bold and italicize text using the ctrl-B/ctrl-I shortcuts, for instance, and the font used is not fixed-width. That menu is primarily used to specify how the message is sent, not how it's composed. (Note, also, that composing as HTML and sending as plain results in the problems of bug 125928.)
Why not simply add 'new plain text message' and 'new html message' as sub-items of the new message button, just like you can download mail from all acounts or choose one right now? Like 'download mail from *all* accounts' is the default of that button, the chosen way to compose messages (either plain text or HTML) should be the default for pressing the big button 'write message' (or 'compose', whatever, I use the Dutch translation of TB, so don't know the exact words). Also do thi sfor 'reply' and maybe for forwarding. The only change in the composition window should be that changing from plain text to HTML should be possible, like changing from HTML to plain is right now (via the options menu). For some odd reason, this option is not present as soon as one start the message in plain text mode.
Severity: normal → enhancement
OS: Linux → All
Hardware: PC → All
Version: 1.5 → Trunk
(In reply to comment #10) > Why not simply add 'new plain text message' and 'new html message' as sub-items > of the new message button, just like you can download mail from all acounts or > choose one right now? That's what SeaMonkey just did in bug 16908, thus respective code would/may be available for Thunderbird to port. It still leaves "Auto detect" in place even if explicit HTML composition is desired, so that's another question if this should be preset with the default HTML-send setting.
I doubt it would do most regular users any good, only adding confusion, especially considering we do smart down-conversion and stuff on send.
It seems that when replying to a plain text message, it will always be the plain text compose window for the reply. So this issue affects not only power users who changed some settings, but also any regular user. He clicks reply, tries to paste a picture or format his text and he can't. Then he diggs through all menus and cannot find anything to change that. So I wouldn't call this just an enhancement, it's a bug. Or at least a missing basic feature. One cannot expect that everyone finds out that Shift+Reply does the trick. This should really be improved, ideally by some way to switch to html from the already open compose window. If that's really too hard to implement, a first good step would be "Reply as html" menu options and dropdown-buttons.
Severity: enhancement → normal
(In reply to Moritz Franckenstein from comment #14) > It seems that when replying to a plain text message, it will always be the > plain text compose window for the reply. It is not - you may have different identities which each have their own default composition mode. If it's not behaving that way, please open a new bug (and this one stays an enhancement request). (In reply to Mark Jansen from comment #10) > Why not simply add 'new plain text message' and 'new html message' as > sub-items of the new message button, just like you can download mail from > all acounts or choose one right now? Looking at current versions, there is now a drop-down menu in Thunderbird as well, which offers however the choices of Message/Event/Task, but only with Lightning enabled (which is the default).
Severity: normal → enhancement
You need to log in before you can comment on or make changes to this bug.