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

STR #1986

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  AlbrechtS 15:48 Jul 02, 2009	str_1986.patch 0k

Trouble Report Comments:

	Name/Time/Date	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

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