Selection highlighting of left-to-right text (e.g. English) which follows right-to-left text results in highlighting the text until the end of the document. to reproduce: 1. enter in a new line (copy and paste): "שלום hello" 2. try selecting the two 'l' letters
Thanks for reporting this issue. Could you please paste the info from Help - about LibreOffice ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
Version: 7.2.1.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Ubuntu package version: 1:7.2.1-0ubuntu0.20.04.1~lo1 Calc: threaded
I can't reproduce it in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: ba5156abace2e41ec4d21397c0875f7e1efd2beb CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
that's promising, and something to look for in the next release have you confirmed the behavior in the 7.2.1.2 release?
Bug 146154 discribes a similar bug. Could youl please have a look at the video and the sample docmument, to check if it is the same bug? => NEEDINFO
The other bug report (Bug 146154) is indeed very similar. You should note that there are two different issues: 1. the way highlighting changes direction with the direction of the text 2. the fact that ltr selection in mixed direction paragraph (starting with rtl text) caused an inverted selection to appear - all the document except the needed selection in Bug 146154 the last comment refers to issue #1 stating that it is NOTABUG, which is correct, at least partially. you can see in the video (or try for yourself in the attached document) that when selecting continuously it is not working correctly. when the cursor reaches the rtl text, the entire rtl text is selected, and as the selection progresses the highlighting disappears (inverted) until, finally, when the entire rtl text is selected - it is highlighted again. this is indeed a bug. as for issue # 2, it is definitely a bug, and a very annoying one. it is extremely hard to edit mixed direction text (as are most academic manuscripts)
Created attachment 177225 [details] Comparison of the behavior in LO 7.1.5 and 7.2.4 I'm pretty sure this is the same bug as the one I submitted. I hope it is helpful and not presumptuous to add here the video that I made comparing the selection behaviors in LO 7.1.5 (which worked correctly) and in LO 7.2.4 (which broke it somehow). A reversion to the behavior in 7.1.5 is needed. Thank you.
perfectly ok (to add the video), thanks hope this gets fixed I wrote a couple of papers recently using LO, and this bug really slowed me down
[Automated Action] NeedInfo-To-Unconfirmed
Comment from William Friedman (bug 146154 comment 8): Created attachment 177224 [details] Comparison of the behavior in LO 7.1.5 and 7.2.4 This video demonstrates, side-by-side, the behavior of the exact same selections on the provided test document in LO 7.1.5 (where it works correct) and LO 7.2.4.1, where it does not.
William, feel free to set bug status to NEW, if you think you can reproduce it.
*** Bug 146154 has been marked as a duplicate of this bug. ***
I can reproduce this using: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 250e4886d85a7e131da76f181b3fa7be02d1a76d but not using the 7.0.4.2 release. Exact reproduction instructions: 1. Create a new LO Writer document. 2. Type: "hello". 3. Set the paragraph direction to LTR. 4. Select the "ll" in "hello"; you may use either the mouse or keyboard for the selection. 5. Set the paragraph direction to RTL Expected result: The selection should be a rectangle covering just the ll and a bit of surrounding space - and stay that way as the direction changes. Actual results: In step 5, the selection area becomes much larger, covering the entire word hello, all of the empty space to the left edge of the page, and a bunch of empty space below the paragraph. You can de-select and try to re-select the "ll" - same effect. If there's run of RTL text earlier on the line, it doesn't get selected (as in OP's description). Indeed, this is a regression. Not sure about the relationship with bug 146154
Created attachment 177253 [details] LTR-RTL Bug Behavior Discrepancy Eyal's comment is a precise and simpler demonstration of the problem. Please also note that the same thing happens with RTL text in LTR mode, but the selection problem appears slightly differently. When I followed Eyal's directions, selecting the "ll" of "hello" in LTR mode and set it to RTL mode, the entire text and more is erroneously selected. However, when I type שלום in RTL mode, select the letters לו and then set it to LTR mode, the ש is (correctly) outside the erroneously large selection box. I assume the same fix will apply, but I figured it was worth noting the discrepancy in erroneous behavior here. The attached video demonstrates the difference between the bug's behavior with LTR text in RTL mode and RTL text in LTR mode, also comparing it with the correct behavior in LO 7.1.5.2 for both.
(In reply to Eyal Rozenberg from comment #13) > I can reproduce this using: > > > Exact reproduction instructions: > Bisected to: dbbe8ec41c989ec5ceb0a0dfedb4e881b5608380 is the first bad commit commit dbbe8ec41c989ec5ceb0a0dfedb4e881b5608380 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Tue Jun 15 15:01:37 2021 -0700 source ec50b9e5eaec7c94df35617676077ef0d65cecc7 https://git.libreoffice.org/core/+/ec50b9e5eaec7c94df35617676077ef0d65cecc7 no need to allocate Sw2LinesPos separately on heap Adding CC to: Noel Grandin
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/563af8fd15aa37e75af8882cccbdf8914ebe8e61 tdf#144890 Invalid selection area when text in LTR run It will be available in 7.4.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.
Verified in Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: bf883027ee62ece0844730572305094f53daa521 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Noel, thanks for fixing this issue!!
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/2de9b8ad9eaadb420b70ed9b5604c876f161c04c tdf#144890 Invalid selection area when text in LTR run It will be available in 7.2.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/0c54ddf5237914560a121453b41c8e3a50f02019 tdf#144890 Invalid selection area when text in LTR run It will be available in 7.3.0.2. 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 have now downloaded 7.2.6.2 (version info pasted at the end), and sadly have to report that this bug has *not* been completely fixed. The issue arises with selecting RTL text in LTR mode. When only RTL characters are selected, the selection box does not appear. For some reason, this does not occur when only LTR characters are selected in RTL mode. Please see the attached video demonstrating the problem. To reproduce: 1. Set text to LTR mode. 2. Type RTL text (e.g., Hebrew). 3. Select only RTL characters in the middle of the text. Notice that the selection box does not appear. 4. Bold or italicize the text. Notice that the selected text changes, despite the absence of the selection box. Expected behavior: Selection box appears around selected text. Actual behavior: No selection box appears. Version: 7.2.6.2 (x64) / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Created attachment 179472 [details] Selecting just RTL text in LTR mode does not show a selection box
Why is this reopened? I can't reproduce with: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: fb9270b238cba4f36e595c5d7f4d85f6f3f18e1c CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US was this broken by a recent nightly?
I reopened because of the remnant of the bug I experienced in 7.2.6.2 (to which the patch had been pushed), which I described above and attached a video showing -- no selection box appears around RTL text selected by itself in LTR mode. I have not tested on later versions, but it seems strange that the patch would function differently in different versions.
(In reply to William Friedman from comment #23) So, I'm not the expert on the rules on this bugzilla, but IIANM, when a bug has been resolved on the master branch, it's FIXED. And if not that, then at least master + next release + current release. 7.2.* is an "old" branch. So, I believe you should mark it as FIXED again.
William, it is possible to reopen a bug with status RESOLVED FIXED, but you should never reopen a bug with status VERIFIED FIXED. If you think, the bug is back, please open a new report. But you should test with master or at least with LO 7.3.2. Thank you. => VERIFIED FIXED
My apologies. I will open a new bug, since it also appears in 7.3.2.
Just to close the loop here, the remnant of the bug I described appeared in 7.2.6.2 and 7.3.1, but is fixed in 7.3.2.2. Kudos to whomever or whatever fixed it!