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
I meant: Additional Info: It should have been 'jam jam'
What is the language for the sentence and its parts at the time of spell checking?
(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.
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!!
(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
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
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?
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.
https://gerrit.libreoffice.org/52979
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.
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.