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
Created attachment 157070 [details] Screenshot of Color Picker Dialogue, with Warning Dialogue
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.
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
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
Adding cc to: Caolán McNamara
STR 1. Click the Font Color & Select custom Color 2. Select the default hex "ffffff" 3. CTRL+C 4. CTRL+V
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.
(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).
not seeing this under gen plugin under Linux, perhaps cut and paste works differently under windows so I'll need to check there
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
(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...
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.
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
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.
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.
(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.