RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1388764 - [fix available] When editting text in LibreOffice Calc the new and old texts are shown on top of each other
Summary: [fix available] When editting text in LibreOffice Calc the new and old texts ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreoffice
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Caolan McNamara
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-26 07:24 UTC by Alexander Todorov
Modified: 2018-10-30 07:57 UTC (History)
4 users (show)

Fixed In Version: libreoffice-5.3.6.1-13.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 07:57:26 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
ODS file partially reproducing the bug (14.48 KB, application/octet-stream)
2016-10-27 10:22 UTC, Alexander Todorov 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Document Foundation 100925 0 None None None 2016-12-07 10:00:49 UTC
Red Hat Product Errata RHSA-2018:3054 0 None None None 2018-10-30 07:57:57 UTC

Description Alexander Todorov 2016-10-26 07:24:24 UTC 
Description of problem:

When editing text in a cell what the user types is shown above what is already there. And if you try to edit the line you are writing the characters are rendered on top of each other and the whole text becomes unreadable.


Version-Release number of selected component (if applicable):
libreoffice-calc-5.0.6.2-3.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Just edit text in a cell
2.
3.

Actual results:
See this screen cast
https://www.youtube.com/watch?v=z4bjBtnbNMU

Also this is a regression from previous versions.
Comment 2 David Tardon 2016-10-26 08:41:29 UTC 
Cannot reproduce with 5.0.6.2-2.el7 anyway. Will try with 5.0.6.2-3.el7 in a moment.
Comment 3 Caolan McNamara 2016-10-26 11:24:06 UTC 
caolanm->dtardon: Is https://cgit.freedesktop.org/libreoffice/core/commit/?id=8c4dbcef8f92c9bd1c2208e7de7971f184f8a3ff relevant, or was that something entirely different ?
Comment 4 David Tardon 2016-10-26 12:27:20 UTC 
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.
Comment 5 David Tardon 2016-10-26 12:29:47 UTC 
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?
Comment 6 Alexander Todorov 2016-10-26 13:02:58 UTC 
(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.
Comment 7 Alexander Todorov 2016-10-26 13:04:48 UTC 
(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.
Comment 8 David Tardon 2016-10-26 13:11:28 UTC 
Okay, so the way to reproduce this clearly is not just "Just edit text in a cell" .-) Could you attach the document here?
Comment 9 Alexander Todorov 2016-10-27 10:22:31 UTC 
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.
Comment 10 David Tardon 2016-10-27 14:28:32 UTC 
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?
Comment 11 Alexander Todorov 2016-11-02 08:44:42 UTC 
(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 ?
Comment 12 Caolan McNamara 2017-05-26 11:02:09 UTC 
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 ?
Comment 13 Alexander Todorov 2017-06-01 13:20:50 UTC 
I have updated to libreoffice-impress-5.0.6.2-11.el7.x86_64 but the issue still persists.
Comment 16 Caolan McNamara 2018-04-16 20:02:28 UTC 
upstream qa can reproduce this and can can reproduce that my speculative fix seems to solve the problem
Comment 18 Martin Krajnak 2018-07-12 15:07:58 UTC 
Not reproducible with libreoffice-calc-5.3.6.1-16
Comment 20 errata-xmlrpc 2018-10-30 07:57:26 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.