Open Bug 1976738 Opened 1 year ago Updated 10 months ago

Setting font and background color for compose window missing in versions after 128

Categories

(Thunderbird :: Preferences, defect, P3)

Thunderbird 140
defect

Tracking

(thunderbird_esr140 wontfix)

ASSIGNED
Tracking Status
thunderbird_esr140 --- wontfix

People

(Reporter: dskirk, Assigned: aleca)

References

(Blocks 1 open bug)

Details

(Keywords: ux-consistency)

Attachments

(3 files)

In 128 and prior versions, composition font and background color, plus link colors, could be set at Settings>General in the languages and fonts section. A screenshot is attached. This allowed setting of colors for composition window for both plain text and HTML messages. Further, the background color was not appended to outgoing messages but was for the user. This menu selection has been removed from versions after 128. Instead, a lookalike feature was added to Settings>Composition screen, but applies only to HTML messages. Please restore this feature.

Did any of this change for dark mode support, or something else?

Flags: needinfo?(alessandro)

I think you're talking about browser.display.document_color_use. Removed intentionally in bug 1956292.

The ability to set background color and font color for compose window is gone. That was a feature and I see no way in config editor to set it. The feature in prior versions was for the Thunderbird user, not recipients. It was a minor customization that has been removed. The only option now is to hope a theme is available to do this, but that seems to be a step backward. If this feature was intentionally removed, I encourage a revisit to it. Personally, I set the background to an off-white color to ease the glare of all white. Thank you for your consideration.

That feature was dependent on Firefox preferences for the browser background and foreground color.
It was a mistake inheriting it and consuming it, also because Firefox started changing a lot on their side and handling automatic contrast switching and other things that shouldn't happen in Thunderbird.

Instead, a lookalike feature was added to Settings>Composition screen, but applies only to HTML messages. Please restore this feature.

Oh, we missed that this option doesn't style plaintext message, apologies for the annoyance.
I was going to suggest to use that feature because we control those preferences.

I'll take care of fixing this.
I'm sorry for the disruption.

Assignee: nobody → alessandro
Severity: -- → S3
Status: NEW → ASSIGNED
Flags: needinfo?(alessandro)
Keywords: ux-consistency
Priority: -- → P3

How to test

  • Access Account Settings > Composition and Addressing.
  • Uncheck Compose messages in HTML format
  • Access Settings > Composition.
  • Uncheck Use reader's default colors and customize those colors.
  • Write a new message and confirm that the chosen colors are styling the compose window.
  • Send the plaintext email and ensure that the receiver doesn't have any inline styles in that email.

TODO

I'm seeking a review now to ensure that this approach makes sense, and if it does I'll add some tests.
We should also not have these convoluted options tied to the HTML formatting, but that's a longer conversation for a future improvement.

The Colours menu also allowed setting link colours, and this is still present in FF 140 (Manage Colours...). Links can be styled in TB 140 with css.

https://support.mozilla.org/en-US/questions/1518196

(In reply to sfhowes from comment #6)

The Colours menu also allowed setting link colours, and this is still present in FF 140 (Manage Colours...). Links can be styled in TB 140 with css.

https://support.mozilla.org/en-US/questions/1518196

Isn't this a dangerous pattern that can affect readability and accessibility?
Shouldn't plain links be styled by the default OS user agent?
In case of color blindness or other visual issue the OS should be in charge of controlling the theme of the application. If we allow cherry picking the color of links that could create some readability problems, especially when receiving styled HTML emails with a custom background color.

Hi, Alessandro,
FIRST, thank you for stating that you would correct this. I sincerely appreciate it.
Second, I did the test you suggested and it does nothing for plain text messages. The compose window is unchanged. I will follow this bug and do any further testing you request.
david

Hi David

Second, I did the test you suggested and it does nothing for plain text messages

Sorry, I should have specified that I confirmed the issue and that indeed doesn't work.
I have a patch up for review with a fix, which hopefully will land in 142 or 143.

Cheers,

Are the proposed changes of setting the editor's text colour and background colour also working in dark mode?

(In reply to Francesco from comment #10)

Are the proposed changes of setting the editor's text colour and background colour also working in dark mode?

If custom colors are chosen they will override any dark mode styling coming from themes or the OS.

There is a question in Support Forum which says :

140.1.0esr (64-bit)
Since the last update, the background on my Tbird messages list, email panel and in my compose email panel have turned from my eye-friendly light grey to glaring white and this is literally causing me a headache and a "flimmer" in my eyes (common in people with blue eyes).

https://support.mozilla.org/en-US/questions/1526681

I believe the above Support Question maybe what triggered this bug report regarding composing emails. But the person with the issue in Support says changes have effected alot more of Thunderbird UI.

My beta 142.0b2 using Light mode does display an incredibly white background on Message List, composing area etc.
Has there been any sudden alterations which may effect this ?

Attached image 1976738.png

Any news on this? I was asking about dark mode, since when I apply your changes to an unpacked omni.ja, I get this in dark mode. Works fine in light mode.

(In reply to Magnus Melin [:mkmelin] from comment #2)

I think you're talking about browser.display.document_color_use. Removed intentionally in bug 1956292.

The bug says "Bug 1956292 - Port bug 1898096: Replace color settings with "contrast control". r=#thunderbird-front-end-reviewers"

The problem is color settings was removed but contrast control was NOT added.

I see contrast in latest version of Firefox and checking Off does change document_color_use, so if contrast control was present in Thunderbird it would solve the issue. Well, people would need to know to change it to off for it to work.

I'd like to know just what Firefox and Thunderbird think system settings are or where one would set them. I noticed that in Firefox using Automatic (system settings) causes some html things not to show. This is not the case with Safari or Chrome. Something about system settings in Thunderbird and Firefox isn't right.

For example this html doesn't show a green bar in either Firefox or Thunderbird using default settings. It's there but doesn't display.
<td width="100%" height="10" style="padding: 0; font-size: 1px; line-height: 1px; max-height: 1px; width: 100%; background-color: #00b050; line-height: 10px; max-height: 10px; overflow: hidden">.

Duplicate of this bug: 1979848

Alessandro, here is another SUMO report, although there have been others:
https://support.mozilla.org/en-US/questions/1534186 And, from the notes here, I see several have inadvertently assumed this bug report applies to the HTML compose feature for background and font, but it applies explicitly to the setting as shown in original screenshot. You mentioned that a solution was in review and that its omission had been an oversight. Do you have an estimate on when this panel will reappear in Thunderbird? It remains a desirable feature. Thank you for all you do.
david

(In reply to Francesco from comment #13)

Any news on this? I was asking about dark mode, since when I apply your changes to an unpacked omni.ja, I get this in dark mode. Works fine in light mode.

Works fine if you set editor.document.body.style.backgroundColor and editor.document.body.style.color, that is body instead of documentElement.

Duplicate of this bug: 1990132
No longer duplicate of this bug: 1990132

Alessandro,

Is there an update on this? That panel was in 128 and seemingly forgotten. You mentioned fixing it and I will certainly appreciate it. Thank you.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: