Bug 100925 - When overwriting a cell, new content is displayed on top of the old content until finishing the edit
Summary: When overwriting a cell, new content is displayed on top of the old content u...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: Other Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.4 target:5.4....
Keywords: bibisected, bisected, regression
: 100483 100802 101151 101311 104474 106065 107640 107808 109336 113678 113796 115102 (view as bug list)
Depends on:
Blocks: Calc-Cells Cell-Edit-Mode
  Show dependency treegraph
 
Reported: 2016-07-15 07:58 UTC by Dietmar
Modified: 2018-05-09 09:18 UTC (History)
22 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (1.38 MB, image/jpeg)
2016-07-25 06:30 UTC, Dietmar
Details
screenshot (47.37 KB, image/jpeg)
2017-01-06 15:35 UTC, Andreas Schleth
Details
simple odt doc (10.67 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-01-06 15:35 UTC, Andreas Schleth
Details
Text overlap when scrolling past the fold (276.04 KB, image/gif)
2017-07-08 06:30 UTC, Dan Dascalescu
Details
debugging patch (1.96 KB, patch)
2018-04-12 14:01 UTC, Caolán McNamara
Details
does this make any difference ? (2.42 KB, patch)
2018-04-12 16:57 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dietmar 2016-07-15 07:58:02 UTC
I created an calc file under LO5.x on windows.
Open it under LO5.2.x on a debian machine results in the following behavior:
if i try to edit cell content, the new content is writen over the existing content. After finishing the edit and leaving the cell, the old content is gone. Seems the repainting of the cell tooks just place after leaving the cell. Even if i press the back button, the former content is not removed, first after leaving the cell.
If i open a new file in the debian environment, the behavior is normal as expected.
Comment 1 Dietmar 2016-07-15 07:58:59 UTC
sorry, the behavior with a new document is wrong too
Comment 2 Buovjaga 2016-07-18 11:42:29 UTC Comment hidden (obsolete)
Comment 3 Dietmar 2016-07-19 14:45:20 UTC
But you are using a windows version. Under Windows on the same machine i did not see this behavior like you
Comment 4 Buovjaga 2016-07-19 15:01:50 UTC
(In reply to Dietmar from comment #3)
> But you are using a windows version. Under Windows on the same machine i did
> not see this behavior like you

Notice I mentioned I also tried on Linux.
Comment 5 Dietmar 2016-07-20 19:46:43 UTC
http://ruderninleipzig.de/index.php?option=com_content&view=article&id=167
shows in a video the behavior
Comment 6 Dietmar 2016-07-20 19:47:29 UTC
Version: 5.1.5.1
Build ID: 1:5.1.5~rc1-1
CPU Threads: 4; OS Version: Linux 4.6; UI Render: default; 
Locale: en-US (C); Calc: group
Comment 7 Buovjaga 2016-07-20 20:22:33 UTC Comment hidden (obsolete)
Comment 8 Dietmar 2016-07-20 21:47:46 UTC
I open a new document and start inserting content in the upper left cell. Then I move to the next cell and so on. I just go back and start writing. I did not enter the editing mode with F2
Comment 9 Dietmar 2016-07-20 21:50:33 UTC
entering just numbers, the behavior is normal. If you start writing text in a cell with numbers, the number is still visible until you enter a second character
Comment 10 Buovjaga 2016-07-21 10:31:40 UTC
This is the normal behavior. I thought you meant editing by double-clicking or F2 was causing this. Closing.
Comment 11 Dietmar 2016-07-22 06:59:48 UTC
But how can be this the normal behavior? Normal for me is, I enter the first new character and all old content disapears! Hmmm....
Comment 12 Buovjaga 2016-07-22 08:09:47 UTC
(In reply to Dietmar from comment #11)
> But how can be this the normal behavior? Normal for me is, I enter the first
> new character and all old content disapears! Hmmm....

Ok, sorry, I understood the problem wrong. I thought the problem was that the old content is overwritten, like it says in the bug summary. I adjusted the summary to be more clear.
Comment 13 Dietmar 2016-07-22 19:44:16 UTC
great, thanks.
The same behavior under OpenSUSE
Version: 5.2.0.1
Build-ID: 20m0(Build:1)
CPU-Threads: 4; BS-Version: Linux 4.6; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE.UTF-8)
I can't say it starts in column D, in column C it apears in row 6.
Comment 14 Dietmar 2016-07-25 06:30:46 UTC
Created attachment 126394 [details]
screenshot
Comment 15 Dietmar 2016-07-25 06:32:56 UTC
after how many characters the old content is deleted seems to depend how far away the cell is from the origin A1. The attached screenshot is on line 30 in column C
Comment 16 Buovjaga 2016-08-05 18:13:03 UTC
*** Bug 101151 has been marked as a duplicate of this bug. ***
Comment 17 Buovjaga 2016-08-05 18:14:37 UTC
Finally confirmed per dupe - also using Debian!
Comment 18 Dietmar 2016-08-05 20:48:22 UTC
plasma 5.7.0
KDE Framework 5.24.0
Qt 5.6.1
Kernel 4.6.4

Version: 5.2.0.1
Build-ID: 20m0(Build:1)
CPU-Threads: 4; BS-Version: Linux 4.6; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE.UTF-8)

on openSuSE didn't show this behavior.
Comment 19 Samuel 2016-08-05 22:24:24 UTC
As soon I use the modesetting driver in my xorg.conf under Debian Jessie the issue in LibreOffice is gone.

Working here with a brand new Skylake Hardware. I'am pretty unsure this is a LibreOffice or a X/Intel driver issue.

Works also with Debian Jessie and the NVIDIA driver without any issue.
Comment 20 Buovjaga 2016-08-06 10:11:53 UTC
Thanks, Samuel! Debian unstable has switched to modesetting as default: https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now-defaults-to-modesetting-driver-on-x/

Dietmar: are you seeing the problem with Intel's driver?

Adjusting version per Samuel's report.
Comment 21 Dietmar 2016-08-06 16:47:38 UTC
Yes, it is the Intel driver
Comment 22 Buovjaga 2016-08-06 19:06:24 UTC
Aaargh, now I am seeing it finally: I only see it, when inputting using the formula editor input field.

I also have Intel graphics (Skylake).

Arch Linux 64-bit, KDE Plasma 5
Version: 5.2.0.4
Build ID: 5.2.0-1
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: f3d26af51588af441f62fb69bb7a5432845226ac
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on August 5th 2016
Comment 23 Buovjaga 2016-08-06 20:06:43 UTC
*** Bug 101311 has been marked as a duplicate of this bug. ***
Comment 24 Buovjaga 2016-08-07 12:49:18 UTC
(In reply to Buovjaga from comment #22)
> Aaargh, now I am seeing it finally: I only see it, when inputting using the
> formula editor input field.

Update: I now see it sometimes when inputting directly to the cell.
Comment 25 Samuel 2016-08-08 09:31:24 UTC
Question is now, bug in LibreOffice or not?
Personally I see this graphic issues only in LibreOffice Calc, not for example in Writer or Gnome.
Comment 26 Caolán McNamara 2016-08-11 15:38:57 UTC
Does the gtk3 backend suffer from this as well (on the same hardware which shows the problem with the other backends).

And wrt bibisectRequest & regression, is there a version of LibreOffice which is known to not now suffer from this ?
Comment 27 Buovjaga 2016-08-11 16:41:56 UTC
Samuel: can you reproduce the problem by ensuring you use the gtk3 backend, launching from the command line:
SAL_USE_VCLPLUGIN=gtk3 libreoffice

I could not reproduce now with gtk3. I could immediately reproduce, when I switched back to my default, kde4 backend.
I could also repro with gtk and gen backends!

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: 5d8639aaf2f60157c99c3ee3a8bfa78e4efd010a
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on August 9th 2016
Comment 28 Caolán McNamara 2016-08-11 20:14:48 UTC
The gen, gtk and kde backends all share the same X11 code path, so *if* the bug is ours then its in there. I sort of feel the bug is "someone else" though. I wonder if

export SAL_SYNCHRONIZE=1 makes any difference to the broken case ?
Comment 29 Buovjaga 2016-08-11 20:28:49 UTC
(In reply to Caolán McNamara from comment #28)
> I wonder if
> 
> export SAL_SYNCHRONIZE=1 makes any difference to the broken case ?

You wondered correctly, I cannot repro with that variable set.
Comment 30 Samuel 2016-08-15 14:16:17 UTC
(In reply to Caolán McNamara from comment #28)
> export SAL_SYNCHRONIZE=1 makes any difference to the broken case ?

Works here as well (with Intel driver), no graphical glitches with this option.
What does this mean?
Comment 31 Samuel 2016-08-24 21:12:49 UTC
(In reply to Buovjaga from comment #27)
> Samuel: can you reproduce the problem by ensuring you use the gtk3 backend,
> launching from the command line:
> SAL_USE_VCLPLUGIN=gtk3 libreoffice

Should I try this also?

(In reply to Caolán McNamara from comment #28)
>> export SAL_SYNCHRONIZE=1 makes any difference to the broken case ?

> Works here as well (with Intel driver), no graphical glitches with this option.
> What does this mean?

Can somebody explain me what this mean?

Any change to fix this issue with the intel driver?
Comment 32 Samuel 2016-08-24 21:15:18 UTC
@  Caolán McNamara,
I add you to the CC list, feel free to remove your address (in this case sorry).
Comment 33 Caolán McNamara 2016-08-30 20:06:42 UTC
With SAL_SYNCHRONIZE set (for gtk3/x11) we call XSynchronize (https://tronche.com/gui/x/xlib/event-handling/protocol-errors/synchronization.html) which changes from the normal mode where applications don't wait for a response to a request from the X server to do something before moving on the the next request. So e.g. draw line, draw circle, draw line can be fired off without waiting for the X server to actually draw them. With it on, its draw line, wait for response that it drew, draw circle, wait, draw line, wait. Its much slower, so using XSynchonize isn't a fix. Its a pity that XSynchronize affects this, cause its far easier to debug with XSynchronize set to true, and easier to determine where the fault it.

Its probably easier to see if this is bibisectable and find out if there is a change on our side that triggered this to start happening.
Comment 34 Buovjaga 2016-10-22 07:31:21 UTC
*** Bug 100483 has been marked as a duplicate of this bug. ***
Comment 35 Cay Horstmann 2016-12-04 15:49:16 UTC
I have this bug on Ubuntu 16.04 with LXDE. LibreOffice 5.1.4.2. Intel i915 display driver. 

Remedy #1: Turn on OpenGL
Remedy #2: Use SAL_SYNCHRONIZE=1
Comment 36 Andreas Schleth 2017-01-06 15:35:06 UTC
Same here with openSUSE 42.2 (42.1 was OK).

Kernel: 4.9.0-4.g1af4b0f-default
Intel-Graphics (i6700)
LibreOffice Version:
Version: 5.2.3.3
Build-ID: 20m0(Build:3)
CPU-Threads: 8; BS-Version: Linux 4.9; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

The error shows only in larger calc docs with several filled cells.
I startet with "12345678" in one cell.  Everything was OK until I had about 50 cells filled with similar numbers.

See attachments "in_cell_editing_error".
Comment 37 Andreas Schleth 2017-01-06 15:35:31 UTC
Created attachment 130206 [details]
screenshot
Comment 38 Andreas Schleth 2017-01-06 15:35:58 UTC
Created attachment 130207 [details]
simple odt doc
Comment 39 Buovjaga 2017-02-19 19:08:43 UTC
*** Bug 106065 has been marked as a duplicate of this bug. ***
Comment 40 Buovjaga 2017-04-13 20:13:59 UTC
*** Bug 100802 has been marked as a duplicate of this bug. ***
Comment 41 kchin80 2017-04-15 16:01:36 UTC
Reproducible with the following:

Linux localhost 4.10.8-1-ARCH #1 SMP PREEMPT Fri Mar 31 16:50:19 CEST 2017 x86_64 GNU/Linux

gtk3 3.22.10-1
plasma-desktop 5.9.4-1
plasma-framework 5.32.0-1
qt4 4.8.7-16
qt5-base 5.8.0-7

Version: 5.3.2.2
Build ID: 5.3.2-1
CPU Threads: 4; OS Version: Linux 4.10; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: en-US (en_US.UTF-8); Calc: group

However, when running Libreoffice Calc using SAL_USE_VCLPLUGIN=gtk3, the issue is not appearing.
Comment 42 Max A. Dednev 2017-04-18 20:03:37 UTC
Distributor ID: Debian
Description:    Debian GNU/Linux 8.7 (jessie)
Release:        8.7
Codename:       jessie

Linux verstak 4.9.0-0.bpo.2-amd64 #1 SMP Debian 4.9.18-1~bpo8+1 (2017-04-10) x86_64 GNU/Linux

X.Org X Server 1.16.4
Release Date: 2014-12-20

Integrated Graphics Chipset: Intel(R) HD Graphics 620:
00:02.0 VGA compatible controller: Intel Corporation Device 5916 (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device 8234
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at 1ffe000000 (64-bit, non-prefetchable) [size=16M]
        Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 5000 [size=64]
        [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: i915

Version: 5.2.6.2
Build ID: a3100ed2409ebf1c212f5048fbe377c281438fdc
CPU Threads: 4; OS Version: Linux 4.9; UI Render: default; VCL: kde4; 
Locale: en-US (C); Calc: group

I have same issue with overlapping text while editing data in cell, specifically while entering long number. I've tried LO5.3 but it has exactly the same issue. But original LO version 4.3.3-2+deb8u6 from Debian 8 distribution runs perfectly without any text overlapping.

SAL_SYNCHRONIZE=1 solves this issue for LO5.2/LO5.3 at the cost of flickering.
Comment 43 Aron Budea 2017-05-06 04:11:28 UTC
*** Bug 107640 has been marked as a duplicate of this bug. ***
Comment 44 Buovjaga 2017-05-14 12:03:12 UTC
*** Bug 107808 has been marked as a duplicate of this bug. ***
Comment 45 Peer Griebel 2017-05-26 06:43:31 UTC
I have the same problem.
Using Gentoo, Intel Graphics. I'm willing to provide more information if needed.
Comment 46 Caolán McNamara 2017-05-26 10:08:10 UTC
caolanm->peer: what could be helpful is to identify the range of commits where this problem began. https://wiki.documentfoundation.org/QA/Bibisect for the how to on that.
Comment 47 Bernhard Frauendienst 2017-05-26 12:39:30 UTC
I have the same problem with an upstream binary rpm package running on Exherbo Linux 64 bit, KDE, Intel Graphics.

I tried bisecting bibisect-linux-64-5.3	and bibisect-linux-64-5.4, but couldn't reproduce the problem in either of them.
Comment 48 Bernhard Frauendienst 2017-05-26 15:26:15 UTC
I'm sorry, looks like the bibisect builds start with a different VCL than my local install.

Using SAL_USE_VCLPLUGIN=gen, I could reproduce the bug in the `oldest` builds of both bibisect-linux-64-5.3 and bibisect-linux-64-5.4, and will now work my way backwards as fast as my downstream permits ;)
Comment 49 Bernhard Frauendienst 2017-05-26 16:21:58 UTC
Got something in lo-linux-dbgutil-daily-till52 

$ git bisect log
> # bad: [d3acb9dfa21e2597d0affe3f04fe18b2022b9026] 2016-05-26: source-hash-a042951ad4db2b84021e1d43361511dec998ce82
> # good: [69eedb44a433e3be69137a83238a4184785c752f] 2015-11-25: source-hash-7289a140fc68dc898ba2b2357cc960968195f236
> git bisect start 'origin/master' 'oldest'
> # good: [7d1c6fda154836547542c6d741f34a158dd1102c] 2016-02-24: source-hash-f84b8c03462238b821724b7f504ad141c83fcf8f
> git bisect good 7d1c6fda154836547542c6d741f34a158dd1102c
> # good: [2592d68f5be89cc78dd3fc00360d4829790c2827] 2016-04-10: source-hash-7b9a5e8124328da9d81aed58cf944c91560a7c07
> git bisect good 2592d68f5be89cc78dd3fc00360d4829790c2827
> # bad: [c8c7bdf3034dccf1b28146e88e6280e2ca7c814c] 2016-05-03: source-hash-fa6efd4511a999618fd3958c1c72811dc0ef83ee
> git bisect bad c8c7bdf3034dccf1b28146e88e6280e2ca7c814c
> # bad: [26b2ac124a94a6717a873166bdd442c593bbfbf8] 2016-04-21: source-hash-5bb308a9ad16f6002486a60e4a753693818580b6
> git bisect bad 26b2ac124a94a6717a873166bdd442c593bbfbf8
> # good: [8f05b9642652b52965004311bf9a20cb4f70b9ce] 2016-04-15: source-hash-561ae8b0803f2ff1d09345c204c2973c44dba25d
> git bisect good 8f05b9642652b52965004311bf9a20cb4f70b9ce
> # good: [a1571e2d7d4d29716120c72113f6cca733ffe9a1] 2016-04-18: source-hash-92ddd584f1b8777932d86e26120977b9b66af8a4
> git bisect good a1571e2d7d4d29716120c72113f6cca733ffe9a1
> # good: [af327e85a23b4ecd96bfebb7386a31bec1ba4912] 2016-04-20: source-hash-f4827e1bba5d6951cfc995531342395f8bc9a630
> git bisect good af327e85a23b4ecd96bfebb7386a31bec1ba4912
> # first bad commit: [26b2ac124a94a6717a873166bdd442c593bbfbf8] 2016-04-21: source-hash-5bb308a9ad16f6002486a60e4a753693818580b6
Comment 50 Bernhard Frauendienst 2017-06-19 18:58:09 UTC
Does this help, or is there any more useful information I can provide?
Comment 51 Mac Duff 2017-06-30 21:34:29 UTC
I have found one cause of this problem.  When LibreOffice Calc is used with Linux mint 18.1 and KDE 5.8.7, the overwrite only happens if the System > Font settings are set to force font DPI to greater than 96 points.  At 96 points the cells behave themselves perfectly.
Comment 52 andis.lazdins 2017-07-01 05:48:48 UTC
(In reply to Mac Duff from comment #51)
> I have found one cause of this problem.  When LibreOffice Calc is used with
> Linux mint 18.1 and KDE 5.8.7, the overwrite only happens if the System >
> Font settings are set to force font DPI to greater than 96 points.  At 96
> points the cells behave themselves perfectly.

It seems that the workaround doesn't work in all systems, in my case (Ubuntu 16.04, 64 bit) system fonts are 96 dots and I still have this issue. The only way I found to get rid of this issue is to activate OpenGL, but it makes even more problems with flickering scrolling and freezing of screen during moving.
Comment 53 Dan Dascalescu 2017-07-08 06:30:08 UTC
Created attachment 134538 [details]
Text overlap when scrolling past the fold

Reproduced in 5.3.4.2 on Ubuntu 16.04 running on a Dell laptop with an integrated Intel video card.

New tidbit: the behavior happens after I scroll past the fold.

Will this behavior still show on a laptop with a dedicated NVidia graphics card?
Comment 54 Buovjaga 2017-07-09 15:03:20 UTC
(In reply to Dan Dascalescu from comment #53)
> Will this behavior still show on a laptop with a dedicated NVidia graphics
> card?

You just have to try and see, but be sure to explicitly switch to the NVidia, if it uses a bumblebee solution: https://wiki.archlinux.org/index.php/bumblebee
During the weekend I tested with such an Optimus bumblebee laptop and I saw the problem. It must have used the Intel gfx at that moment.
Comment 55 Xavier Van Wijmeersch 2017-07-09 20:35:18 UTC
can't reproduce the behavior with
old laptop Dell Latitude D620
Intel(R) Core(TM)2 cpu T5500 @1.66Ghz
build year 2006; mesa 17.1.4
Mesa DRI Intel(R) 945GM x86/MMX/SSE2

Version: 5.4.0.1.0+
Build ID: 367de96d58043f3a4e7809fa2d588e263a86af1b
CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:libreoffice-5-4, Time: 2017-07-05_08:14:09
Locale: nl-BE (en_US.UTF-8); Calc: group

Version: 5.3.4.2
Build ID: SlackBuild for 5.3.4 by Eric Hameleers
CPU Threads: 2; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: nl-BE (en_US.UTF-8); Calc: group
Comment 56 Buovjaga 2017-07-18 16:42:14 UTC
*** Bug 104474 has been marked as a duplicate of this bug. ***
Comment 57 Buovjaga 2017-09-02 13:50:39 UTC
*** Bug 109336 has been marked as a duplicate of this bug. ***
Comment 58 Buovjaga 2017-11-15 14:40:42 UTC
*** Bug 113796 has been marked as a duplicate of this bug. ***
Comment 59 Buovjaga 2017-11-16 14:04:38 UTC
*** Bug 113678 has been marked as a duplicate of this bug. ***
Comment 60 Gauthier 2017-11-28 13:36:37 UTC
Same issue here:

Version: 5.4.3.2
Build ID: 1:5.4.3~rc2-0ubuntu0.16.04.1~lo1
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: kde4; 
Locale: en-GB (en_GB.UTF-8); Calc: group

Using Intel GPU Skylake
Kernel 4.10.0-40
Plasma 5.11.3

It's reproduced whether I use kde, gtk2 or gtk3 VCL.
Comment 61 Caolán McNamara 2017-11-28 14:51:28 UTC
Are you certain you can see this with the gtk3 vclplug too ?, i.e. that help->about has "VCL: gtk3" in it ?
Comment 62 Buovjaga 2017-11-28 16:09:40 UTC
(In reply to Caolán McNamara from comment #61)
> Are you certain you can see this with the gtk3 vclplug too ?, i.e. that
> help->about has "VCL: gtk3" in it ?

Gauthier: can you answer this?
Comment 63 Gauthier 2017-11-29 15:35:22 UTC
Hummm...how can say this...I swear yesterday I had the bug with gtk3...and the best behaviour was with gtk2 so I reinstalled gtk2 (although bug was still there but just a little)

BUT I've just reinstalled the gtk3 integration package to check again in response to question...and no more bug!! 

Either I made a mistake when trying config yesterday in which case I apology...or something happened. I have fiddle around I/O schedule and font config. I change anti-aliasing settings in plasma system settings but then went back to what it was...so can't see how any of that could have had an effect.

I have just restart my PC to make sure...and I can confirm...no more bug :)
Comment 64 Mac Duff 2017-11-29 23:15:41 UTC
Installing gtk3 on my Mint 18.2 KDE fixed the problem on LibreOffice Version: 5.1.6.2 on a Lenovo 
Build ID: 1:5.1.6~rc2-0ubuntu1~xenial2

Works now at high resolutions on a Lenovo T450s with high res screen.
Comment 65 andis.lazdins 2017-11-30 05:42:40 UTC
(In reply to Mac Duff from comment #64)
> Installing gtk3 on my Mint 18.2 KDE fixed the problem on LibreOffice
> 

Sorry for stupid question, but what do you mean with installation of GTK3? I have Ubuntu 16.04 64 bit, MATE 1.12.2 and Libreoffice 5.4.3.2 with VCL:gtk2. There are some GTK3 related packages installed in the system, but nothing related to Libreoffice is available.
Comment 66 Mac Duff 2017-11-30 13:58:09 UTC
Using Synaptic Package Manager search for "libreoffice-gtk3"

That should display the line and description.  Just install it from there.
Comment 67 Mac Duff 2017-11-30 13:58:42 UTC Comment hidden (obsolete)
Comment 68 andis.lazdins 2017-11-30 14:47:41 UTC
(In reply to Mac Duff from comment #67)
> Using Synaptic Package Manager search for "libreoffice-gtk3"
> 
> That should display the line and description.  Just install it from there.

I'm using Libreoffice installation downloaded from the official website. It doesn't have such libreoffice-gtk3 package. It is available for the version bundled with Ubuntu, but, I guess, it is conflicting with other libreoffice versions installed. At least there are no changes in VCL: gtk2 after installation of the bundled libreoffice-gtk3.
Comment 69 Buovjaga 2018-02-11 15:15:14 UTC
*** Bug 115102 has been marked as a duplicate of this bug. ***
Comment 70 Allan 2018-02-11 22:35:02 UTC
After running into this issue with both Linux Mint xfce and Linux Mint Mate, I decided to try Kubuntu LTS, and it works perfectly fine there.
Comment 71 Bernhard Frauendienst 2018-03-24 14:18:37 UTC
Is there any news on this? Do you need more information? Did the bibisect information I provided help in any way?
Comment 72 Buovjaga 2018-03-24 14:34:22 UTC
(In reply to Bernhard Frauendienst from comment #49)
> > # first bad commit: [26b2ac124a94a6717a873166bdd442c593bbfbf8] 2016-04-21: source-hash-5bb308a9ad16f6002486a60e4a753693818580b6

The source hash is: https://cgit.freedesktop.org/libreoffice/core/commit/?id=5bb308a9ad16f6002486a60e4a753693818580b6

The only thing that it might be related to is svx/source/dialog/charmap.cxx in my view.

Julien: do you think the bibisect result is correct? If not, feel free to remove yourself from CC.
Comment 73 Julien Nabet 2018-03-24 14:48:38 UTC
(In reply to Buovjaga from comment #72)
> (...
> Julien: do you think the bibisect result is correct? If not, feel free to
> remove yourself from CC.

About svx/source/dialog/charmap.cxx,
there was a previous change from here: 85dd50819b8b736e8a791ed3f001145a0df54265
then I reverted it with 5bb308a9ad16f6002486a60e4a753693818580b6

Idem for svx/source/form/fmvwimp.cxx
85dd50819b8b736e8a791ed3f001145a0df54265 reverted by 5bb308a9ad16f6002486a60e4a753693818580b6

For the other 2 files, it's a bit more tricky to tell.
Comment 74 Martin 2018-04-10 09:54:03 UTC
After a long time of banging my head against this wall, I just discovered I can reliably reproduce and solve (work-around) the problem by adding and removing the Cell Freeze in my offending sheet.

Tested/reproduced/solved in LO 1:6.0.3~rc2-0ubuntu0.17.10.1~lo2 (Ubuntu packages)
CPU threads: 4; OS: Linux 4.16; UI render: default; VCL: kde4; 
Locale: nl-NL (en_US.UTF-8); Calc:
Comment 75 Martin 2018-04-10 10:16:59 UTC
Hmm... I cheered too soon. This only solves the problem if the row is above a certain line in my Calc window. This means: the problem now starts at row 25, but if I scroll the sheet down, the whole sheet is again affected.
Comment 76 Buovjaga 2018-04-11 12:21:43 UTC
Finally was able to bisect this - and reliably!
The effect manifests more and more when you go further away from A1. So I always clicked to T1 and started pressing some letter.
I used the gen VCL backend.

Result:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=29a9f433c268414747d8ec7343fc2b5987971738

commit	29a9f433c268414747d8ec7343fc2b5987971738 (patch)
tree	880958e82d23c37b0511efc88c27651ffd3c99b9
parent	7a264c3bbaab6b32741333c6862c902930d8654c (diff)
Resolves: tdf#91778 drawing the background over an active cursor
will overwrite it, which means that when it toggles "off" afterwards, it uses
invert on the freshly drawn background which will visually make it appear "on"
and not off

Just explictly turn it off and restore it and avoid the whole potential
problem.

Change-Id: Ie21d77e9d704124011e43b42c98b26eaf208eef2
Comment 77 Xisco Faulí 2018-04-11 14:53:53 UTC
Adding Cc: to Caolán McNamara
Comment 78 Caolán McNamara 2018-04-12 13:57:30 UTC
I'm unconvinced, reverting that brings back the broken cursor problem it fixes.
Comment 79 Caolán McNamara 2018-04-12 14:01:50 UTC
Created attachment 141311 [details]
debugging patch

caolanm->Buovjaga: are you in a position to build with the attached patch ? Does the background of the cell change to red with it in place ?
Comment 80 Buovjaga 2018-04-12 16:37:43 UTC
(In reply to Caolán McNamara from comment #79)
> Created attachment 141311 [details]
> debugging patch
> 
> caolanm->Buovjaga: are you in a position to build with the attached patch ?
> Does the background of the cell change to red with it in place ?

Thanks, I did git apply and built.

Yes, actually the overwriting effect is seen in a sort of "foreshadowing" style even when typing to an empty cell. The red background appears after the ninth typed character.

With SC_NOINLINETEXT=1, the text is not seen when typed in an empty cell. It appears after focusing out of the cell.
When typing over old text, the old text is visible until I have typed the ninth character. Then there is only redness.
Comment 81 Caolán McNamara 2018-04-12 16:45:14 UTC
so the bg doesn't clear (for some unknown reason) in the first place apparently
Comment 82 Caolán McNamara 2018-04-12 16:57:49 UTC
Created attachment 141313 [details]
does this make any difference ?
Comment 83 Buovjaga 2018-04-12 19:13:55 UTC
(In reply to Caolán McNamara from comment #82)
> Created attachment 141313 [details]
> does this make any difference ?

Now the background turns red immediately upon typing.
In a cell with existing content, old text is not visible when new typing begins.

With SC_NOINLINETEXT=1, no text (new or old) is visible when typing. Either in an empty cell or one with content.
Comment 84 Caolán McNamara 2018-04-13 08:26:30 UTC
That sounds a lot like "that would work", so how about https://gerrit.libreoffice.org/#/c/52810/ as an actual proposed solution, does that work in practice ?
Comment 85 Buovjaga 2018-04-13 09:33:23 UTC
(In reply to Caolán McNamara from comment #84)
> That sounds a lot like "that would work", so how about
> https://gerrit.libreoffice.org/#/c/52810/ as an actual proposed solution,
> does that work in practice ?

Yes, it works! No overwriting/shadowing anymore.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 16b51d73c94f6fcab45695e4353cbe4ee97b52cc
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on April 13th 2018
Comment 86 Commit Notification 2018-04-13 10:17:13 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=75dba661d97c625fee8fd2b80c90b9adba9aeffb

Related: tdf#100925 background not getting set under X sometimes

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.
Comment 87 Commit Notification 2018-04-13 15:10:31 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ccb90e3266336d6b022c48ec90cd55450c9c209e&h=libreoffice-6-0

Related: tdf#100925 background not getting set under X sometimes

It will be available in 6.0.4.

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 88 Commit Notification 2018-04-13 15:10:48 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e8080c79043a7d9036f27cc24b76b7ff21c58da8&h=libreoffice-5-4

Related: tdf#100925 background not getting set under X sometimes

It will be available in 5.4.8.

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 89 Caolán McNamara 2018-04-16 20:01:00 UTC
caolanm->Buovjaga: do you think we can call this fixed now ?
Comment 90 Buovjaga 2018-04-17 06:05:38 UTC
(In reply to Caolán McNamara from comment #89)
> caolanm->Buovjaga: do you think we can call this fixed now ?

Sure. Of course it would be fantastic, if other people CC'd to this report would verify the fix: https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/current/
Comment 91 Commit Notification 2018-04-30 10:08:45 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-4-7":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e89c5ec55dd5eedbd2b3822f14e73a486beef13&h=libreoffice-5-4-7

Related: tdf#100925 background not getting set under X sometimes

It will be available in 5.4.7.

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 92 Jean-Baptiste Faure 2018-05-03 13:59:57 UTC
I have the same double display slightly offset when I double click in a cell to edit its content and move the cursor inside the cell. Even with the fixes from comments #86 and #87.
In branch 6.0 it appeared recently and after the fix, only with GTK3 backend (no problem with GTK2 backend).

A bisection on branch 6.0 showed that the problem is introduced or reintroduced by commit https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=28f2941680f850e88228e45699ac612ce036cf16

I am not able to say if that is exactly the same bug or if it has only the same effect.

I am available to test a patch. I build LO under Ubuntu/Unity 16.04 x86-64.

Best regards. JBF
Comment 93 Caolán McNamara 2018-05-03 14:12:39 UTC
This bug is a dumpster fire, can you please file something separate and new for your new finding, and add me on cc to it.
Comment 94 Xisco Faulí 2018-05-04 09:00:36 UTC
(In reply to Caolán McNamara from comment #93)
> This bug is a dumpster fire, can you please file something separate and new
> for your new finding, and add me on cc to it.

bug 117413 has been reported as a follow-up bug. I guess we can close this one as RESOLVED FIXED for the time being...
Comment 95 Caolán McNamara 2018-05-04 10:50:19 UTC
yeah, lets do that. If there are further problems use a new bug.