Bug 163161 - HexColorControl field validation, remove # when pasting hex value for color
Summary: HexColorControl field validation, remove # when pasting hex value for color
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Color-Picker-Dialog Area-Fill-Tab-Color
  Show dependency treegraph
 
Reported: 2024-09-26 10:01 UTC by Henrik
Modified: 2024-09-26 21:49 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Screen recording (1.88 MB, video/mp4)
2024-09-26 20:08 UTC, Henrik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik 2024-09-26 10:01:35 UTC
Description:
When working with colors in LibreOffice I sometimes copy and paste the hexadecimal color codes into the color picker. Sometimes when copying the color hex codes, the hash is included. When pasting a color hex code with a hash into the color picker field for hex codes, the color picker complains about the hex code being too long and then proceeds to remove the hash AND the last character of the hex code, thereby leaving the wrong hex code and therefore also the wrong color.

Steps to Reproduce:
1. Copy the following hex code including the hash: #49423A
2. Open LibreOffice's color picker (in any module).
3. Paste the copied hex code into the "Hex #:" field.

Actual Results:
The color picker gives an error message and the entered hex code is now '49423'.

Expected Results:
The color picker should automatically recognise and remove the hash and enter the desired hex code '49423A'.


Reproducible: Always


User Profile Reset: No

Additional Info:
Comment 1 V Stuart Foote 2024-09-26 14:54:57 UTC
"...when copying the color hex codes, the hash is included."

How? What are you picking/copying with, and where are you picking from?
Comment 2 Henrik 2024-09-26 20:08:40 UTC
Created attachment 196732 [details]
Screen recording
Comment 3 Henrik 2024-09-26 20:09:30 UTC
Added video of the steps to reproduce. Hopefully that makes clear what I mean.
Comment 4 V Stuart Foote 2024-09-26 21:44:58 UTC
(In reply to Henrik from comment #3)
> Added video of the steps to reproduce. Hopefully that makes clear what I
> mean.

OK thanks! Confirm the request for allowing the "#" character, and see we have an issue.

Reasonable enhancement, and needed for consistency as it already works like that with pasted entry in the Color Picker dialog across the UI, but not the Area fill.

The 'Hex #' input field  (colorpage.ui hex_custom [1]) on the Area fill 'Color' tab rejects a pasted color value with a preceding #.

Inconsistent in that the 'Hex' input field (colorpickerdialog.ui hexEntry [2]) on the 'Pick a Color' dialog accepts the paste and ignore the preceding # correctly parsing the color.

Both look to point to hexcolorcontrol.cxx, but the Area fill's Color entry errors with warning:

'The inserted text exceeded the maximum length of this text field. The text was truncated'.

While the color picker accepts it.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/cui/source/inc/cuitabarea.hxx?r=48e4a871&fi=m_xHexcustom#681
[2] https://opengrok.libreoffice.org/xref/core/cui/source/dialogs/colorpicker.cxx?r=ecf6f6f2#821