Bug 1388764

Cannot reproduce with 5.0.6.2-2.el7 anyway. Will try with 5.0.6.2-3.el7 in a moment.

caolanm->dtardon: Is https://cgit.freedesktop.org/libreoffice/core/commit/?id=8c4dbcef8f92c9bd1c2208e7de7971f184f8a3ff relevant, or was that something entirely different ?

dtardon->caolanm: This apparently happens without any selection, so that commit doesn't seem to be relevant. OTOH, it seems that not all letters are blackened, but only every other. But that's hard to tell, as the screen cast has a really low resolution. It's possible that the blackening is just more visible on some letters.

Cannot reproduce on CentOS 7 with 5.0.6.2-3.el7.

Does this happen in a new spreadsheet too? If yes, could you make a screen cast with the sheet zoomed to 200-300%, so it is actually visible what is happening?

(In reply to David Tardon from comment #4)
> dtardon->caolanm: This apparently happens without any selection, so that
> commit doesn't seem to be relevant. OTOH, it seems that not all letters are
> blackened, but only every other. But that's hard to tell, as the screen cast
> has a really low resolution. It's possible that the blackening is just more
> visible on some letters.

I think the blackening happens only when I go back and edit over what has already been typed. Which is independent of the fact that I see the new line above the old one.

(In reply to David Tardon from comment #5)
> Cannot reproduce on CentOS 7 with 5.0.6.2-3.el7.
> 
> Does this happen in a new spreadsheet too? 

No, I've created a new spreadsheet and everything appears to be fine with it. The one in the screen cast is an old document, which I've been copying to a new file name and editing from time to time.

Okay, so the way to reproduce this clearly is not just "Just edit text in a cell" .-) Could you attach the document here?

Created attachment 1214563 [details]
ODS file partially reproducing the bug

I can't attach the original document because it contains private information but here's the same file copied under a new name (via the file system) and with most of the content deleted. 

Steps to reproduce:

1) Using the keyboard I focus on the cell containing the text
2) then start typing something and press Enter
3) Using arrow up go back to the same cell
4) repeat

Observations: 
when editing both old and new text is visible one under the other. With this particular document I wasn't able to reproduce the part where I start typing new text (both lines appear, this is reproducible) and then I use backspace to edit the new text and whatever I type is rendered on top of what is already there.

I also have the feeling that if there's more text in the lines above the bug is easier to reproduce. 

Please let me know how can I collect more debugging info locally.

Still can't reproduce... A driver problem, possibly? Anyway, could you try again with a new file, writing into a row of more than 2x normal height?

(In reply to David Tardon from comment #10)
> Still can't reproduce... A driver problem, possibly? Anyway, could you try
> again with a new file, writing into a row of more than 2x normal height?

I can't reproduce at all with a new document regardless of the height of the row. Is there anything in the attached document that is different from what a new document looks like ?

Is it possible that this is a duplicate of bug 1421726, can you check if the problem persists with our 7.4 candidate builds >= 5.0.6.2-6 ?

I have updated to libreoffice-impress-5.0.6.2-11.el7.x86_64 but the issue still persists.

upstream qa can reproduce this and can can reproduce that my speculative fix seems to solve the problem

Not reproducible with libreoffice-calc-5.3.6.1-16

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3054