Created attachment 116145 [details] Move the file picker around and the canvas does not repaint. Using 5.0 on Linux and using the native OS picker, if you do a file > open, it's not firing in a new thread and the canvas in the background is blocked from repaints as the dialog is moved around. If you configure LO to use the native file picker, this symptom is not seen and the dialog can be moved and the canvas repaints. So in some way these two dialogs are being fired differently. This leads users to think LO has deadlocked. Attaching screenshot.
Not reproduced. DE: Unity, in a VM. Ubuntu 15.04 64-bit Version: 5.1.0.0.alpha1+ Build ID: be01d68420086fc36ecf26b5f597ba7c6b29b369 TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-05-28_03:30:12 Locale: en-US (en_US.UTF-8)
Added Michael Meeks per his IRC request. I have a bit more information. This is happening on 5.0 snapshot from 5-27. I installed the snapshot from 5-29 on another server and performed the same test and it's doing the same thing. So it's multiple users, happens with .config folder completely wiped. This is being tested over NX technology, similar to remote X but with compression. Most similar technology to this would be VNC. Maybe it's not seen when the video card is local. I still feel that whatever is happening is easily fixed because the LO native dialog works perfectly and does not leave artifacts. I can maybe bibisect if not replicated or seen elsewhere.
I see a failure to repaint in (chroot to) debian-sid with daily dbgutil version 2015-06-01 ... Version: 5.1.0.0.alpha1+ Build ID: e61fcfea5c2a306e44a053976e921160e78917ac Locale: en-CA (en_CA.UTF-8) and with LibreOffice version ... Version: 5.0.0.0.beta1 Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3 Locale: en-CA (en_CA.UTF-8 but not with ... Version: 4.5.0.0.alpha0+ Build ID: a272f5b7b30f356418ecf28eb95d066f081d1624 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-01-09_09:50:59 Locale: en_CA nor with ... Version: 5.1.0.0.alpha1+ Build ID: 1a8e9dae32997bf199dbd192058fcd8f187ddc49 TinderBox: Win-x86@39, Branch:master, Time: 2015-05-31_03:55:23 Locale: en-CA (en_CA) so I am setting keyword regression. However, contrary to Dave's experience, I see the problem only with native dialogs, not with LibreOffice dialogs. I have not succeeded in finding a duplicate bug report, so setting status NEW.
Heh ; so the gtk+ file picker was never in a separate thread. It does seem however to pretty vigorously grab focus - and indeed appears to inhibit other windows from rendering when it's visible - most unusual =) Of course with a modern compositing WM you tend not to see that happening so easily; but grabbing focus from all other app windows is annoying indeed - but that in itself is no regression; the open dialog was confusingly application-modal in 4.3. None of the commits in vcl/unx/gtk/fpicker look at all suspicious since 4.3 either - so I guess perhaps more of a core gtk+ or RenderContext issue.
Performed bibisect and it can clearly be seen in the 5.0 version. Continued through until bibisect reported: The first bad commit could be any of: 891b689ba95b9e53609194ee2a1a2d3b8955843c 18afb8632caa524fbc70ed5ce3808e23e5dad16f We cannot bisect more!
The range in comment 5 maps to 9e678c14e4fc8e58b1e0530744f648fa3958d338..d05a64df34fd143670cb939b72abfb32d6b714c7 on master, which is the Timer/Idle work Adding Cc: to tobias.madl.dev@gmail.com; Could you possibly take a look at this one? Thanks
If bisected to idle / timer - it's not rendercontext =)
We get the signalExpose we expect with the right (or a plausible) GdkEvent area to re-render, that hits winproc.cxx's ImplHandlePaint - this queues an invalidate - pWindow->ImplInvalidateOverlapFrameRegion which (I assume) never comes back while the dialog is there.
So - paint.cxx ImplPostPaint doesn't start the maPaintIdle - since it is already active (cf. the IsActive() call in there). Heh - the bug is pretty comic. The Idle is added, but unfortunately it never triggers the backend to post the idle event or adjust the timeout. I'll need to add an 'Idle::Start' method to wakeup the backend and get things going. I imagine that most idles only happened to work because there was an existing timeout being processed there that they could piggy-back on - wow.
It looks like the idle backend uses the default Scheduler implementation of: sal_uInt64 Idle::UpdateMinPeriod( sal_uInt64 nMinPeriod, sal_uInt64 nTime ) which looks really unhelpful =) the min. period for any idle should be 0 or 1 depending how you look at things.
This seems like a feature Lubos added: commit 06d731428ef6cf93c7333e8228bfb6088853b52f Author: Luboš Luňák <l.lunak@collabora.com> Date: Sat Jan 31 17:40:48 2015 +0100 make idle timers actually activate only when idle Without this, they can activate after any call to the event processing, so they may activate in cases such as when updating progressbar while loading a document, or on repeated user input (so things like showing spellchecking get updated when the app is busy redrawing). This change makes idle timers activate only when there's nothing more for the event loop to process. It's a bit of a question if this doesn't break something that happens to expect idle timers to be not-really-idle timers, but oh well. I guess - its not an entirely obvious feature, its Linux-only, and now re-rendering is done in an idle handler =) So - I think I'll re-do this to special-case rendering to be allowed in this case.
Fix in: https://gerrit.libreoffice.org/16205 pending a CI build.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=48c2815dd20cf20eeec8bb4e003000f4a3d13291 tdf#91727 - Unwind non-dispatch of idle handlers. It will be available in 5.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.
Queued in gerrit for -5-0 as well. Thanks for the report.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ee1e267f8811285c5d526f9b698897b2043059c&h=libreoffice-5-0 tdf#91727 - Unwind non-dispatch of idle handlers. It will be available in 5.0.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]