Apache OpenOffice (AOO) Bugzilla – Issue 126695
Tabs that bisect words and result in a new line result in wonky drag-selection of text.
Last modified: 2016-02-21 17:51:19 UTC
Environment: Windows 10 64-bit AOO420m1(Build:9800) - Rev. 1692551 Issue: If I use the tab key to bisect a word (press tab with the cursor in the middle of a word), and the tab results in a newline being created, trying to use drag-selection of the left word segment results in the right-most letter not being highlighted. Drag-selecting leftwards or rightwards both have the issue. Animation showing the behavior in action: http://i.imgur.com/knCGqgD.gifv I press tab in the middle of "maecenas" and try to highlight "maec" but it gives me issues with the letter c. Steps to replicate: - Go to tools > Options > OpenOffice Writer > General - Set tab stops to something large like 2,50" (inches) to facilitate tabs that result in new lines. - Press OK - Use the tab key to bisect a word (so "elephant" becomes "elep hant" for example) but the tabbing action has to result on "hant" being on a new line. - Attempt to highlight "elep" using dragging left or right. - It will behave oddly during the highlighting process and not quite work right. - Attempt to put the cursor after the letter p by clicking to the right of it - It will place the cursor immediately to the left of the letter p.
I tested my same issue in Microsoft Word 2013 and found that this behavior does not occur there. Selecting tabbed words resulting in a new line behaves as expected and the cursor can be placed where I click.
Environment used: Windows 10 64-bit OpenOffice version 4.1.2 build: AOO412m3(Build:9782) - Rev. 1709696 Configuration: Tab spacing : Default (0.49''-inch) I was able to successfully replicate the bug using the steps provided. Here are the steps I took to replicate the bug. 1. Open a blank document. 2. Type a sentence that reaches at least the end of the page. 3. At the last word on the first line, hit the tab key anywhere in that word. For example, splitting the word “cattle” into “cat” and “tle”. 4. Place cursor after the last character on the first line and drag left to select the last word. The result of this should be everything in the last word except the last character should be selected. (See attachments.) 5. Similarly, place the cursor in front of the last word and drag right to select the last word.The result should be the same as the previous step. The failure looks like OpenOffice does not place the input cursor in the correct location, resulting in partial highlighted selections. If you open the attached .odt file and try to move the cursor to the end of the last letter on the splitted line, the cursor will go infront of the last letter rather than behind.
Created attachment 85315 [details] OpenOfficeWriter test document
Created attachment 85316 [details] Picture snapshot from the document
Created attachment 85319 [details] Selecting the tab-preceding text includes the tab This screen capture of the demonstration test file shows that successfully selecting the last character before the "cat|tle" tab produces a selection that ends with the cursor at the beginning of the next line. This is conceptually in front of the tab, which is what causes the "tle" to be intended. This is an odd case. For tabs in the middle of words that do not cause part of the word to go to a new line, there is a separate wide space that corresponds to the tab-induced separator between the separated parts of the word. That separating "space" is independently selectable. In this odd case, the tab-induced spacing is revealed as the indentation of the second line. Note that this much, by itself, would not be a significant defect, if the selection was really "cat" (i.e., everything actually in the text, up to the but not including the inserted tab. But there's more ... Demonstrated here also with AOO 4.1.2 on Windows 10. The same behavior is exhibited with LibreOffice 5.0, indicating that this is a very old behavior that has been in the code base for many years.
(In reply to orcmid from comment #5) > Created attachment 85319 [details] > Selecting the tab-preceding text includes the tab That attachment title is incorrect. The tab is not included in the selection, but the stepping to the next line is.
(In reply to orcmid from comment #6) > (In reply to orcmid from comment #5) > > Created attachment 85319 [details] > > Selecting the tab-preceding text includes the tab > That attachment title is incorrect. The tab is not included in the > selection, but the stepping to the next line is. as if the letter before the tab is extended to where the tab is moved to the new line along with the remainder of the word.
Created attachment 85320 [details] Cut and Paste of the Selection I did not try dragging the selection anywhere. What I did do was cut the selection shown in attachment 85319 [details] and paste in front of the "tle" text on the second line. Notice that the tab is not part of that selection. The tab is still at the beginning of the second line. However, a space is brought into the word, giving us "cat tle". Furthermore, the last work on the first line now has the problem. The word "word" is only fully selected if the selection extends to the end of the line, with cursor at the beginning of the second line. CONFIRMATION: What we have is that a tab insertion that cannot be satisfied without going to a new line always has the described impact on the character immediately before the tab insertion. It would obviously be beneficial if spacing induced by the insertion were separately selectable as it is when the tab-induced separation is all on a single line. (I did not check what happens if it is the second of two tab insertions that takes the second insertion to a new line.) COLLATERAL PROBLEM: When the word preceding a tab insertion having the identified behavior is cut/copied and pasted, a blank space is inserted. Confirmed with AOO 4.1.2 on Windows 10 and also LibreOffice 5.0.
The behavior described in this issue statement is confirmed. 1. Meanwhile, it is possible to work around this case so long as the user is observant. 2. It would also be useful if the handling of tabs in Writer (and probably everywhere else that paragraph formatting is provided) were clearly identified in some form of documentation, with some sort of caveat about line-breaking cases. 3. The inducement of a trailing space as part of the selection is a defect that is likely curable by not treating soft line breaks as extensions of the final character on the line before the break of a tab to the next line. There is no estimate of how much effort or time that might take and when a developer might turn attention to it.