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.
sorry, the behavior with a new document is wrong too
I don't see the problem. I also tried in Linux yesterday and no problem with editing cells. Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ Build ID: 28ac6fdc11559b58ac62089300aa99530b0b822d CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-07-18_02:54:20 Locale: fi-FI (fi_FI); Calc: CL
But you are using a windows version. Under Windows on the same machine i did not see this behavior like you
(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.
http://ruderninleipzig.de/index.php?option=com_content&view=article&id=167 shows in a video the behavior
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
(In reply to Dietmar from comment #5) > http://ruderninleipzig.de/index.php?option=com_content&view=article&id=167 > shows in a video the behavior So what exactly is happening in the videos: are you hitting F2 to edit a cell with existing content?
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
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
This is the normal behavior. I thought you meant editing by double-clicking or F2 was causing this. Closing.
But how can be this the normal behavior? Normal for me is, I enter the first new character and all old content disapears! Hmmm....
(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.
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.
Created attachment 126394 [details] screenshot
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
*** Bug 101151 has been marked as a duplicate of this bug. ***
Finally confirmed per dupe - also using Debian!
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.
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.
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.
Yes, it is the Intel driver
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
*** Bug 101311 has been marked as a duplicate of this bug. ***
(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.
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.
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 ?
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
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 ?
(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.
(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?
(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?
@ Caolán McNamara, I add you to the CC list, feel free to remove your address (in this case sorry).
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.
*** Bug 100483 has been marked as a duplicate of this bug. ***
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
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".
Created attachment 130206 [details] screenshot
Created attachment 130207 [details] simple odt doc
*** Bug 106065 has been marked as a duplicate of this bug. ***
*** Bug 100802 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 107640 has been marked as a duplicate of this bug. ***
*** Bug 107808 has been marked as a duplicate of this bug. ***
I have the same problem. Using Gentoo, Intel Graphics. I'm willing to provide more information if needed.
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.
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.
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 ;)
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
Does this help, or is there any more useful information I can provide?
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.
(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.
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?
(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.
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
*** Bug 104474 has been marked as a duplicate of this bug. ***
*** Bug 109336 has been marked as a duplicate of this bug. ***
*** Bug 113796 has been marked as a duplicate of this bug. ***
*** Bug 113678 has been marked as a duplicate of this bug. ***
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.
Are you certain you can see this with the gtk3 vclplug too ?, i.e. that help->about has "VCL: gtk3" in it ?
(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?
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 :)
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.
(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.
Using Synaptic Package Manager search for "libreoffice-gtk3" That should display the line and description. Just install it from there.
(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.
*** Bug 115102 has been marked as a duplicate of this bug. ***
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.
Is there any news on this? Do you need more information? Did the bibisect information I provided help in any way?
(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.
(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.
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:
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.
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
Adding Cc: to Caolán McNamara
I'm unconvinced, reverting that brings back the broken cursor problem it fixes.
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 ?
(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.
so the bg doesn't clear (for some unknown reason) in the first place apparently
Created attachment 141313 [details] does this make any difference ?
(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.
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 ?
(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
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.
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.
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.
caolanm->Buovjaga: do you think we can call this fixed now ?
(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/
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.
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
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.
(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...
yeah, lets do that. If there are further problems use a new bug.
A fix for this problem on Ubuntu 16.04 with KDE and using the default version of Libreoffice shipped with Ubuntu: ------ Section "Device" Identifier "card0" Driver "intel" Option "AccelMethod" "blt" EndSection -------- at /usr/share/X11/xorg.conf.d/20-intel.conf. You also may want to go to systemsetting -> desktop behaviour -> desktop effects and uncheck the window maximize effect, just because this effect gets a little funky with the blt AccelMethod (just a tiny little glitch compared to the huge usability problem reported here).