Bug 169477 - [Writer] Pressing `End` then `Home` on a line ending with a hyphenated word—or on a line without spaces that's split over 2 lines—moves the cursor to the beginning of the next line (plus a few other bugs)
Summary: [Writer] Pressing `End` then `Home` on a line ending with a hyphenated word—o...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.8.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-11-16 12:42 UTC by yarma22
Modified: 2026-02-08 22:20 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Lorem Ipsum example to illustrate the bug (for bugs #1, #2, #3, #4 and #5) (51.39 KB, application/vnd.oasis.opendocument.text)
2025-11-16 12:44 UTC, yarma22 		Details
Lorem Ipsum example to illustrate the split URL bugs (for bugs #6, #7, #8 and #9) (50.58 KB, application/vnd.oasis.opendocument.text)
2025-11-20 09:33 UTC, yarma22 		Details
Lorem Ipsum example to illustrate the split "long" line without spaces bugs (for bugs #6, #7, #8 and #9) (42.61 KB, application/vnd.oasis.opendocument.text)
2025-11-20 10:14 UTC, yarma22 		Details
Lorem Ipsum example to illustrate the split URL bug with enough text afterwards (for bug #10) (47.27 KB, application/vnd.oasis.opendocument.text)
2025-11-20 11:29 UTC, yarma22 		Details
N/A (47.27 KB, application/vnd.oasis.opendocument.text)
2025-11-20 11:30 UTC, yarma22 		Details
Lorem Ipsum example to illustrate the split URL case without enough text afterwards (for bug #10) (46.58 KB, application/vnd.oasis.opendocument.text)
2025-11-20 11:34 UTC, yarma22 		Details
N/A (47.27 KB, application/vnd.oasis.opendocument.text)
2025-11-20 11:35 UTC, yarma22 		Details
Lorem Ipsum example to illustrate the split hypehnated word bug when text overflows on a second page (for bug #11) (50.68 KB, application/vnd.oasis.opendocument.text)
2025-11-20 11:39 UTC, yarma22 		Details
Lorem Ipsum example to illustrate the split "long" line without spaces bug when text overflows on a second page (for bug #11) (51.37 KB, application/vnd.oasis.opendocument.text)
2025-11-20 11:40 UTC, yarma22 		Details
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description yarma22 2025-11-16 12:42:43 UTC 
Description:
Hyphenated word: a word split in two with a hyphen

When a line ends with a hyphenated word (i.e. the first part of the word is at the end of the line and the next line begins with the second part of the word), pressing the `End` key followed by the `Home` key will result in moving the cursor to the beginning of the next line, instead of the beginning of the current line.

Steps to Reproduce:
As a convenience, I provided a document with a line that ends with a hyphenated word ("master-builder"). I'm referring to this document in the following steps.

1. Open the example document
2. Find the line "explorer of the truth, the master-"
3. Place the cursor on that line
4. Press the `End` key to move the cursor at the end of the line
5. Press the `Home` key

Actual Results:
The cursor is now at the beginning of the next line (i.e. "builder of human happiness. No one")

Expected Results:
The cursor should be at the beginning of the current line (i.e. "explorer of the truth, the master-"), like it's normally the case when pressing the `end` and `home` keys consecutively


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Notice how pressing `End` will result in the cursor being placed _after_ the hyphen. To the contrary, when clicking with the mouse at the end of the line, the cursor automatically gets placed at the beginning of the next line.

I'm not sure why this "click" behavior was implemented, but it seems to be the root cause of the issue and is actually seems pretty buggy. For instance, I found the other following issues which all seem to be related.

Bug #2
------
1. Select the 2 lines containing the hyphenated word (i.e. "explorer of the truth, the master-" and "builder of human happiness. No one")
2. Now, click at the end of the line

Notice how this time the cursor is placed after the hyphen, instead of on the next line, contrary to the mouse click behavior.

Bug #3
------

1. Put the cursor at the beginning of the line starting with the second part of the hyphenated word (i.e. before "builder" on the line "builder of human happiness. No one")
2. Select the whole line by pressing `Shift + End`
3. Press `Up`

Notice the cursor remains on the same line. Normally, the cursor goes on the previous line, above the last character of the line that was selected.

And it keeps getting worse:
4. Press `Up` a bunch more times and notice _the cursor still doesn't move_
5. Press `Down` a couple of times and notice the cursor moving to the next lines (okay, but we're not out of trouble yet)
6. Press `Up` a couple of times until coming back to the line that starts with the second part of the hyphenated word
7. Then press `Up` again

Notice the cursor won't go up, no matter how many times you press `Up`.

At this point, the only ways to get unstuck are:
- Pressing `Right` then `Up`
- clicking with the mouse
- switching to another window (i.e. `Alt + Tab`) and then back to Writer

Bug #4
------

This one is pretty similar to the previous one, but it starts differently.

1. Put the cursor at the beginning of any line that's after the line that starts with the second part of the hyphenated word (for instance, "that are extremely painful. Nor")
2. Select the whole line by pressing `Shift + End`
3. Now press `Up` a bunch of times
4. Notice how the cursor is always where we expect it to be
5. Press `Up` until reaching the line that starts with the second part of the hyphenated word

Notice how, this time, the cursor is placed at the beginning of the line (i.e. before "builder"). From then on, when pressing `Up`, the cursor won't move and we're basically in the same situation as bug #3.

Note
----

Though these issues might appear minor, I selected the `Normal` severity. The reason is, I'm actually quite affected because I have a macro that relies heavily on the following dispatch commands (c.f. https://wiki.documentfoundation.org/Development/DispatchCommands#Writer):
- `GoToStartOfLine`
- `GoToEndOfLine`
- `EndOfLineSel`

The macro works perfectly fine except for lines ending with a hyphenated word due to the erratic behaviors mentioned above.

The current workarounds I'm trying to implement are extremely hacky. And considering how erratic these behaviors are, I'm worried I might not be able to handle all the edge-cases and make my code bullet-proof.

As far as I'm concerned, I'd say this behavior when clicking at the end of the line with the hyphenated word (i.e. to move the cursor at the beginning of the next line) should simply be removed. Who knows, this might make all these problems disappear? But that's just my two cents 😇
Comment 1 yarma22 2025-11-16 12:44:32 UTC 
Created attachment 204023 [details]
Lorem Ipsum example to illustrate the bug (for bugs #1, #2, #3, #4 and #5)
Comment 2 yarma22 2025-11-16 13:39:31 UTC 
While working on my macro workarounds, I found yet another related bug similar to the main one:

1. Open the example document
2. Find the line "explorer of the truth, the master-"
3. Place the cursor on that line
4. Press the `End` key to move the cursor at the end of the line
5. Press the `End` key once again

Actual Results:
The cursor is now at the end of the next line (i.e. "builder of human happiness. No one")

Expected Results:
The cursor should be at the end of the current line (i.e. "explorer of the truth, the master-"), like it's normally the case when pressing the `end` key twice in a row
Comment 3 Regina Henschel 2025-11-17 12:44:51 UTC 
I can reproduce the problem in 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: de-DE (de_DE); UI: en-US
Calc: threaded
Comment 4 yarma22 2025-11-20 09:31:55 UTC 
Thanks Regina for confirming the bug(s)!

While reading through the description of the bug, I noticed this step under the `Bug #2` section is not very clear

> 2. Now, click at the end of the line

What I meant is:
2. Now, click at the end of the first of these 2 lines (i.e. "explorer of the truth, the master-")

Also, for clarity, I probably should've named the bug I reported in `Comment 2` so it's easier to refer to each bug in the future. Especially since I have more to come! Let's call it `Bug #5`. As for the main bug described in this bug report, though it's implied, let's call it `Bug #1`.

I found another series of bugs today, similar to these hyphen-related bugs. Only this time, it's with a URL whose members are automatically split over several lines after the `/` (a.k.a. slash).

Interestingly, though these slash-related bugs are quite similar to the hyphen-related bugs, their behavior is sometimes slightly different.

As a convenience, I attached a document with a URL that's split over 2 lines ("https://bugs.documentfoundation.org/" and "show_bug.cgi?id=169477"—yes, that's the very URL of this bug!). I'm referring to this document in the following steps.

Interestingly, that series of bugs happens only with URLs. Indeed, as shown at the bottom of this same document (the paragraph "Note: this bug only happens if the/slash separates members of a URL, unlike in this very sentence."), notice that "the/slash" is not split over 2 lines, even though there's technically enough space to fit "the/" on the first line.

Bug #6
------
Note: It's the same as `Bug #1`, but with a URL.

1. Open the URL bug example document
2. Find the line "https://bugs.documentfoundation.org/"
3. Place the cursor on that line
4. Press the `End` key to move the cursor at the end of the line
5. Press the `Home` key

Actual Results:
The cursor is now at the beginning of the next line (i.e. "show_bug.cgi?id=169477")

Expected Results:
The cursor should be at the beginning of the current line (i.e. "https://bugs.documentfoundation.org/"), like it's normally the case when pressing the `End` and `Home` keys consecutively

Additional Info:
Notice how pressing `End` will result in the cursor being placed _after_ the slash. To the contrary, when clicking with the mouse at the end of the line, the cursor automatically gets placed at the beginning of the next line.

Bug #7
------
Note: It's the same as `Bug #2`, but with a URL.

1. Select the 2 lines containing the URL (i.e. "https://bugs.documentfoundation.org/" and "show_bug.cgi?id=169477")
2. Now, click at the end of the first of these 2 lines (i.e. "https://bugs.documentfoundation.org/")

Notice how this time the cursor is placed after the slash, instead of on the next line, contrary to the mouse click behavior.

Bug #8
------
Note: This one is a bit similar to `Bug #3`. However, following the `Bug #3` procedure on a URL actually doesn't cause a bug. The procedure for this bug is slightly different.

1. Select the 2 lines containing the URL (i.e. "https://bugs.documentfoundation.org/" and "show_bug.cgi?id=169477")
2. Now, click at the end of the first of these 2 lines (i.e. "https://bugs.documentfoundation.org/")
3. Press `Up` and notice the cursor moves on the line above the URL (i.e. "that are extremely painful."), where we expect it to be
4. Press `Down` and notice the cursor moves to the beginning of the second line of the URL (i.e. "show_bug.cgi?id=169477")
  - Note: though the cursor went down 2 lines, it ends up at the same place as when clicking at the end of the first line of the URL, so let's consider this is an expected behavior
5. Then press `Up` again

Notice the cursor remains on the same line. Normally, the cursor goes on the previous line, above the last character of the line that was selected.

And it keeps getting worse:
6. Press `Up` a bunch more times and notice _the cursor still doesn't move_
7. Press `Down` a couple of times and notice the cursor moving to the next lines (okay, but we're not out of trouble yet)
8. Press `Up` a couple of times until coming back to the line that starts with the second part of the URL
9. Then press `Up` again

Notice the cursor won't go up, no matter how many times you press `Up`.

At this point, the only ways to get unstuck are the same as for `Bug #3`:
- Pressing `Right` then `Up`
- clicking with the mouse
- switching to another window (i.e. `Alt + Tab`) and then back to Writer

Note: There's a variant of this bug for steps #3 and #4, but since all the other steps are the same, they can probably be packaged together. The modified steps #3 and #4 go as follows:

3. Press `Down` and notice the cursor moves to the end of the second line of the URL (i.e. "show_bug.cgi?id=169477"), where we expect it to be
4. Press `Up` and notice the cursor moves to the beginning of the second line of the URL (i.e. "show_bug.cgi?id=169477"), instead of moving on the first line of the URL

From here, the behavior is the same.

Bug #8
------
Note: It's the same as `Bug #5`, but with a URL.

1. Open the URL bug example document
2. Find the line "https://bugs.documentfoundation.org/"
3. Place the cursor on that line
4. Press the `End` key to move the cursor at the end of the line
5. Press the `End` key once again

Actual Results:
The cursor is now at the end of the next line (i.e. "show_bug.cgi?id=169477")

Expected Results:
The cursor should be at the end of the current line (i.e. ""https://bugs.documentfoundation.org/""), like it's normally the case when pressing the `end` key twice in a row

Note
----
As of right now, I didn't manage to find a use-case to reproduce `Bug #4` with a URL.

Note
----
I found another strange behavior which I also think is a bug. Notice how the URL at the end of the document is split on 3 lines instead of 2 lines for the URL used to describe the bugs above, even though these 2 URLs are the same. The only difference is that the first one is inline with the text that precedes, while the second one is on its own paragraph.
However, since this seems to be unrelated to the main bug reported here, I created a separate bug report:
https://bugs.documentfoundation.org/show_bug.cgi?id=169565
Comment 5 yarma22 2025-11-20 09:33:44 UTC 
Created attachment 204128 [details]
Lorem Ipsum example to illustrate the split URL bugs (for bugs #6, #7, #8 and #9)
Comment 6 yarma22 2025-11-20 09:52:22 UTC 
Erratum
-------
The last bug in `Comment 4` should actually be named `Bug #9` instead of `Bug #8`, since `Bug #8` was already taken 🙈
Comment 7 yarma22 2025-11-20 10:12:52 UTC 
Note
====
I realized that the split URLs bugs mentioned above (i.e. `Bug #6`, `Bug #7`, `Bug #8` and `Bug #9`) actually happen with any "long" line without a space that's automatically split over multiple lines.

I attached an example file to illustrate this behavior. The line without spaces is "ThisIsAVeryLongLine,ItDoesn'tContainAnySpace" and it's split in 2 lines:
1. "ThisIsAVeryLongLine,ItDoesn'tContain"
2. "AnySpace"

All the split URLs bugs can be reproduced, except this time replace any reference to the first and second line of the URL by the 2 above lines.
Comment 8 yarma22 2025-11-20 10:14:04 UTC 
Created attachment 204130 [details]
Lorem Ipsum example to illustrate the split "long" line without spaces bugs (for bugs #6, #7, #8 and #9)
Comment 9 yarma22 2025-11-20 11:29:11 UTC 
I found a couple more related bugs.

Bug #10
------
This one is tricky. I could only reproduce it with a split URL (i.e. not with a line ending with a hyphenated word and not with a "long" line without spaces). Also, it requires the split URL to be on its own paragraph.

I created 2 example documents with a paragraph after the split URL:
1. One where the last line of that paragraph is _longer_ than the last line of the URL
2. Another one where the last line of that paragraph is _shorter_ than the last line of the URL

The bug happens only with the first document, even though both documents are entirely similar in every other aspect.

Steps to Reproduce:
1. Open the example document "Lorem Ipsum example to illustrate the split URL bug with enough text afterwards"
2. Select all the text (e.g. `Ctrl+A`)
3. Press `Up` a bunch of times until reaching the line "show_bug.cgi?id=169477"
4. Press `Up` one more time

Notice the cursor moves to the beginning of the line instead of on the line above (i.e. "bugs.documentfoundation.org/").

From now on, we're in the same situation as `Bug #3`, `Bug #4` and `Bug #8` (i.e. the cursor won't go up).

As mentioned, if the length of the last line of the last paragraph is less than the length of the last line of the URL, this bug won't happen. At least that's what my different tests have uncovered. Try the above procedure with the example document "Lorem Ipsum example to illustrate the split URL case without enough text afterwards" and notice we're not stuck on the "bugs.documentfoundation.org/" line.

Note
----
As mentioned, it can't be reproduced if instead of a URL, it's a line ending with a hyphenated word or a "long" line without spaces. I can't explain this difference in behavior.

Bug #11
-------
This bug happens when the text overflows on a second page, both when there's:
- a line ending with a hyphenated word
- or a "long" line without spaces (including URLs)

I provided one example for each:
1. Lorem Ipsum example to illustrate the split URL bug when text overflows on a second page
2. Lorem Ipsum example to illustrate the split "long" line without spaces bug when text overflows on a second page

The same procedure applies for both cases.

Steps to Reproduce:
1. Open the example document
2. Select all the text (e.g. `Ctrl+A`)
3. Press `Up` until reaching the top of the second page
4. Press `Up` one more time

Notice the cursor remains at the top of the second page. Normally, the cursor goes on the first page.

And it keeps getting worse:
4. Press `Up` a bunch more times and notice _the cursor still doesn't move_
5. Press `Down` and notice the cursor moving to the next line (okay, but we're not out of trouble yet)
6. Press `Up` until coming back to the top of the second page
7. Then press `Up` again

Notice the cursor won't go to the first page, no matter how many times you press `Up`.

At this point, the only ways to get unstuck are:
- Move the cursor before the first character of the first line of the second page and then press `Left` 
- Clicking with the mouse _on the first page_
  - Note that for `Bug #3`, `Bug #4`, `Bug #8`, and `Bug #10`, clicking anywhere with the mouse would unstuck the cursor

Note that, contrary to `Bug #3`, `Bug #4`, `Bug #8`, and `Bug #10`, switching to another window (i.e. `Alt + Tab`) and then back to Writer doesn't seem to unstuck the cursor either.
Comment 10 yarma22 2025-11-20 11:29:51 UTC 
Created attachment 204136 [details]
Lorem Ipsum example to illustrate the split URL bug with enough text afterwards (for bug #10)
Comment 11 yarma22 2025-11-20 11:30:59 UTC 
Created attachment 204137 [details]
N/A
Comment 12 yarma22 2025-11-20 11:33:20 UTC 
Comment on attachment 204137 [details]
N/A

ERRATUM
-------
Uploaded the wrong document
Comment 13 yarma22 2025-11-20 11:34:31 UTC 
Created attachment 204138 [details]
Lorem Ipsum example to illustrate the split URL case without enough text afterwards (for bug #10)
Comment 14 yarma22 2025-11-20 11:35:45 UTC 
Created attachment 204139 [details]
N/A
Comment 15 yarma22 2025-11-20 11:38:07 UTC 
Comment on attachment 204139 [details]
N/A

ERRATUM
-------
Uploaded the wrong document
Comment 16 yarma22 2025-11-20 11:39:27 UTC 
Created attachment 204140 [details]
Lorem Ipsum example to illustrate the split hypehnated word bug when text overflows on a second page (for bug #11)
Comment 17 yarma22 2025-11-20 11:40:26 UTC 
Created attachment 204141 [details]
Lorem Ipsum example to illustrate the split "long" line without spaces bug when text overflows on a second page (for bug #11)
Comment 18 yarma22 2025-11-20 11:43:11 UTC 
ERRATUM
-------

In `Bug #11`, instead of:

> 1. Lorem Ipsum example to illustrate the split URL bug when text overflows on a second page

I actually meant:
1. Lorem Ipsum example to illustrate the split hypehnated word bug when text overflows on a second page
Comment 19 yarma22 2025-11-20 11:51:19 UTC 
Note
----
I'm not sure about the LibreOffice policy when it comes to bug reports like this one, i.e. if each bug should be in a separate bug report. I personally see all these 11 bugs as being different use-cases of what seems to be one main unique bug. I hope it's ok if we keep them all under the same roof 😇
Comment 20 BogdanB 2026-02-07 05:08:11 UTC 
(In reply to yarma22 from comment #19)
> Note
> ----
> I'm not sure about the LibreOffice policy when it comes to bug reports like
> this one, i.e. if each bug should be in a separate bug report. I personally
> see all these 11 bugs as being different use-cases of what seems to be one
> main unique bug. I hope it's ok if we keep them all under the same roof 😇

Developes are working based on bug reports. So if here will be 11 problems, no one will start work on this. If the report is short and clear over 1 aspect, the developer can focus at ne problem at a time.
Comment 21 yarma22 2026-02-08 22:20:45 UTC 
(In reply to BogdanB from comment #20)
> Developes are working based on bug reports. So if here will be 11 problems,
> no one will start work on this. If the report is short and clear over 1
> aspect, the developer can focus at ne problem at a time.

Thanks for the feedback. I'm happy to create 11 individual bug reports then :)

I guess I can use the "See also" field to link all these bugs together.