[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #3179

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  cand 11:42 Jan 25, 2015	hang.cxx 1k
	#2  AlbrechtS 08:06 Jan 26, 2015	disable_grab.patch 1k
	#3  AlbrechtS 03:37 Jan 31, 2015	disable_grab_v2.patch 2k
	#4  cand 12:03 Jan 31, 2015	over.png 12k

Trouble Report Comments:

	Name/Time/Date	Text
	#1  cand 11:42 Jan 25, 2015	If a menu is open while a popup dialog, such as a file chooser, is popped up, X gets its panties in a twist and nothing accepts input. I suspect this is a matter of competing grabs. The attached program demonstrates this: open the menu within one second. When this hang hits, the mouse cursor still moves, but nothing accepts clicks nor keyboard input. The X server is still fine, you can switch to a VT, kill the offending app, and everything is fine again. Confirmed in today's svn (10534).
	#2  AlbrechtS 08:06 Jan 26, 2015	This is another variant of STR #1869 and STR #1986. Sigh... :-(. http://www.fltk.org/str.php?L1869 http://www.fltk.org/str.php?L1986 These STR's have been fixed (partially) in a way that avoids the hang, but not in a general (optimal) way. The optimal solution would probably need some changes in the way menus are handled. Note that the fixes discussed in these patches are partially obsolete because the code in fl_ask etc. has changed significantly meanwhile. Anyway, the attached patch file should fix the issue. Please test "disable_grab.patch" and report if it solves the issue or whatever observations you make about any (mis-)behavior. Did you notice other popup dialogs with the same issue? There may well be some, but fl_ask and friends should not show this behavior any more.
	#3  cand 01:00 Jan 27, 2015	Yes, this patch fixes the hang. A downside is that the menu is shown on top of the dialog, meaning you have to move the dialog to be able to click in that area. This was the only dialog that hit me. I had a menu open in Fifth while a site popped up a file download dialog. Good thing Fifth has recovery support, if it dies because of a crash (killall -SEGV etc) it will restore all tabs ;)
	#4  cand 10:48 Jan 30, 2015	Should I commit this, or?
	#5  AlbrechtS 03:12 Jan 31, 2015	No, thanks, I'm going to do it... One more question though: I can't confirm that the dialog window opens under the menu with my Ubuntu system (in a Virtualbox VM). Which platform are you using? Which WM etc.?
	#6  AlbrechtS 03:37 Jan 31, 2015	Please try the new file disable_grab_v2.patch. I found there was the same issue with fl_dir_chooser(), although I didn't test it explicitly. The new patch uses a static function popup(). I believe that we can commit this, if your tests are positive. This seems to be a step forward and the best we can do w/o further changes in the menu system.
	#7  cand 12:03 Jan 31, 2015	Yes, both file and dir choosers work fine with the v2 patch. The WM is JWM, on TC. Attaching screenshot.
	#8  AlbrechtS 10:02 Feb 02, 2015	Fixed in Subversion repository. The current fix in svn r 10550 appears to be the best available for now w/o more investigation and maybe changing menu handling significantly. The committed fix resolves the current issue, but leaves the "dialog underneath menu" problem open - which seems to happen only for some OS's and/or window managers. Lowered priority to 2 (Low), and status to 4 (Pending). Set "Fix Version" to 1.3.4. Set "Software Version" to 1.4-feature for later investigation. Please see also related STR's #1869 and #1986 (direct links in comment #2).

[ Return to Bugs & Features | Post Text | Post File ]