Alt-Drag triggers Alt menu in Firefox and Wine apps #9
Comments
|
Another Firefox observation: I clicked on the initial default Google search box to display a blinking caret. With xfwm4, when I use Alt-drag to move/resize Firefox, its window remains focused according to its title bar, but the caret stops blinking. With blackbox, the caret remains blinking. |
|
I tested by Alt-moving an blackbox: xfwm4: It's also interesting to me that xfwm4 generates |
|
First off: I hate Firefox because it breaks so many client focus rules. It often steals focus. I find that Chromium behaves way better. That said, blackbox focus handling is not the best. Most WMs properly intercept the Alt-mouse at the frame, grab the pointer, and do not allow the event to propagate to the client inside the frame. Is looks like blackbox is allowing the mouse click event to pass to the client in some cases, or maybe is not grabbing the pointer with the correct attributes. As for the ConfigureNotify events, ICCCM 2.0 only requires the WM to generate a synthetic ConfigureNotify event to the client when the window changes in size (and not when the window only moves). Looking at the ConfigureNotify events that xfwm4 generates (synthetic YES), they only indicate that the window moved and not that it has resized and are, therefore, unnecessary from an interaction viewpoint. When coding synthetic notifies, bad things happen when you miss one (the frame resizes but the client window inside does not), so from a coding perspective it is better to err on the side of sending too many synthetic configure notifies than to miss sending one that resizes the window. |
I didn't see ButtonPress/ButtonRelease events in the testing I did, but maybe they are getting through? The trouble is the KeyPress/KeyRelease events for Alt. It would be intrusive to suppress the Alt KeyPress event, because it can happen long before the mouse is pressed. It probably wouldn't work to suppress the Alt KeyRelease if the KeyPress is delivered to the app. (I'd guess the imbalance would break at least something?) I have focus-follows-mouse enabled, so I can test Firefox by pressing Alt down, then briefly switching focus away and back to Firefox, then releasing Alt. The focus switching prevents the menu from activating. I tested Openbox and Metacity with xev, and alt-dragging generates the same FocusOut/FocusIn events as xfwm4. Alt-dragging does not activate the Firefox menu. The convention is that FocusOut is generated once the move/resize operation starts (typically at mouse-down or soon after), and FocusIn is generated on mouse-up. The WMs generate the same FocusOut/FocusIn events even when I move/resize the window using the window frame (i.e. without using Alt). |
bbidulock
added
the
enhancement
When I use Alt-mouse to move/resize a window with Blackbox, the menu activates in certain applications. For example, with Firefox, the menu is normally invisible. Pressing Alt shows the menu and transfers keyboard focus to it. The problem also affects Wine (e.g. Notepad), because Alt transfers focus to the menu in Windows.
Ideally, pressing Alt would not activate the menu.
Somehow, xfwm4 avoids this problem, but I'm not sure how. Maybe it's got something to do with window focus. The Alt-Tab switching in bbkeys also avoids the problem.
(Aside: The problem is much worse in Windows. The solution that altdrag uses is to generate a fake Ctrl keypress (e.g. AltDown -> dragging -> CtrlDown -> CtrlUp -> AltUp), but I didn't see any Ctrl keypresses with
xev.Edit: I'm using commit 8c9e2af, Blackbox 0.72.
The text was updated successfully, but these errors were encountered: