This is a Linux GTK only problem. Starts in 5.0 - present 5.2dev. Tested with Precise 12.04. To reproduce in Writer -insert frame -right click on frame - Description. You can see what you type in the Title, but not in the Description (until pressing Enter). Scrolling doesn't fix it.
This bug occurred when I had a "special" language selected in ibus - using kmfl with one of our own keyboards. The bug didn't appear when I used English, Arabic, or French. The bug doesn't appear with SAL_USE_VCLPLUGIN=gen. Bibisected and re-confirmed on 14.04. Author: Matthew Francis <mjay.francis@gmail.com> Date: Wed May 27 22:45:13 2015 +0800 source-hash-29b1e6718f6ebdb45d2a8c6a89a86bc0a6bbb3ae commit 29b1e6718f6ebdb45d2a8c6a89a86bc0a6bbb3ae Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> AuthorDate: Wed May 6 15:49:16 2015 +0900 Commit: Jan Holesovsky <kendy@collabora.com> CommitDate: Thu May 7 09:57:50 2015 +0200 refactor "TextEdit" & co. to use RenderContext Change-Id: Ib26ecb9640d23714acec73304f26e2fd6af90ed4 :040000 040000 56b0e99aa9d990af71190d98a7a4ca6a8167ae9e 7c572b7745a9d53f693cc4c4985a30faee500db1 M opt git bisect log # bad: [e7374cd735af2344dae55be40946d96633d2f6ee] source-hash-8a91528a3e03fe6e2923c33327b687ecf57adb0b # good: [6f4c9f43f113643e0a0051967a17a43befb4aa74] source-hash-cd84fffd506e7d681d6542f979045691c49bbd8c git bisect start 'e7374cd735af2344dae55be40946d96633d2f6ee' '6f4c9f43f113643e0a0051967a17a43befb4aa74' # good: [808d74dd04bd9059a77a581d6acc3dd6d2c50f95] source-hash-498e25e14bfeac30c00e5f6204fa8103270c96a5 git bisect good 808d74dd04bd9059a77a581d6acc3dd6d2c50f95 # skip: [056b61ed290ebe29772fb434686f4fffad3fd8ec] source-hash-1275a450c10d581e453f0d822d9d77b5bdf07d68 git bisect skip 056b61ed290ebe29772fb434686f4fffad3fd8ec # bad: [227fc1576a6c2fbcabcecc0a9b969bffccaa2481] source-hash-a563bd6a3e2768a5248abb3ad889d0ed739df1ba git bisect bad 227fc1576a6c2fbcabcecc0a9b969bffccaa2481 # bad: [35e69743ad74f1bc61be5ddf09514a13a028e873] source-hash-29b1e6718f6ebdb45d2a8c6a89a86bc0a6bbb3ae git bisect bad 35e69743ad74f1bc61be5ddf09514a13a028e873 # good: [2388eb86def307a9a8a6d363dd6597c87fd14963] source-hash-d8a53d46278ee6415d47aec8db90577b7bd52764 git bisect good 2388eb86def307a9a8a6d363dd6597c87fd14963 # good: [4635462f05404fef3767db1a7381004440ac8c99] source-hash-a6b9d9a19fb8c5c9f166682f52941aee25b89c94 git bisect good 4635462f05404fef3767db1a7381004440ac8c99 # good: [4a3ad48ec412e5c778a4b5341981b1b3990149a4] source-hash-c299413c6d51280804e1996330a960d02050507d git bisect good 4a3ad48ec412e5c778a4b5341981b1b3990149a4 # first bad commit: [35e69743ad74f1bc61be5ddf09514a13a028e873] source-hash-29b1e6718f6ebdb45d2a8c6a89a86bc0a6bbb3ae
Other places where this bug is noticed -spelling and grammar: typing in the textbox -any type of frame's Description. Description on any control -control properties: Label on button, default text on textbox etc.
A bit clearer description of the problem I am seeing: using spell checker after typing "recieve", right-clicking on the misspelled word and choosing spelling and grammar. In the spelling dialog, I see the paragraph with the misspelled word in red. I click inside the textbox and start typing. With my first keypress, all of the words in the current paragraph become invisible. I see the cursor moving as I type, but no characters are seen. Typing enough to wrap (or push) characters to the next line doesn't help. The entire paragraph is hidden until a carriage return - then the entire (old) p̣aragraph is displayed and the new paragraph I am on is invisible. Moving the cursor from one paragraph to another is not enough to hide or show a paragraph - a new character must be entered. For paragraphs 0 to n, if I am typing in paragraph x, then 0 - x-1 will be displayed, and x-n will be invisible. If I move the cursor to paragraph 0 and type one character, then all paragraphs will become invisible. If I move to paragraph n-1 and type one character, then everything will become visible except for the last two paragraphs. Trying to highlight some words doesn't help. So it doesn't seem to be a color issue. Somehow the paragraphs are just not being painted.
commenting out one line removes the problem (not a proper fix, but at least gets to the right point in the code). vcl/source/edit/textview.cxx ::Command() if GetCommand == EndExtTextInput //pPortion->MarkSelectionInvalid Or more specifically, commenting out //mbInvalid = true in textdata.cxx MarkSelectionInvalid()
After MarkSelectionInvalid, nothing was attempting to validate the text portion again because it was still marked as bFormatted=true. So a possible fix is: +mpImpl->mpTextEngine->TextModified(); mpImpl->mpTextEngine->FormatAndUpdate( this ); +mpImpl->mpTextEngine->mbFormatted; would be a more targeted fix, but mbModified doesn't seem to be used anyway and likely wouldn't cause any harmful side-effects except perhaps using a bit of extra processing power to re-verify layout. It seems better to use a function than to set a variable directly, even though mbFormatted is a public variable. This fixes the problem in all the places mentioned in Comment 3.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5a217ada5e28e17f052ebec8e53dce05c2aa9cae tdf#96687 - force validation after External Input It will be available in 5.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6211a9ec196b16d6c2773fc8dbdd8c39002b28b7&h=libreoffice-5-1 tdf#96687 - force validation after External Input It will be available in 5.1.0.2. 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.
version seems to be wrong: (In reply to Justin L from comment #0) > This is a Linux GTK only problem. Starts in 5.0 - present 5.2dev. Tested > with Precise 12.04.
*** Bug 92204 has been marked as a duplicate of this bug. ***
problem was not limited to linux, and not just gtk plugin (see bug#92204), adjusting summary and OS accordingly
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b170aa84afbbb6c984d739aed15846c2269be9ff&h=libreoffice-5-0 tdf#96687 - force validation after External Input It will be available in 5.0.6. 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.