[Libreoffice-bugs] [Bug 116725] !!br0ken!! mysteriously appears in Spellcheck after some steps

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=116725

Mike Kaganski <mikekaganski at hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |michael.stahl at cib.de
     Ever confirmed|0                           |1

--- Comment #7 from Mike Kaganski <mikekaganski at hotmail.com> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180416/f24ae01d/attachment.html>