1896960 - When setting custom color in edit, they disappear after closing pane

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[david]

Steps to reproduce:

edit HTML message
highlight text
click color button on HTML compose menu bar
Select a color and tweak it and click 'add to custom colors'
Click OK and return to edit mode

Actual results:

click the color button again in compose window and the custom colors that were added no longer appear. Once a custom color is added, it should remain.

Expected results:

when clicking the color button again, the custom colors should still be on the color pane for further use. This feature worked in 102 and in 91, but does not work in 115.

Comment 1

[Magnus Melin [:mkmelin]]

Seems to work for me.

Comment 2

[david]

Please recheck. I have used Thunderbird (and even Betterbird), plus beta and daily, with and without troubleshoot mode, on two PCs, and the results have been the same: I can create custom color, but on clicking the feature a second time, the custom colors are not there. Using Windows 11, 64-bit. This has also been reported on SUMO by users.

Comment 3

[chrizilla]

Can reproduce in TB 115.

Following the steps above, the customized color is only available as "last picked color", but not in choose a color > custom colors.

Comment 4

[david]

That is a different workflow and is not providing an accumulation of custom colors, as is how the panel is constructed. What you wrote is a workaround for just one color. This is still an active bug. I look forward to seeing it fixed.

Comment 5

[chrizilla]

(In reply to david from comment #4)
I think you misunderstood. Comment #3 reproduced and confirmed your report.

Comment 6

[Francesco]

Alice, can you find the regression?

Comment 7

[Alice0775 White]

I can reproduce the color picker bug on Firefox126.0 Windows11, but not on Ubuntu22.04.
Str:

1. Open https://developer.mozilla.org/ja/docs/Web/HTML/Element/input/color
2. Click on a color box of HEAD and create and add custom color, close the picker
3. Click on a color box of BODY

AR:
The colors created are not listed.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2530f7588e103e1d608e8100f5a97d1b8ff4f060&tochange=9e1bb956dc0d7d1c50a3d99201ec7fce1f10728c

Suspect: Bug 960984 - Implement the list attribute for <input type=color>.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

:evilpie, since you are the author of the regressor, bug 960984, could you take a look?

For more information, please visit BugBot documentation.

Comment 9

[Francesco]

Thank you, Alice, great idea to reproduce the regression in Firefox!

Comment 11

[Tom S [:evilpie]]

Attachment: Bug 1896960 - Preserve the user's custom colors between multiple color pickers. r?emilio

I think there is no good way of combining support for datalists and
whatever the user picked. So I just treat the datalist colors as an
overwrite.

Comment 12

[Pashta MaryMoon]

Sorry -- but I have no idea what you mean by datalist colours or overwrite

Comment 13

[Tom S [:evilpie]]

Datalist colors are described here on MDN. Probably doesn't apply to Thunderbird and everything should work as before.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/def90fc8f64b
Preserve the user's custom colors between multiple color pickers. r=emilio

Comment 15

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/def90fc8f64b

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:evilpie, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox127 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[Monica Chiorean]

I was able to reproduce the issue on Win11 using FF build 126.0 and steps from comment#7.
Verified as fixed on Win11/Mac12.6 using FF builds 128.0b8 and 129.0a1.