yes its true that if you type 'abcd' and then split it as 'a bcd' or 'ab cd', the line appears under the second half, but if you split it as 'abc d', the line appears under the first half. Just to further test it, i typed 'adslfjalskdjsjdfkalsdjkfsjdlkdfj' and then split it, and both parts had underline under them.

Tested in Linux Mint with 4.2.4 abd 4.3 beta 1.

@jay Your comments seem to partly confirm the error, so did not understand why you changed to resolved.

I have now also tested under Mint Qiana with 4.2.3.3 and the issue is exactly the same as in Windows.

With your example of adslfjalskdjsjdfkalsdjkfsjdlkdfj splitting anywhere always leaves the second half without an ubderline until some other edit is done to the file. What's more, if you continually split your example at different points, the second part of the new words are not underlined initially, corrected for previous splits as each new split is made.

(In reply to comment #2)
> @jay Your comments seem to partly confirm the error, so did not understand
> why you changed to resolved.
> 
> I have now also tested under Mint Qiana with 4.2.3.3 and the issue is
> exactly the same as in Windows.
> 
> With your example of adslfjalskdjsjdfkalsdjkfsjdlkdfj splitting anywhere
> always leaves the second half without an ubderline until some other edit is
> done to the file. What's more, if you continually split your example at
> different points, the second part of the new words are not underlined
> initially, corrected for previous splits as each new split is made.

No i wasnt confirming the error as 'a' in 'a bcd' and 'ab' in 'ab cd' are words. Well i just retested it again in Linux Mint and i see my instructions were slightly off in that you have to type in 'adslfjalskdjsjdfkalsdjkfsjdlkdfj ' and then split it and that works correctly.

Testing it in Windows XP SP3 with 4.3 beta and the same instructions wont work unless you add another letter after the last space. So if anything, this should be limited to a windows issue. If you disagree that it still happens in Linux, please send in a screencast, if you know how to.

@jay I can't get your example to work 'correctly' on Win or Mint, ie putting the insertion point anywhere in the middle of your example and typing a space without subsequently moving the insertion point leaves the second part without the miss-spleeing underline. 

Agree that Win is worse than Mint in that in Win you can move the insertion point anywhere without the misspelling underline for the second half of a split word reappearing. Inserting any character into the document corrects the previous missing underline. In Mint, you can move the insertion point anywhere within a miss-spelt word without the underline appearing, but moving it outside the word corrects the missing underline. Moving it into the miss-spelt and non-underlined word does not correct the missing underline.

Here's another example (using Mint Qiana on a 32 bit PC):

             type a new line with a following space
queue
             -> no underline - correct

             delete first u
qeue 
             -> no underline until click outside word

             click outside word to get underline, then replace missing u
queue
             -> underline immediately dissapears

This is inconsistent behaviour.

Thus, for me, this is an almost identical bug in both Linux and Win.

(In reply to comment #4)
> @jay I can't get your example to work 'correctly' on Win or Mint, ie putting
> the insertion point anywhere in the middle of your example and typing a
> space without subsequently moving the insertion point leaves the second part
> without the miss-spleeing underline. 

'correctly' meant that the underline appear in both words.

> Here's another example (using Mint Qiana on a 32 bit PC):
> 
>              type a new line with a following space
> queue
>              -> no underline - correct
> 
>              delete first u
> qeue 
>              -> no underline until click outside word
> 
>              click outside word to get underline, then replace missing u
> queue
>              -> underline immediately dissapears
> 
> This is inconsistent behaviour.
> 
> Thus, for me, this is an almost identical bug in both Linux and Win.

Yes i can see the inconsistency in behaviour in this example, but this was different from your first instruction to split a word.

@jay Yes, you are right that the second example is different, but it's very likely that the underlying cause is the same in both cases, ie spell check is not being triggered properly. Thus, the two examples are reasonably kept together. I edited the title therefore.

To extend the second example:

                  type queue followed by a space
queue 
                  -> no underline - correct

                  add an extra u
quueue
                  -> no underline until click outside word (linux) or make a change to the document outside the word (Win) - inconsistent since when adding a letter to make a word correct the underline dissapears

I wouldn't be surprised if this one turned out to be a duplicate, but I couldn't find the right bug report. If you can't either, do you think it's time to change the status to 'new'?

Also, I wonder a bit about quoting complete responses, which seem to make reports longer than necessary. Would you consider quoting just a small part, or using something like 'responding to comment n'?

Well we both can confirm your latest example but i couldnt confirm your previous one, but you are correct that the spell checkers isnt trigger correctly. I have set it as new now. It would be great if you could do a short screencast of the issue, or else i can do it. :)

(In reply to comment #7)
> It would be great if you could do a
> short screencast of the issue, or else i can do it. :)
Thanks Jay. If you think it's necessary then by all means do a screencast...

seems i was able to reproduce your initial bug as i show it in the below screencast < http://youtu.be/l4KWsgOC6Gw >

still reproducible under Win8.1 x64 using LibO 5.0.3.
I see the same behaviour in OOo 3.3.0
so issue is inherited from OOo

No change in 5.3.0.1 on Win 64, issue is exactly as set out in the initial descriptions.

Happens in 5.4.1, also happens with RTL text (Hebrew).

No change, bug remains as described - tested with 6.1.2.1 on Linux Mint.

Bug is unchanged in 6.3.2.2 (Win 64)

PS: Suspect bug is inherited from Ooo but not able to test that.

Dear mike.hall,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug