STR #1986: X-server freezes when a window is opened while the menu is open

STR #1986

Application:	FLTK Library
Status:	4 - Pending
Priority:	4 - High, e.g. key functionality not working
Scope:	2 - Specific to an operating system
Subsystem:	X11
Summary:	X-server freezes when a window is opened while the menu is open
Version:	1.4-feature
Created By:	arjenvr
Assigned To:	AlbrechtS
Fix Version:	1.1.10
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Post File

#1	AlbrechtS 15:48 Jul 02, 2009

str_1986.patch
0k

Trouble Report Comments:

Post Text

#1	arjenvr 03:57 Jun 18, 2008

If a new FLTK window is opened while a menu is opened, FLTK causes the X server to hang until the application is killed. The code below reproduces the problem. Run it and open the menu. After a few seconds fl_message is called from the idle callback and the application and X-server freeze. Tested on Fedora Core 6 x32, gcc 4.1.2. Not tested under windows. #include <FL/Fl.H> #include <FL/Fl_Window.H> #include <FL/Fl_Menu_Bar.H> #include <FL/Fl_Menu_Button.H> #include <FL/fl_ask.H> #include <stdio.h> #include <stdlib.h> #include <unistd.h> void quit_cb(Fl_Widget*, void*) {exit(0);} Fl_Menu_Item menutable[] = { {"&File",0,0,0,FL_SUBMENU}, {"&Open", FL_ALT+'o', 0, 0, FL_MENU_INACTIVE}, {"&Close", 0, 0}, {"&Quit", FL_ALT+'q', quit_cb, 0, FL_MENU_DIVIDER}, {0}, {0} }; void IdleCallback(void* pData) { usleep(5000); static int cnt = 0; if (++cnt > 1000) { fl_message("Hello bug!"); cnt = 0; } } int main(int argc, char **argv) { Fl_Window window(600,400); Fl_Menu_Bar menubar(0,0,600,30); menubar.menu(menutable); window.end(); window.show(argc, argv); Fl::add_idle(IdleCallback, &window); return Fl::run(); }

#2	wavexx 05:37 Aug 11, 2008

Reproduced successfully with debian sid/ion3. This is another case of recursive event handling, combined with grab() issues (which still seems to have some effect). Note that X is _not_ frozen, is being locked via grab() on the menu, while event handling is currently processing another window (fl_ask's innards). Pressing space unlocks the app. This can't be fixed in 1.1.x, but please repost/merge with: 1747 Fl::grab() behavior changed on newer platforms Core Library Pending HIGH 1869 avoid recursing event handlers (Fl::readqueue, Fl::check) New HIGH 1873 more fl_ask issues

#3	matt 13:09 Dec 30, 2008

Yes,I am seeing it in FC5 as well. My suggestion is to close any popup menu whenever the event loop gets called from anywhere outside of the menu handling code. This will solve this one particular case, but not the egenral problem fo Fl::grab() vs. recursive event handling.

#4	AlbrechtS 16:09 Jul 02, 2009

wavexx wrote: "Note that X is _not_ frozen, is being locked via grab() on the menu, while event handling is currently processing another window (fl_ask's innards)." In the current svn version (r 6817), the following is done in fl_ask.cxx/innards(): message_form->show(); // deactivate Fl::grab(), because it is incompatible with Fl::readqueue() Fl_Window* g = Fl::grab(); if (g) // do an alternative grab to avoid floating menus, if possible Fl::grab(message_form); I think that this is the culprit, and I uploaded a patch file, see http://www.fltk.org/strfiles/1986/str_1986.patch . The correct part is that the existing grab(), if any, is terminated, but IMHO we must not do Fl::grab(message_form). On Windows this doesn't do much harm, but on Linux it is responsible for the described effect. When doing grab() with an open menu, a mouse click outside the menu dismisses it. That's okay. But here it is a grab() for an open fl_ask window, and this one simply ignores the click :-( This was introduced in svn -r 6035 (not 6034) as a fix for STR #1869. Having "floating menus" is IMHO a much minor issue than this "locking" experience under Linux. BTW.: Matt, did you mean that one can drag a window away from its open menu? Please test and confirm, I'd like to close the STR with the proposed fix. Maybe we can find an even better solution for 1.3, but this would need some redesign that can't be done for 1.1.

#5	matt 03:03 Sep 13, 2009

Looks OK to me for 1.1 and 1.3

#6	AlbrechtS 06:04 Sep 13, 2009

I think that we should apply the patch as an intermediate solution, and I'll do this later today or tomorrow. I've been working on a better solution that addresses more issues (see post #2 to this STR of wavexx), but this is not yet ready. I'm not sure if this can make it into 1.1.10, although there will probably be no ABI problems. I have a working prof of concept, but this needs to be integrated into the Fl_Menu code, and this is maybe too big a change for FLTK 1.1. I'll try to work soon on the patch for FLTK 1.3 though, and then we can decide if we can do it in 1.1 as well.

#7	matt 06:17 Sep 13, 2009

OK with me

#8	AlbrechtS 15:11 Sep 13, 2009

I applied the proposed fix as an intermediate solution. This fixes the lock problem, but a better fix would dismiss the menu, if the mouse is clicked elsewhere, while the modal window is open. I'm working on the final fix, but it is not yet ready, and it is not yet decided, if this will go into FLTK 1.1.10. The intermediate fix has been applied to: FLTK 1.3: svn -r 6869 FLTK 1.1: svn -r 6870 Leaving this STR open, until either the final fix will be applied, or we will decide to release 1.1.10 w/o it.

#9	matt 12:46 Feb 19, 2010

We may fix this later. The current solution has not caused any new issues.

#10	ianmacarthur 01:40 Jul 20, 2011

NOTE: This bug was tied to an apparently similar bug (#2490) on fltk-1.1.10. That other bug has recently been closed as "no fault found", it appears that in that case the bug was specific to a WM, rather than a bug in fltk. So, this bug (#1986) is probably unrelated to #2490 after all, as it turns out...

#11	AlbrechtS 10:06 Feb 02, 2015

See also related STR's #1869 and #3179. http://www.fltk.org/str.php?L3179 http://www.fltk.org/str.php?L1869