Open Bug 1348750 Opened 7 years ago Updated 2 years ago

Maintain previous type-in state (font size/face/colour) when clicking in empty paragraph or elsewhere outside a font tag

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

People

(Reporter: jorgk-bmo, Unassigned)

References

Details

Maintain previous type-in state (font size/face/colour) when clicking in empty paragraph or elsewhere outside a font tag.

This is a carry-over from bug 677046 and also captures the complaint of bug 1270803 and its duplicates.

STR:
Select some font other than "Variable Width" as predefined composition font.

Reply to an e-mail. Note that when entering text the chosen font will be used.

Reply again, this time, click somewhere in the quoted text before starting to type. This will pick up the font used at the click position. Click at the initial text insertion point (at the start of the e-mail when replying above the quote, otherwise at the end). Start typing and note that the predefined font isn't used since the click tried to pick up the font from the empty paragraph which has no font information.

Workarounds:
First: Start typing at the initial text insertion point before clicking elsewhere in the quoted part.

Second: Don't use Paragraph mode:
Tools > Options, Composition, General. Last item.
TB 45: "When using paragraph format, the enter key creates a new paragraph"
Later versions: "Use Paragraph format instead of Body Text by default"
This may or may not mitigate the problem.

Suggestion: Use add-on ThunderHTMLedit to inspect HTML of the message to see where font information is present and where it is not.
Of course when splitting a block quote, the predefined font is also not used. Neither do we obey the paragraph setting in this case, see bug 1271835.
Some technical background: The font face/size/colour is set here for a new message, reply, forward, etc.:
https://dxr.mozilla.org/comm-central/rev/1df067640ceebf58b01ab1705b0496c43f732d57/mail/components/compose/content/MsgComposeCommands.js#355
using loadHTMLMsgPrefs()
These setting are applied when typing into the e-mail, however, when clicking elsewhere in the e-mail, or later into an empty paragraph, these settings are lost.

There is not easy technical solution to this. One would have to intercept the click or change of selection and then re-apply the font settings in appropriate cases, which may include clicking into an area outside a font tag, for instance an empty paragraph.
Thank you for the background information. While I do understand, that there is no easy technical solution for the current faulty scenario, I would propose to rethink how Thunderbird is handling the whole message formatting.

If a message were a simple HTML document, a simple CSS setting would apply the desired font throughout the document, no matter where somebody is clicking. Maybe we should rather strive for a solution, that makes it possible to manage styles more robust and logically?
Yes, I've thought of that. If instead of inserting a <p> we inserted a <p class="moz_tb_predef"> (or similar), then we could attach the chosen settings to that class.

Sadly, the Mozilla Core editor predates CSS somewhat, well, CSS was bolted on later. Proper CSS support is desirable, see also bug 1193631 and its duplicates.

If I may say so, I am glad of the evidence shown on this page that a Thunderbird developer made an effort to fix this problem.

It is a shame that the bug still exists and that work on it (judging by this page) seems to have stalled.

One of the comments above says that the problem is hard to fix. OK. Yet, what's going wrong here is something really basic - Thunderbird is not letting me type, or return to typing, in the font that I have chosen. Moreover, I did not find, last time I tried it, that switching to 'Body text' mode obviated the problem. This problem - together admittedly with some others - make it a pain to use Thunderbird and sometimes results in e-mail formatting for which I feel the need to apologise to the recipient.

Perhaps now that Thunderbird is recruiting extra staff, this problem - which, in one form or another, seems to stretch back the better part of a decade - can be fixed.

Flags: needinfo?(jorgk)

Currently no plans for fixing this, mostly because the problems stem from Mozilla's HTML editor.

Flags: needinfo?(jorgk)

It is disappointing that there are no plans to fix the problem. Users of MS Word or Outlook wouldn't put up with a fundamental bug like this.

To avoid the worst of the problem, whenever I create a new email in Thunderbird I enter "Hi xxx. Return. Return. Regards, me." Then I go back to editing the body of the email. It'll still often mess-up if I switch to another application and come back to the email but I have to put up with that.

I've got so used to doing that I even find myself doing it at work when using Outlook!

(In reply to Jorg K (GMT+1) from comment #13)

Currently no plans for fixing this, mostly because the problems stem from Mozilla's HTML editor.

If Mozilla's HTML editor is bad, we should consider developing a state of the art HTML editor for Thunderbird.

The requirements to be met are very simple:

  • the editor should offer WYSIWYG as well as HTML source code
  • the HTML should be stylable with CSS
  • it should be side-effect free

The first point guarantees easy editing and full control over the content, the second point allows the styling of the HTML in Thunderbird's settings (default font xyz) as well as full flexibility for power users and the third point should be the result from point one and two.

In Thunderbird we do not have a side-effect free editor: the fonts change arbitrarily, I cannot enforce a certain design and typography and editing mails from other senders is sometimes a nightmare.

Just my two cents.

Hi Jorg,
As you have many complains on this subject and that a solution is possible (new publisher) why not launch a development and whether to solicit users via a crowdfunding platform ???
Cordially
Jean Claude

The problem is that the TB Write/compose window is controlled be the Mozilla editor which is a complicated piece of code and not under Thunderbird control. It would need a very skilled person to tackle this bug here. An alternative would be to replace the HTML editor in the compose window by some other "standard" HTML editor.

I admit that losing the font under certain circumstances it inconvenient, but this case can easily be detected and corrected manually.

No it's not always possible to detect the defect.
I had seen messages with no différence on fonts when you click "SEND" and you discover the différence when you receive the answer!

To have a correct result in terms of font, it is necessary to intervene manually systematically.

I understood that the problem is due to differences between publisher; the precaution to take is to make a message without being interrupted!
TB is not interruptible!

Jcgh78
re :I had seen messages with no différence on fonts when you click "SEND" and you discover the différence when you receive the answer!

But do you see the differences in your original saved 'sent' message located in the 'Sent' folder?

Note: If responding - reply - to a message that has hardcoded css html in the received email which the sender included, then it can influence the font when replying.
As it is not always known what fonts are available on all computers and as users can choose their own font when viewing/writing emails, it is perhaps a better solution to not include hardcoded html on font in the email.

See Also: → 1718112
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.