Bug Hunting Session
Bug 116725 - !!br0ken!! mysteriously appears in Spellcheck after some steps
Summary: !!br0ken!! mysteriously appears in Spellcheck after some steps
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.1.1 release
Hardware: All Windows (All)
: medium minor
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.1.0 target:6.0.5
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-31 18:33 UTC by Dylan Risso
Modified: 2018-05-29 11:29 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dylan Risso 2018-03-31 18:33:23 UTC
Description:
When I typed, on a new sentence, 'jarn jarn' or 'harn harn' or larn larn', then went on the Spellcheck, and corrected it, !!br0ken!! appeared.

Steps to Reproduce:
1. Type 'jarn jarn' on a new sentence.
2. Go on Spellcheck, and in the top box, not the suggestions, replace it for 'jam jarn'.
3. For the second 'jarn', change it, in the top box, to 'jam jam'
4. Click the greyed-out box 'Always Correct'.
5. Click 'Correct'

Actual Results:  
'jam j!!br0ken!!'

Expected Results:
'jam j!!br0ken!!'


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
'jam jam'


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Comment 1 Dylan Risso 2018-03-31 18:36:55 UTC
I meant:

Additional Info:
It should have been 'jam jam'
Comment 2 Mike Kaganski 2018-03-31 19:00:46 UTC
What is the language for the sentence and its parts at the time of spell checking?
Comment 3 Buovjaga 2018-04-03 17:43:47 UTC
(In reply to Mike Kaganski from comment #2)
> What is the language for the sentence and its parts at the time of spell
> checking?

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 4 Telesto 2018-04-04 18:26:21 UTC
Something similar or the same
1. Language English USA (or something else)
2. Type: Hollo
3. F7
4. Manual correction to say: "Hollo3"
5. Press correct
6. Press Undo (3 times) -> until Hollo is back
7. Press correct -> !!br0ken!!
Comment 5 Buovjaga 2018-04-08 17:22:05 UTC
(In reply to Telesto from comment #4)
> Something similar or the same
> 1. Language English USA (or something else)
> 2. Type: Hollo
> 3. F7
> 4. Manual correction to say: "Hollo3"
> 5. Press correct
> 6. Press Undo (3 times) -> until Hollo is back
> 7. Press correct -> !!br0ken!!

I only need 1 undo. Step 7 results in nothing happening. Hollo is not changed to Hollo3, but not !!br0ken!! either.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: d4c0e7ef2b7f7e3cb36996bad72ac255b630beb4
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on April 8th 2018
Comment 6 Telesto 2018-04-11 20:43:11 UTC
Repro with [no recent daily available]
Version: 6.1.0.0.alpha0+
Build ID: 818619b0f2f7813decb26d0b14362dec76a8ff37
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2018-04-08_13:29:47
Locale: nl-NL (nl_NL); Calc: CL

1. Language English USA (or something else)
2. Type: Hollo
3. F7
4. Type into "Not in dictionary field" -> "Hollo3"
5. Press correct
6. Press Undo (3 times) -> until Hollo is back
7. Press correct -> !!br0ken!!

I could reproduce this on Linux LXDE too
Comment 7 Mike Kaganski 2018-04-16 12:54:03 UTC
Wanted to debug this, and it feels like there's some race condition here.

First, I was able to repro the steps from comment 0 (here I reproduce them with clarification required between original steps 2 and 3):

1. Type 'jarn jarn' on a new sentence.
2. Go on Spellcheck, and in the top box, not the suggestions, replace the highlighted word 'jarn' to 'jam', so the end result is 'jam jarn'. (The first jarn might had beed sentence-cased to Jarn; that doesn't matter, and I reproduced with Jarn->Jam as well).
2.1. Click 'Correct'.
3. For the second 'jarn', change it, in the top box, to 'jam', so that end result is 'jam jam'.
4. I didn't need the step "Click the greyed-out box 'Always Correct'".
5. Click 'Correct'.

I had the assertion in void SAL_CALL IMPL_RTL_STRINGNAME( newFromSubString ) (sal/rtl/strtmpl.cxx) for condition "beginIndex + count > pFrom->length", called from TextEngine::GetText( const TextSelection& rSel, LineEnd aSeparator ), called from SentenceEditWindow_Impl::MarkNextError, where the m_nErrorEnd for some reason stayed 8, when it needed to be 7 already (and that should have been corrected inside if(pNextError) check).

But after a couple of "successful" (=failing assertions) tests, I now cannot repro it again. So, my suspicion is that the previous change might not yet reflect itself in the nodes contents, so that the old length was used for the end pos...

A simple "fix" (like the one I mentioned in bug 104032) would be to simply change TextEngine::GetText to use something like

>        if ( nNode == nEndPara ) // may also be == nStart!
>            nEndPos = std::min(nEndPos, aSel.GetEnd().GetIndex());

... because the nEndPos is already equal to length of the string; but I feel like it's just a workaround trying to fix symptoms rather than the problem.

Maybe Michael Stahl could have some insight here?
Comment 8 Mike Kaganski 2018-04-16 13:00:00 UTC
Huh. The problem is reproducible if at step 3 of my description in comment 7 one *selects "rn" from right to left (!)*. Selecting from left to right doesn't give the problem. So - no race here; need to debug further.
Comment 9 Mike Kaganski 2018-04-16 13:27:12 UTC
https://gerrit.libreoffice.org/52979
Comment 10 Commit Notification 2018-04-17 11:36:02 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f7de9473b2fddd84d03fb521709d805486292800

tdf#116725: justify selection to handle right-to-left selections

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2018-04-26 14:17:00 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea33797be1b683ca5743a00bd3347d0806bd62a8&h=libreoffice-6-0

tdf#116725: justify selection to handle right-to-left selections

It will be available in 6.0.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.