Created attachment 118555 [details] Open form for editing - move tablecontrol ... Open the attached database. Open the form for editing. Try to move the tablecontrol of the form. The tablecontrol couldn't be moved, flickers and the whole desktop hangs. Works right with LO 4.4.*, fails with LO 5.0.1.2, OpenSUSE 13.2, 64bit rpm Linux.
Reproducible with Version: 5.0.3.0.0+ Build ID: 651205cdf64d3fce6685a58587c8ec4626278779 Ubuntu_15.04_x86-64 Locale : fr-FR (fr_FR.UTF-8) Best regards. JBF
The program hang, and mouse control doesn't work, I have to use keyboard to exit and select close button with tabulation.
We can confirm this issue on linux x86_64 with a different database. Tested versions of libreoffice are 5.0.1 and 5.0.2; both built from source releases. perf top showed some high activity in "libmergedlo.so" while the mouse control was gone (as far as i can remember atm). Did not have the time to investigate further yet. sorry. best regards, marius..
Created attachment 119142 [details] patch for libreoffice-5.0.2.2 which prevents this bug The problem is, that the application stops to response to X events (mouse move, button release) while it has a mouse grab. The reason is, that the main loop of the application effectively alternates between repainting the moving window and a single glib main iteration ("input event") via g_main_context_iteration(). The single glib input event processed in each round is apparently not the one needed to deliver the user input to the application, so the drag stalls. There may be other glib input sources involved. Maybe the redraw of the complex window just takes to long and some higher priority timer sources get in the way? Or does the repaint generate input events itself? I don't know, but the patch, which is more a proof of theory than the "right" solution to this problem, fixed it for me. For further analysis: The call frames for the two events (repainting the window and processing a single glib input event are _replaint_ [...] vcl::Window::ImplCallPaint(vcl::Region const*, unsigned short) (this=0x2a75180, pRegion=0x0, nPaintFlags=8) at /dev/shm/buczek/libreoffice/test2/vcl/source/window/paint.cxx:611 vcl::Window::ImplCallOverlapPaint() (this=0x2a75180) at /dev/shm/buczek/libreoffice/test2/vcl/source/window/paint.cxx:631 vcl::Window::ImplHandlePaintHdl(Idle*) (this=0x2a75180) at /dev/shm/buczek/libreoffice/test2/vcl/source/window/paint.cxx:661 vcl::Window::LinkStubImplHandlePaintHdl(void*, Idle*) (instance=0x2a75180, data=0x2b16df0) at /dev/shm/buczek/libreoffice/test2/vcl/sourc e/window/paint.cxx:641 Link<Idle*, void>::Call(Idle*) const (this=0x2b16e10, data=0x2b16df0) at /dev/shm/buczek/libreoffice/test2/include/tools/link.hxx:127 Idle::Invoke() (this=0x2b16df0) at /dev/shm/buczek/libreoffice/test2/vcl/source/app/idle.cxx:26 ImplSchedulerData::Invoke() (this=0x2e839b0) at /dev/shm/buczek/libreoffice/test2/vcl/source/app/scheduler.cxx:38 Scheduler::ProcessTaskScheduling(bool) (bTimer=false) at /dev/shm/buczek/libreoffice/test2/vcl/source/app/scheduler.cxx:127 ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at /dev/shm/buczek/libreoffice/test2/vcl/source/app/svapp.cxx:346 Application::Yield() () at /dev/shm/buczek/libreoffice/test2/vcl/source/app/svapp.cxx:382 Application::Execute() () at /dev/shm/buczek/libreoffice/test2/vcl/source/app/svapp.cxx:336 [...] _event_ [...] GtkData::Yield(bool, bool) (this=0x623570, bWait=true, bHandleAllCurrentEvents=false) at /dev/shm/buczek/libreoffice/test2/vcl/unx/gtk/app/gtkdata.cxx:597 GtkInstance::Yield(bool, bool) (this=0x623420, bWait=true, bHandleAllCurrentEvents=false) at /dev/shm/buczek/libreoffice/test2/vcl/unx/gtk/app/gtkinst.cxx:407 ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at /dev/shm/buczek/libreoffice/test2/vcl/source/app/svapp.cxx:353 Application::Yield() () at /dev/shm/buczek/libreoffice/test2/vcl/source/app/svapp.cxx:382 Application::Execute() () at /dev/shm/buczek/libreoffice/test2/vcl/source/app/svapp.cxx:336 [...]
*** Bug 95112 has been marked as a duplicate of this bug. ***
@Lionel: I see that you wern't yet on CC for this bug, but does the patch provided by Donald look sane ?
(In reply to Alex Thurgood from comment #6) > @Lionel: I see that you wern't yet on CC for this bug, but does the patch > provided by Donald look sane ? Don't know, this is not database-code, but VCL code. Caolán? You have an opinion on this? Maybe the right fix is to set bHandleAllCurrentEvents to true rather than changing the value for the case bHandleAllCurrentEvents == false?
I've tested the patch, supplied by Donald Buczek, in master and it works for me. Reading the other comments their seems to be a discussion as to whether the patch looks sane. In the short term is it possible to apply the patch to master and then wait until something "saner" turns up. At the moment we're frightening people with a locked desktop. btw the work around is to use the Size & Position dialog instead of dragging.
I think, comparing against a button control which works, that the vcl window associated with the element should be toggled to "hidden" when in design mode. Doing that would suppress the invalidate etc events that are generated when its moved by the user fighting with the user movement events themselves.
There seems to be a separate rendering issue of bug 95723 in addition
Created attachment 120466 [details] stash this here while I play with some other aspects
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a7816853bad55ada597092c16ba9a0a761e067d0 Resolves: tdf#94069 call setVisible when setDesignMode is called 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.
Done a git pull, compiled and tested on Master. Looks good to me.
Seems it is working now. One note: At the same time colored table-borders are visible again in a form - but only while editing the form (Bug 95150). Don't think it has anything to do with this bug ...
The master currently doesn't compile in our environment, but I've put the patch on top of libreoffice-5.0.2.2 and can confirm that it fixes the problem for us as well.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a08a5ff76b78f828367467a0a1610d2f7e63ad75&h=libreoffice-5-0 Resolves: tdf#94069 call setVisible when setDesignMode is called It will be available in 5.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.
Fix works for me in master 5.2 alpha OSX 10.11.1
*** Bug 96501 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=57b1cf5862429d86a82158eb5e8cf425fd2f4527 tdf#96482 Revert "Resolves: tdf#94069 call setVisible when setDesignMode is called" 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.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3408d37aed9d494e1401417a9344012a54ebdfd8&h=libreoffice-5-1 tdf#96482 Revert "tdf#94069 call setVisible when setDesignMode is called" It will be available in 5.1.0.2. 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.
*** Bug 97076 has been marked as a duplicate of this bug. ***
Works for me - ubuntu 14.04 64 bit LO 5.1.0.2. Many thanks.