Users report an issue when pasting hex color codes with a leading # (e.g., #1a2331) into Discourse’s color input fields during theme customization. The current behavior truncates the string to six characters first — removing the last digit — then strips the #, resulting in an incorrect color value like 1a233. Canapin suggests the # should be stripped before character counting to avoid data loss. dax notes that while some color pickers allow format selection, many do not, making this a common pain point. nathank agrees the behavior remains problematic and calls for automatic handling of leading # characters as a UX improvement. The issue is reproducible in Discourse 2.4.0.beta7 on Chrome/Windows 10. No major drawbacks are anticipated from fixing it, and users suggest it would be a valuable polish for theme customization workflows.
(not sure this should be considered as a bug or an ux issue)
Hi,
When manipulating colors hex on your computer, you often copy-paste hex values with a leading # from your clipboard.
When pasting, for example, #1a2331 into a color text input, there is a minor issue:
First, the last character from your string #1a2331 is removed since the input is limited to six characters and #1a2331 has seven because of the #.
And after that, the # is automatically stripped from the string.
So the final value in your input after you paste it becomes: 1a233 with the missing last character 1, resulting in wrong color value.
A solution to fix this could be that the # should be removed before the number of characters from your string is checked.
To reproduce the issue, paste the string #1a2331 in any color text input from your Discourse color theme customization.
Since I can remember the insertion of the hexadecimal codes in the Discourse palette has always been exactly as you described it. You must manually enter only the hexadecimal number and omit #
Many color pickers give you the option of copying the hexadecimal code by previously deciding the code format
Sure I get this, it’s just that this behavior is a bit odd. I had to check the value I was coping pasting a couple times before noticing that the last number of my string was missing in the input. I didn’t understand why the value was invalid at first and I guess this specific copy paste behavior could be improved with no drawback.
