https://bugs.documentfoundation.org/show_bug.cgi?id=163161
--- Comment #6 from [email protected] --- 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? -- You are receiving this mail because: You are the assignee for the bug.
