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:
"...when copying the color hex codes, the hash is included." How? What are you picking/copying with, and where are you picking from?
Created attachment 196732 [details] Screen recording
Added video of the steps to reproduce. Hopefully that makes clear what I mean.
(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
*** Bug 166777 has been marked as a duplicate of this bug. ***
Version: 25.2.3.2 Component: Styles & Formatting / UI / Color Picker When attempting to input a hexadecimal color code into the "Hex" input field within the Paragraph Style's Area tab, if the copied hex code includes a leading pound sign (#), as is the case when using the native color picker in Mozilla Firefox, LibreOffice Writer exhibits incorrect parsing behavior. The "Hex" input box has a hard and displayed input limit of 6 characters. Although the leading # is automatically deleted from the input field, it is evidently counted as a character in this 6-character input buffer. This causes the actual six-digit hexadecimal value to be truncated, specifically resulting in the loss of the last hexadecimal digit, which is then incorrectly substituted with a 0. This forces the user to manually correct the last digit, after finding out what the digit actually is since Firefox automatically copies the value to the clipboard so it is not likely to have been seen or remembered first. Steps to Reproduce: Open LibreOffice Writer. Open a document (e.g., a new blank document or a template you are editing). Open the Styles deck (Ctrl + F5). Go to the Paragraph Styles tab. Right-click on any paragraph style (e.g., "Preformatted Text" or "Text Body") and select "Edit Style..." Navigate to the "Area" tab. Click the "Color" button (under the "Fill" section). This will reveal the "Colors," "Active," and "New" columns. Locate the "Hex" input box under the "New" column (below the R, G, B fields). Copy a standard 7-character hexadecimal color code (including the leading #) from an external source, such as Firefox's Eyedropper tool. Example Code to Use: #e9eef6 Paste this code into the "Hex" input box. Observed Behavior: The leading # character is automatically deleted from the input field. However, due to the 6-character limit and the # being counted, the last digit of the original 6-digit hexadecimal value is incorrectly truncated/dropped, and the field displays the value with a 0 in its place. For example, pasting #e9eef6 results in e9eef0 being displayed in the "Hex" input box. The "New" color preview box updates to show the color for the incorrectly truncated value (e9eef0), not the intended color (e9eef6). The user must manually re-enter the correct last digit to achieve the desired color. When manually typing into the "Hex" input box, it strictly enforces the 6-character limit, with subsequent digits being dropped and remaining characters auto-filling with 0s. Expected Behavior: The "Hex" input field should intelligently strip non-hexadecimal characters (like #) without counting them towards the valid 6-digit hexadecimal input. When a 7-character hex code (e.g., #RRGGBB) is pasted, the input field should correctly display the full 6-digit hex code (RRGGBB) without any truncation or substitution of valid digits. The "New" color preview box should immediately reflect the accurately pasted 6-digit hexadecimal color. The input field should allow entry of up to 6 valid hexadecimal characters, handling non-hex characters gracefully (e.g., stripping them without affecting the 6-character limit for valid hex digits). Impact: This behavior creates unnecessary friction in the user workflow, requiring a manual remembrance and correction for a common input method. It hinders the ability to precisely and efficiently apply specific colors obtained from web sources. I can't believe this issue has not been corrected already since it was reported last year. If no developers want to tackle it, to save time can someone point me to the relevant file(s) in the source code to implement a fix?
Yes, maybe a bit more was needed for the tweak to bug 123291 to fully handle the leading Hash while pasting RGB color as HEX. The 6 char RGB is fine, but the 7 chr with # included ought to be handled.
"the 7 chr with # included ought to be handled." Actually the more I think about this, aside from the current problem of the final digit being truncated, that input field for the color should not only allow the preceding pound/hash symbol, it should add it if not included in the input. The stored string value should retain the "#" and display it in the input field, so it is included if copied for use elsewhere. That string variable wouldn't preclude the existing use of the numerical variable already being used to store the color value. The reason for requiring the # is that web development, e.g. CSS, already requires colors to be prefaced with the pound/hash/# symbol which is a very common use case for a word processor and defacto or ersatz (depending upon your perspective) HTML editor like LibreOffice Writer. Copying and pasting colors back and forth between LibreOffice Writer and Firefox or other web browser or development tool would be seamless with the # prepended to the color value.