Open sillysloft opened 14 years ago
Running your browser with GDK_NATIVE_WINDOWS=1 should fix this issue. I'll still get some changes into fluxbox eventually so this isn't necessary (and eventually flash should fix their gtk code), but this should work for now.
Original comment by: mark-t
Oh, I meant the other bug. Well, you try this too. 8)
Original comment by: mark-t
probably bug #1000 as well (passive grab on active windows)
Original comment by: baghira-style
Similar (though distinct) to https://sourceforge.net/tracker/?func=detail&aid=2885327&group\_id=35398&atid=413960 I am unable to click Flash dialogues, such as this: http://imgur.com/aUgz9.png
This issue seems to be entirely WM-dependent. For example, Xfwm, Kwin and Metacity don't have this issue, while Blackbox, Fluxbox and jwm do. For what it's worth, Openbox does not have this issue, so it may be a long-standing issue in Blackbox that Fluxbox has inherited - I'm not sure how much Blackbox code is still in Fluxbox.
The bug is as such: When a settings dialogue is opened either voluntarily, or by an application exceeding its local storage quota, requesting access to a webcam or microphone, etc., it is displayed on top of the Flash object. The Flash object's controls become unclickable, which is normal, however, the settings dialogue is focused improperly and cannot be dismissed without reloading the object.
While the other bug I linked to was triggered by upgrading to gtk2 2.18.2 (and still present in 2.18.3), this issue is longer-standing. I have had this issue for months, if not years, across several major xorg-server versions, with gtk2 2.16.5 and earlier. The simplest workaround for the other bug, opening a Flash context menu and then double-clicking on the controls, does not work for this issue.
Tested on Arch Linux with Fluxbox 1.1.1 and Git (commit 8def80cec337a986b762cdbb5e2555c6da809353) under Xorg-server 1.6.3 and 1.7.1 with Flash 10.0.32.18. The issue persists with multiple browsers of multiple toolkits and rendering engines (Firefox, Midori, Arora, Uzbl).
Reported by: *anonymous