STR #1986

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

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 ]
Name/Time/Date Filename/Size top right image
 
#1 AlbrechtS
15:48 Jul 02, 2009
str_1986.patch
0k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#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
 
bottom left image   bottom right image

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

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.