Bug 129933 - Hex color code truncated, when Pasting into field of the "Pick a Color" dialog
Summary: Hex color code truncated, when Pasting into field of the "Pick a Color" dialog
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.0.0 target:6.4.1 target:6.3.6
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-01-10 18:26 UTC by John M. Adams
Modified: 2020-02-04 14:08 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of Color Picker Dialogue, with Warning Dialogue (70.27 KB, image/png)
2020-01-10 18:28 UTC, John M. Adams
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John M. Adams 2020-01-10 18:26:52 UTC
Description:
"Pick a Color" Dialogue fails to replace selected field value, when pasting. Pasted value is replaced with "b0". Common across all products in 6.2.8.2 release.

Steps to Reproduce:
1. Reach a position where a color can be selected (Font Color, Background, Etc)
2. Select the option "Custom Color...", to open the "Pick a Color" Dialogue.
3. Copy into clipboard any valid 6-character hex color code (such as the existing hex color value in field "Hex #:").
4. Select-All, on the value in the field "Hex #".
5. Paste the 6-character hex value (Either Method: Right-Click Menu or keyboard Ctrl-V).

Actual Results:
A warning dialogue is invoked:
Title: "Warning"
Message: "The inserted text exceeded the maximum length of this text field. The text was truncated."
Button: "OK"
After dismissing the warning, field "Hex #" is filled with the value "b0".

Expected Results:
The selected contents of the "Hex #" field are replaced with the valid clipboard contents.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
I selected the product "LibreOffice" because this dialogue is common across all products, and the bug was confirmed in: LO Writer, LO Calc, LO Draw, LO Impress, and LO Base. I tried to replicate in LO Math, but could not find any options that used the color-picker dialogue.

I tested LibreOffice 5.3.2.2 on another machine, and the bug is not yet present. The same actions produce the expected results.


Version: 6.2.8.2 (x64)
Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee
CPU threads: 12; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 1 John M. Adams 2020-01-10 18:28:25 UTC
Created attachment 157070 [details]
Screenshot of Color Picker Dialogue, with Warning Dialogue
Comment 2 V Stuart Foote 2020-01-10 21:19:55 UTC
Can not reproduce on Windows 10 64-bit with Windows builds 6.3.4.2 and current master/6.5.0

Via the Custom Color button on the color picker, and opening the 'Pick a Color' dialog.  Working in either RGB or HSB mode (a selection made by radio button) the selecting/highlighting of the field text in the 'Hex #' field is fully replaced. 

When typing or when pasting a Hex color string held in clipboard.

I had one occurrence of the warning shown while pasting over the selected stirg of the Hex # field, but was unable to duplicate. ~30 other attempts using various panel selections in the dialog were all fine.

Seems more like a transient clipboard issue--nothing reproducible/actionable.
Comment 3 Telesto 2020-01-10 21:28:29 UTC
Repro with
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 42a1a1c6b91907f81e15066ffab219411f18c4db
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 4 Telesto 2020-01-10 21:33:12 UTC
Bisected to
author	Caolán McNamara <caolanm@redhat.com>	2018-03-08 12:17:56 +0000
committer	Caolán McNamara <caolanm@redhat.com>	2018-03-11 21:34:45 +0100
commit cf4b65c75c07142be0fcab5835188a28e839b749 (patch)
tree 41b2bd5cd5d419f33db3839c93b9e674a193c2c1
parent e0e307675cc2b962d0dcb557f4af4a34a729da66 (diff)
weld color picker
Comment 5 Telesto 2020-01-10 21:34:07 UTC
Adding cc to: Caolán McNamara
Comment 6 Telesto 2020-01-10 21:37:38 UTC
STR
1. Click the Font Color & Select custom Color
2. Select the default hex "ffffff"
3. CTRL+C
4. CTRL+V
Comment 7 Ming Hua 2020-01-10 21:38:10 UTC
I can reproduce very reliably in 6.4.0 RC1.
Version: 6.4.0.1 (x64)
Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f
CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: zh-CN (zh_CN); UI-Language: en-US
Calc: threaded

The key step seems to be step 4 in comment #0:
> 4. Select-All, on the value in the field "Hex #".
Either use the right-click menu, or keyboard shortcut Ctrl+A, or mouse to drag and highlight the whole 6-digit value.

As long as the value is selected before pasting, the error dialog pops up for me every time.

FWIW, I tested with Writer and the "Font Color" and "Highlight Color" button on the toolbar to access the color picker.
Comment 8 John M. Adams 2020-01-10 23:11:17 UTC
(In reply to Ming Hua from comment #7)
> As long as the value is selected before pasting, the error dialog pops up
> for me every time.


Correct.  Sorry, I meant to add this... I found with my testing that it appears to be more a "paste as replacement" error, versus general pasting.

It's reacting as if it's following this set of steps to replace the selected value:

1) Concatenate Original Value and Pasting Value
2) Test Combined Value for Validity
3) Set the Field Value as the Substring of Combined Value, removing the Original Value

If you have 2 characters "ff" (LO picker interprets as rgb(255,0,0))...
Select it, and paste the same "ff", and it succeeds (LO picker would see "ffff" as valid).

If you delete the contents and paste "ffffff", it succeeds... but concatenation of "" and "ffffff" is valid.

If you have "ff", and paste "ffffff", it fails ("ffffffff" is invalid).
Comment 9 Caolán McNamara 2020-01-11 14:12:21 UTC
not seeing this under gen plugin under Linux, perhaps cut and paste works differently under windows so I'll need to check there
Comment 10 Caolán McNamara 2020-02-03 15:25:57 UTC
I wonder if the problem is on selecting from the end to the start, I see a bug when I do that (under gen) which https://gerrit.libreoffice.org/c/core/+/87883 will fix but I'm unsure if its the reported problem
Comment 11 V Stuart Foote 2020-02-03 16:59:33 UTC
(In reply to Caolán McNamara from comment #10)
> I wonder if the problem is on selecting from the end to the start, I see a
> bug when I do that (under gen) which
> https://gerrit.libreoffice.org/c/core/+/87883 will fix but I'm unsure if its
> the reported problem

Hey that's weird, on Windows build 6.4.0.3 and 6.3.4.2, selection of the target string backwards from end -> beginning, triggers the reported error. 

So, click into the field with edit cursor at the end, and <Shift>+<Home> to select backwards to beginning--shows the error.

Same steps, but selecting from beginning -> end of the fields value gets a clean replacement.  That is, click into the field at its start, and <Shift>+<End> to select forward to the end--works correctly.

Tabbing into the field positions the edit cursor at the start, and selects forward. Guess that was why I didn't see it in my earlier comment--I'd either tab advance into the field, or click in with cursor at start and click select. Finger memory...
Comment 12 Commit Notification 2020-02-03 19:25:57 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/12f9fdfac8b41d74e9474e8966e3d28755424931

Related: tdf#129933 assert on pasting over selection in edit

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Caolán McNamara 2020-02-04 09:57:06 UTC
I think then that is the original reported problem, which is now fixed in master with backports to 6-4 and 6-3 in gerrit
Comment 14 Commit Notification 2020-02-04 10:37:45 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/1cff94d109c38cc4c929e9ab69c8d5fbd881ba84

Related: tdf#129933 assert on pasting over selection in edit

It will be available in 6.4.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2020-02-04 10:38:23 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/5acddba57e187c4a05d5bb25df36d22b829224cc

Related: tdf#129933 assert on pasting over selection in edit

It will be available in 6.3.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 V Stuart Foote 2020-02-04 14:08:25 UTC
(In reply to Caolán McNamara from comment #13)
> I think then that is the original reported problem, which is now fixed in
> master with backports to 6-4 and 6-3 in gerrit

Verified on
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 54b28638ab15f68731861ae903c732273b41f78a
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

No difference in paste outcome, backward or forward direction of selecting HEX color field value being replaced.