Created attachment 120590 [details] incompletely painted Start Center Steps, one way: (1) Using a new user profile (command line parameter -env:UserInstallation=file:...) run LibreOffice. Observe that Start Center is incompletely painted, as per screenshot attached. Alternatively: (2) Using the user profile from (1), run Writer. Observe that the Writer window is incompletely painted. But to fix the user profile: (3) Using the user profile from (1), run Calc. The easy repair in (3) suggests that this is a minor bug. However, I can imagine that it could hit a brand new user, which suggests a higher priority. The problem seems to have come into LibreOffice between daily dbgutil repository versions (line breaks added) ... # good: [fd6fe1bff0803943d1859d4cb07f041ba6b6ac05] 2015-11-12: source-hash-4b918705f67d0837b56e56d7abac23e6eb21feb4 git bisect good fd6fe1bff0803943d1859d4cb07f041ba6b6ac05 and # bad: [455dfd0b0d56d73db59d588c1cd433206f275974] 2015-11-13: source-hash-41379970e8c6b75563b7c162b4e760b9e93a5bea git bisect bad 455dfd0b0d56d73db59d588c1cd433206f275974 so I am setting whiteboard bibisected.
The fix which I gave in (3) of the bug description does not work for me now. (What did I really do then? I do not know.) Anyway, I now offer a revised fixup: (3b) In the ill-painted Writer window, maximize and then unmaximize the window.
I can confirm this with the gtk3 backend, not with the gtk(2) one, though. It would be good to bisect the range to see the exact commit.
git bisect says: 6adfbe62f6bb67d7d78c1561e9af5169d7f5bb9a is the first bad commit commit 6adfbe62f6bb67d7d78c1561e9af5169d7f5bb9a Author: Caolán McNamara <caolanm@redhat.com> Date: Thu Nov 12 10:36:38 2015 +0000 Resolves: rhbz#1278885 gtk3 allocated size doesn't match configure-event size so LibreOffice thinks its window is smaller than what gtk3 has allocated for it. For gtk3 (like firefox does) split size and position handling, leave position/move handling to the configureEvent, but listen to sizeAllocate and use that for the size handling. Leave gtk2 as it always was Change-Id: Ic52d6971595741ed658247b651e9e16c2ef9ed0b :040000 040000 6b3162a38216d0d122b979000ee6982e96a2b4c1 7ba607ec85c939c67e9f8e0beb56a75070a84f7b M vcl Adding Cc: to caolanm@redhat.com; Could you possibly take a look at this? Thanks In case you can't reproduce, happy to tar up my user profile to see if that helps. The problem happens right after startup, i.e. forces me to use the gtk2 vcl backend to do anything. :-)
*** Bug 96108 has been marked as a duplicate of this bug. ***
This doesn't happen for me, but does http://cgit.freedesktop.org/libreoffice/core/commit/?id=585507a4127ff91d9360ca16938dbd36153aef0d make a difference ? If it doesn't then perhaps this depends on the version of gtk3 or something of that nature. So what are your gtk3 versions ?
> does http://cgit.freedesktop.org/libreoffice/core/commit/?id=585507a4127ff91d9360ca16938dbd36153aef0d make a difference ? No, I can still reproduce this with a more recent build, 129935443cfd9378e1263489fc4bf47aee1f1a46. Be sure to use a new user profile or you need to do a $ rm user/registrymodifications.xcu to reproduce this issue.
And I still see the problem with daily dbgutil bibisect version 2015-12-02. Setting status back to NEW.
and what versions of gtk3 do luke and terrence have ?
$ apt-cache policy libgtk-3-0 Installed: 3.14.13-0ubuntu1 In Bug 96108 this was confirmed on ArchLinux 64bit, which should be a very recent build of gtk3. Terrence, how about you?
I also reproduced it once on Fedora 23 some days ago, but couldn't reproduce again since then.
In the debian-sid environment to which I chroot, I have libgtk-3-{bin,common,dev} version 3.16.6-1.
*** Bug 96235 has been marked as a duplicate of this bug. ***
On my Debian (testing) laptop libgtk-3-0: Installé : 3.18.5-1 Candidat : 3.18.5-1 Table de version : *** 3.18.5-1 0 500 http://ftp.fr.debian.org/debian/ testing/main amd64 Packages 100 /var/lib/dpkg/status
I use enable-dbgutil, if it can help, here's my autogen.input: --with-system-odbc --enable-ext-barcode --enable-ext-diagram --enable-ext-hunart --enable-ext-nlpsolver --enable-ext-ct2n --enable-ext-numbertext --enable-postgresql-sdbc --enable-ext-typo --enable-ext-validator --enable-ext-watch-window --enable-ext-wiki-publisher --enable-dbus --enable-graphite --enable-werror --enable-debug --enable-dbgutil --enable-crashdump --enable-dependency-tracking --enable-online-update --enable-extra-sample --enable-extra-template --enable-extra-gallery --enable-python=internal --without-system-mariadb --enable-ext-mariadb-connector --enable-bundle-mariadb --enable-avahi --enable-eot --enable-odk #--enable-mergelibs --with-lang=en-US it fr de es pt ru cs hu pl da sv el sk is nl #--with-lang=ALL --with-myspell-dicts #--enable-evolution2 #--with-help
I think I'll have to get a bit more radical to get this right. So I'll split off the gtk2 stuff from the gtk3 stuff here so gtk2 can remain using the scheme that works for it and I can freely rejig the gtk3 stuff
As another data point, I can reproduce this with a clean install of Ubuntu 15.10, gtk3: 3.16.7-0ubuntu3 Reported distros: Arch, Ubuntu, Debian
(In reply to Caolán McNamara from comment #5) > This doesn't happen for me, but does > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=585507a4127ff91d9360ca16938dbd36153aef0d make a difference ? No, sadly. > If it doesn't then perhaps this depends on the version of gtk3 or something > of that nature. So what are your gtk3 versions ? $ rpm -q gtk3-devel gtk3-devel-3.14.15-21.1.x86_64 Quite possible it's about some older gtk version vs your one. :-)
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=77f2fed86d512d8e1942a75b91cd13ce1945c149 Resolves: tdf#95865 gtk3: disentangle Geometry handling 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.
ok, let me know if this works or fails. If it works I'll backport to 5.1
With master sources updated today commit 8dea939d65cd3cdd744d21a9f60444a97e45962b Author: Caolán McNamara <caolanm@redhat.com> Date: Fri Dec 4 15:15:06 2015 +0000 implement SAL_INVERT_TRACKFRAME invert via cairo this gives the same (terrible?) pattern as quartz for dragging toolbars around (and so with all the gtk/gtk3 rework which was just before), I don't reproduce tdf#96235 (set as a dup of this one) and startcenter is ok. I'll let Terrence give it a try but I think that we can already thank you as usual Caolan! :-)
With daily dbgutil bibisect version 2015-12-05 ,,, Version: 5.2.0.0.alpha0+ Build ID: 8ac2b6d077f4e7b1c5a010c2960fb08c0132da5f Threads 1; Ver: Linux 3.2; Render: default; Locale: en-CA (en_CA.UTF-8) the problem is gone. Thank you, Caolán. I am setting status VERIFIED FIXED.
Confirmed as well, thanks a lot.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2fbff6cdb3266a26a32390ddddd58ebd11947c49&h=libreoffice-5-1 Resolves: tdf#95865 gtk3: disentangle Geometry handling It will be available in 5.1.0.1. 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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]