Download it now!
Bug 96687 - Characters are not displayed in GTK textbox until Enter is pressed – IME-input (Japanese,…) is not shown on Properties|Description|Comment.
Summary: Characters are not displayed in GTK textbox until Enter is pressed – IME-inpu...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:5.2.0 target:5.1.0.2 target:5...
Keywords: bibisected, regression
: 92204 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-23 11:20 UTC by Justin L
Modified: 2016-10-25 19:09 UTC (History)
3 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 Justin L 2015-12-23 11:20:30 UTC
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.
Comment 1 Justin L 2015-12-24 11:23:55 UTC
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
Comment 2 Justin L 2015-12-24 11:35:47 UTC
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.
Comment 3 Justin L 2015-12-25 04:33:45 UTC
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.
Comment 4 Justin L 2015-12-26 19:01:35 UTC
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()
Comment 5 Justin L 2015-12-28 11:48:45 UTC
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.
Comment 6 Commit Notification 2016-01-05 14:09:45 UTC
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.
Comment 7 Commit Notification 2016-01-06 09:52:18 UTC
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.
Comment 8 Björn Michaelsen 2016-01-12 12:19:46 UTC
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.
Comment 9 Christian Lohmaier 2016-03-13 15:00:49 UTC
*** Bug 92204 has been marked as a duplicate of this bug. ***
Comment 10 Christian Lohmaier 2016-03-13 15:04:18 UTC
problem was not limited to linux, and not just gtk plugin (see bug#92204), adjusting summary and OS accordingly
Comment 11 Commit Notification 2016-03-14 07:25:03 UTC
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.