Description: LibreOffice quiets when minimizing start center if previously a presentation ran Steps to Reproduce: 1. Launch LibreOffice 2. Download and open attachment 166482 [details] 3. Press F5 4. Press ESC 5. Close they document (gray cross) 6. Minimize start center Actual Results: LibreOffice quits Expected Results: Still running Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha1+ (x64) Build ID: eeed9103350d886f5913aed9b525d863a421dffa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
Couldn't reproduce in: Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Could reproduce in: Version: 7.1.0.0.alpha1+ (x64) Build ID: 00e5c63c35307faacf76a5e2ca7953c4208244ed CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Actually this is effects all components. Steps to reproduce: 1. Launch LibreOffice 2. Create a new Writer Document/Calc Spreadsheet/Impress Presentation/etc ... 3. Close the document (gray cross) or click File - Close 4. Minimize start center Actual Results: LibreOffice quits Expected Results: Libreoffice minimize only Version: 7.1.0.0.alpha1+ (x64) Build ID: 631974dd958fe4ca1d1f2164266e1e2c81b325ce CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL
Bibisected using bibisect-win64-7.1 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit?id=6dfbab409032516e05a63fbc777b9147d1deb4ec author: Jan-Marek Glogowski <glogow@fbihome.de> committer: Jan-Marek Glogowski <glogow@fbihome.de> summary: tdf#136555 apply window bg color for button boxes Adding Cc: Jan-Marek Glogowski
I can't reproduce at on Linux with either gen or kf5, just to exclude it's a native menu problem. With today's master from bibisect repo: Version: 7.1.0.0.alpha1+ Build ID: 548d77d0c06f7088dd3eb408797aa1fc1d7eb277 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: x11 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Or with a ~week old Win build, which just has Firebird and a patch for tdf#93352 on top, which would neither "fix" this kind of problem. The bibisected commit isn't Windows specific. I updated my Windows build to master with commit 0d071acc0bd422e6d9af14cc7d7f35b6b3356478 (same patcheset) and still can't reproduce. First I thought it might be a fallout from the Impress part of bug 126700, but that wouldn't match the Writer reproducer you gave. And LO just quits, so it's not a crash. OTOH the bug has blockers on Skia and Crash and I just have a Windows VM without 3D and nothing in that commit remotely touches low level graphics code. If you can't reproduce without Skia, then I would look for a Graphics driver problem, from all the Skia the blacklisting lately.
It's Skia specific.. but unrelated to drivers: talking about Skia Raster (not Vulkan) Version: 7.1.0.0.alpha1+ (x64) Build ID: 5a96093f0ecee53432bdf35f247edd6deb501baf CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL And leaving in the middle if it's crash or graceful exit. Kind of hard to tell with they start center
(In reply to Telesto from comment #5) > It's Skia specific.. but unrelated to drivers: talking about Skia Raster > (not Vulkan) > > Version: 7.1.0.0.alpha1+ (x64) > Build ID: 5a96093f0ecee53432bdf35f247edd6deb501baf > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win > Locale: nl-NL (nl_NL); UI: en-US > Calc: CL > > And leaving in the middle if it's crash or graceful exit. Kind of hard to > tell with they start center Oh. I totally missed that I had Skia disabled in Windows. Now I can reproduce the crash. It actually hits the std::abort() in SkiaSalGraphicsImpl::createWindowSurface(). That line has the following comment: // This should not really happen, do not even try to cope with it. Pending workaround at: https://gerrit.libreoffice.org/c/core/+/105963 IMHO VCL shouldn't send empty images to the backends, like in bug 130831, which is completely unrelated but has the same kind of hack as a fix.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/42e30c24615402c49351f80cc8a47d61d47267c6 tdf#138022 Skia don't recreate empty surfaces It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/838ff2e26e484f2601b0c18756e9230cd7a5d9e9 tdf#138022 Skia don't recreate empty surfaces It will be available in 7.0.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in: Version: 7.1.0.0.alpha1+ (x64) Build ID: 693f12ad57912c2356a197d9a794e6108ce79ef2 CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL Thanks for fixing this issue!