Description: https://drive.google.com/file/d/1CPiCDEjSRLTxSGd0981Vy1mbOeS7dQJH/view?usp=sharing https://drive.google.com/file/d/1_XVxLkWUBt1axkf9RiQrXXdMV4EKd0lE/view?usp=sharing Steps to Reproduce: 1.. 2. 3. Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: .
Created attachment 203787 [details] Video
Created attachment 203788 [details] Video
Created attachment 203789 [details] File in the video
Danat: please always include written steps and not only these videos.
(In reply to Buovjaga from comment #4) > Danat: please always include written steps and not only these videos. They are not random. I put on my list those who respond to me often, and I erase from my list those who don't want to be notified
(In reply to Buovjaga from comment #4) > Danat: please always include written steps and not only these videos. Ok I will 1. Open a document 2. Write an Arabic word 3. Select and copy one letter in between letters Result: it does not always copy as copy button is gray Expected result: always can copy
I was able to reproduce in these versions: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 620(Build:0) CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to jcline from comment #7) > I was able to reproduce in these versions: When you can repro, change the status to NEW. Another note to Danat: remember to copy to your reports the version info from Help - About by clicking the copy button next to "Version information".
Danat, in the first video, we see that the selection gets cleared right when, or just before, you right-click it to get the context menu; while in the second video, that doesn't happen. Can you explain what changed between the two videos, in your setup? Also, what happens if you select, then press the shortcut key for copying? Does that always succeed? Sometimes fail? I cannot reproduce this with: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fbde63c9c689f91c150062023054b6cbe7b3ceaf CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
jcline: per comment 9, can you detail which steps you took to reproduce?
(In reply to Eyal Rozenberg from comment #9) > Danat, in the first video, we see that the selection gets cleared right > when, or just before, you right-click it to get the context menu; while in > the second video, that doesn't happen. Can you explain what changed between > the two videos, in your setup? > > Also, what happens if you select, then press the shortcut key for copying? > Does that always succeed? Sometimes fail? > > I cannot reproduce this with: > > Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: fbde63c9c689f91c150062023054b6cbe7b3ceaf > CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 > Locale: en-IL (en_IL); UI: en-US I didn't do anything, just tried to copy without any hidden actions. Also I don't use a shortcut, I use mouse
Sometimes reproducible indeed. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 620(Build:0) CPU threads: 8; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: en-US (fr_FR); UI: en-US Calc: threaded
Created attachment 203818 [details] Demonstration of the issue
Created attachment 203819 [details] Horziontal point of clicking affects de-selection Ok, I now see what's going on. If you click on the right side of the ع, then it remains selected. But if you click it to the left of some point around its horizontal middle, then it's de-selected - just like if you were to right-click anywhere outside the selected area. So, the problem seems to be that the decision of whether your click is inside or outside the selection "perceives" the selection differently then how it's actually displayed on screen. Danat, nutca, jcline - can you confirm it's the same for you?
(In reply to Eyal Rozenberg from comment #14) > Created attachment 203819 [details] > Horziontal point of clicking affects de-selection > > Ok, I now see what's going on. If you click on the right side of the ع, then > it remains selected. But if you click it to the left of some point around > its horizontal middle, then it's de-selected - just like if you were to > right-click anywhere outside the selected area. So, the problem seems to be > that the decision of whether your click is inside or outside the selection > "perceives" the selection differently then how it's actually displayed on > screen. > > Danat, nutca, jcline - can you confirm it's the same for you? I feel like this isn't the case. It is a sometimes bug. Most of the times, it will allow you to copy no matter where you click I think it's worth looking in the piece of the code that's responsible for that graying of buttons, then, hopefully, you'll reason out the root of the bug
Repro already with the oldest of linux-43all bibisect repo. This discrepancy in behaviour when clicking to left/right side of a character is somehow familiar to me, but I could not find any related or similar report.
(In reply to Buovjaga from comment #16) I'll also add that, indeed, I have only been able to reproduce this in Writer - but not in textboxes (e.g. Writer, Draw), nor in Calc cells.