Bug Hunting Session
Bug 94069 - EDITING: Moving a tablecontrol while editing a form leads to a hang
Summary: EDITING: Moving a tablecontrol while editing a form leads to a hang
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.0.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: highest major
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.1.0 target:5.0.4 target:5.2.0
Keywords: bibisectRequest, patch, regression
: 95112 96501 97076 (view as bug list)
Depends on:
Blocks: 96500 96482
  Show dependency treegraph
 
Reported: 2015-09-09 18:41 UTC by Robert Großkopf
Modified: 2016-10-25 19:11 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Open form for editing - move tablecontrol ... (10.69 KB, application/vnd.oasis.opendocument.database)
2015-09-09 18:41 UTC, Robert Großkopf
Details
patch for libreoffice-5.0.2.2 which prevents this bug (877 bytes, patch)
2015-09-30 16:29 UTC, Donald Buczek
Details
stash this here while I play with some other aspects (1.11 KB, patch)
2015-11-10 20:38 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2015-09-09 18:41:48 UTC
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.
Comment 1 Jean-Baptiste Faure 2015-09-10 07:17:36 UTC
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
Comment 2 Olivier 2015-09-19 10:14:46 UTC
The program hang, and mouse control doesn't work, I have to use keyboard to exit and select close button with tabulation.
Comment 3 Marius Tolzmann 2015-09-24 19:59:03 UTC
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..
Comment 4 Donald Buczek 2015-09-30 16:29:26 UTC
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
[...]
Comment 5 Alex Thurgood 2015-10-18 16:20:46 UTC
*** Bug 95112 has been marked as a duplicate of this bug. ***
Comment 6 Alex Thurgood 2015-10-19 15:22:50 UTC
@Lionel: I see that you wern't yet on CC for this bug, but does the patch provided by Donald look sane ?
Comment 7 Lionel Elie Mamane 2015-10-19 16:36:19 UTC
(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?
Comment 8 Alex Kempshall 2015-10-28 10:05:25 UTC
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.
Comment 9 Caolán McNamara 2015-11-09 20:44:28 UTC
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.
Comment 10 Caolán McNamara 2015-11-10 10:17:47 UTC
There seems to be a separate rendering issue of bug 95723 in addition
Comment 11 Caolán McNamara 2015-11-10 20:38:12 UTC
Created attachment 120466 [details]
stash this here while I play with some other aspects
Comment 12 Commit Notification 2015-11-11 10:55:40 UTC
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.
Comment 13 Alex Kempshall 2015-11-12 08:00:27 UTC
Done a git pull, compiled and tested on Master.

Looks good to me.
Comment 14 Robert Großkopf 2015-11-14 09:31:17 UTC
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 ...
Comment 15 Donald Buczek 2015-11-14 15:55:16 UTC
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.
Comment 16 Commit Notification 2015-11-15 10:50:39 UTC
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.
Comment 17 Alex Thurgood 2015-12-14 18:01:20 UTC
Fix works for me in master 5.2 alpha OSX 10.11.1
Comment 18 Alex Thurgood 2015-12-15 09:07:00 UTC
*** Bug 96501 has been marked as a duplicate of this bug. ***
Comment 19 Robinson Tryon (qubit) 2015-12-17 10:32:39 UTC Comment hidden (obsolete)
Comment 20 Commit Notification 2015-12-17 15:19:28 UTC
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.
Comment 21 Commit Notification 2016-01-11 13:09:11 UTC
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.
Comment 22 Alex Thurgood 2016-01-12 17:25:11 UTC
*** Bug 97076 has been marked as a duplicate of this bug. ***
Comment 23 tim 2016-01-23 17:49:00 UTC
Works for me - ubuntu 14.04 64 bit LO 5.1.0.2.

Many thanks.