https://bugs.documentfoundation.org/show_bug.cgi?id=94069
Donald Buczek <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Donald Buczek <[email protected]> --- Created attachment 119142 --> https://bugs.documentfoundation.org/attachment.cgi?id=119142&action=edit 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 [...] -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
