Bug 144890 - Invalid selection area when text in LTR run is selected within an RTL paragraph
Summary: Invalid selection area when text in LTR run is selected within an RTL paragraph
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.1.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0 target:7.2.6 target:7.3.0.2
Keywords: bibisected, bisected, regression
: 146154 (view as bug list)
Depends on:
Blocks: RTL-CTL Selection
  Show dependency treegraph
 
Reported: 2021-10-03 10:37 UTC by h.rosemarin
Modified: 2022-04-11 19:12 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Comparison of the behavior in LO 7.1.5 and 7.2.4 (3.07 MB, video/mp4)
2021-12-31 20:45 UTC, William Friedman
Details
LTR-RTL Bug Behavior Discrepancy (1.57 MB, video/mp4)
2022-01-02 19:49 UTC, William Friedman
Details
Selecting just RTL text in LTR mode does not show a selection box (545.80 KB, video/mp4)
2022-04-11 15:58 UTC, William Friedman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description h.rosemarin 2021-10-03 10:37:12 UTC
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
Comment 1 Xisco Faulí 2021-10-04 09:26:12 UTC
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
Comment 2 h.rosemarin 2021-10-04 10:23:28 UTC
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
Comment 3 Xisco Faulí 2021-10-04 10:39:32 UTC
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
Comment 4 h.rosemarin 2021-10-04 10:43:01 UTC
that's promising, and something to look for in the next release

have you confirmed the behavior in the 7.2.1.2 release?
Comment 5 Dieter 2021-12-31 08:13:08 UTC
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
Comment 6 h.rosemarin 2021-12-31 11:29:23 UTC
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)
Comment 7 William Friedman 2021-12-31 20:45:32 UTC
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.
Comment 8 h.rosemarin 2022-01-01 21:43:27 UTC
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
Comment 9 QA Administrators 2022-01-02 03:57:13 UTC Comment hidden (obsolete)
Comment 10 Dieter 2022-01-02 12:01:32 UTC
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.
Comment 11 Dieter 2022-01-02 12:03:53 UTC
William, feel free to set bug status to NEW, if you think you can reproduce it.
Comment 12 Dieter 2022-01-02 12:05:14 UTC
*** Bug 146154 has been marked as a duplicate of this bug. ***
Comment 13 Eyal Rozenberg 2022-01-02 18:51:42 UTC
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
Comment 14 William Friedman 2022-01-02 19:49:47 UTC
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.
Comment 15 raal 2022-01-04 16:25:56 UTC
(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 sha:ec50b9e5eaec7c94df35617676077ef0d65cecc7

https://git.libreoffice.org/core/+/ec50b9e5eaec7c94df35617676077ef0d65cecc7
  no need to allocate Sw2LinesPos separately on heap

Adding CC to: Noel Grandin
Comment 16 Commit Notification 2022-01-08 07:21:55 UTC
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.
Comment 17 Xisco Faulí 2022-01-10 15:55:53 UTC
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!!
Comment 18 Commit Notification 2022-01-10 15:57:00 UTC
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.
Comment 19 Commit Notification 2022-01-10 17:51:37 UTC
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.
Comment 20 William Friedman 2022-04-11 15:57:46 UTC
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
Comment 21 William Friedman 2022-04-11 15:58:49 UTC
Created attachment 179472 [details]
Selecting just RTL text in LTR mode does not show a selection box
Comment 22 Eyal Rozenberg 2022-04-11 17:43:29 UTC
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?
Comment 23 William Friedman 2022-04-11 18:00:06 UTC
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.
Comment 24 Eyal Rozenberg 2022-04-11 18:29:43 UTC
(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.
Comment 25 Dieter 2022-04-11 18:31:49 UTC
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
Comment 26 William Friedman 2022-04-11 18:48:44 UTC
My apologies. I will open a new bug, since it also appears in 7.3.2.
Comment 27 William Friedman 2022-04-11 19:12:15 UTC
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!