| | [ Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]
STR #3179
| Application: | FLTK Library |
|---|
| Status: | 4 - Pending |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | X11 |
|---|
| Summary: | Opening a popup dialog while a menu is open hangs X |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | cand |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.4 (SVN: v10550) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post 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 ]
|
| |
