[Bug 9301] New: regression: windows almost never focussed or loose focus

http://bugs.winehq.org/show_bug.cgi?id=9301

Summary: regression: windows almost never focussed or loose focus
           Product: Wine
           Version: 0.9.43.
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wine-x11driver
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

Hi,
since upgrading to 0.9.42 and 0.9.43, I cannot use wine anymore because most
windows don't get focus or immediately loose it when clicking, even winecfg and
regedit. Some apps iconify as soon as I click something. I upgraded from 0.9.38
(so I don't know whether the regression was introduced with 0.39, .40, 41 or
42). 
Although I'm using metacity in Ubuntu Dapper, I believe this bug is different
from bug #5120 as I had been using Ubuntu with wine successfully with 20070725,
0.9.9, 0.9.15 .16, .19 21 ... and many other versions.

Symptoms:
winecfg & regedit start without getting focus.
When I move the cursor from one window to the other, the "window resize" cursor
that was set while moving over the window's border remains set even after I
click to activate the second window.
There are also several refresh problems when moving windows (mostly grey border
lines) in winecfg and regedit.
Every time I activate the wine 800x600 desktop window, all ms-windows apps
become deactivated (some iconify then).

Normally, I have apps\metycity\focus_mode "sloppy" set via the preferences (the
Gnome prefs set "sloppy", not "mouse"). With that, the situation is now so bad
that wine is unusable. E.g. I can activate winecfg only by moving its window.
Then, approx every other click causes the window to loose focus (which causes
other apps to iconify). Every other click does not toggle the boolean
checkboxes in winecfg (because its window is not active).

When I'm not using a wine desktop window, the sudden iconification also
prevents the apps from being usable, as there's no "restore" menu available
(and "maximize" is disabled) in Gnome/metacity.

I have no other window managers installed on this machines to try.

[Bug 9301] regression: windows almost never focussed or loose focus

http://bugs.winehq.org/show_bug.cgi?id=9301

--- Comment #1 from Jörg Höhle   2007-08-13 13:48:57 ---
I've compared effects with 0.9.15.
What's the same:
o When a second window is present (e.g. winecfg + regedit), switching focus
from one to the other works (dark blue window border).
o Refresh problems (remains from borders) when moving these windows around were
present then as well.
o The resize cursor also remains active after changing the focus window.

What's different?
o In .15, winecfg starts without focus (in a 800x600 desktop window), yet
clicks are handled: boolean toggles work (despite no focus!).
o When only a single app remains in .43 (e.g. winecfg, exiting regedit), it
does not automatically get focus.
o When the wine window is focussed, the unique winecfg app therein sometimes
gets focussed, sometimes not. In 0.9.15, winecfg always got focussed.
o Clicking above the winecfg:graphic boolean toggles shows flicker in the
window title area including the right close button (as if erased (unfocused?),
then redrawn) in .43, while the display in .15 remains stable all time.

In summary, .43 obtains best work-around results while two apps are running.

[Bug 9301] windows almost never focussed or loose focus

http://bugs.winehq.org/show_bug.cgi?id=9301

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |regression
            Summary|regression: windows almost  |windows almost never
                   |never focussed or loose     |focussed or loose focus
                   |focus                       |

--- Comment #2 from Vitaliy Margolen   2007-08-13 13:58:49 ---
Are all your tests with virtual desktop or without? This is really important,
because Wine does not and probably won't have full window manager that is
required for the virtual desktop.

Also please do not use such and ancient version as 0.9.15 for comparison
testing. The change you talking about happened in wine-0.9.42.

[Bug 9301] windows almost never focussed or loose focus

http://bugs.winehq.org/show_bug.cgi?id=9301

--- Comment #3 from Jörg Höhle   2007-08-14 03:32:10 ---
An 800x600 wine virtual desktop window inside a larger X screen is what I
constantly use, as that has given me best results over the years, with various
apps.  Otherwise, some (old) apps may cause the X display to flicker, change
resolution (IIRC) or other weirdness; iconification in X produces very strange
results, often enough the app terminates instead of recovering (lacking a
"restore window" functionality). Using a desktop prevents all these graphical
effects: the apps just sit there and know nothing about other resolutions and X
windows. Also, I can iconify the desktop, while some apps (e.g. winecfg) do not
provide an icon button.  All in all, the virtual desktop gives me the best
environment, except when full-screen makes sense (for some games or regedit's
large window).

<feature-request ;>Alas, I cannot set per app full-screen preferences.
Otherwise, I'd let regedit and selected games open full-screen, keeping the
virtual desktop default for most other apps.

I was using .9.15 for comparison because I happen to have it in a separate
directory.  Whereas .38, .36, .31 .28 get overwritten each time I upgrade via
bzcat diffs.bz2 | patch -p1.

BTW, I've never had the winecfg toggle "allow window manager to control
windows" have any observable effect. I typically have it set.

[Bug 9301] windows almost never focussed or loose focus

http://bugs.winehq.org/show_bug.cgi?id=9301

--- Comment #4 from Jörg Höhle   2007-08-14 07:28:21 ---
To me it looks a bit like a race condition somewhere. I've observed different
cases, solely running winecfg and clicking next to the "ok" box.
- winecfg unselected, click, becomes selected
- winecfg selected, click, remains selected (but short flashing of title
screen)
- idem, no visible flashing
- winecfg selected, click, becomes unselected.
The last case is rare after moving the winecfg window inside the virtual
desktop for the first time, but almost 100% when just started.

Here's some WINEDEBUG=trace+event winecfg. The ony difference is fg=20/24.
window selected & remains selected
trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events
trace:event:process_events ClientMessage for hwnd/window 0x10020/3a00007
trace:event:handle_wm_protocols got take focus msg for 0x10020, enabled=1,
visible=1 (style 96000000), focus=0x10020, active=0x10020, fg=0x10024,
last=(nil)
trace:event:set_focus setting foreground window to 0x10020
trace:event:process_events processed 1 events
trace:event:process_events EnterNotify for hwnd/window 0x10024/3600001
trace:event:process_events KeymapNotify for hwnd/window (nil)/0
trace:event:process_events ButtonPress for hwnd/window 0x10024/3600001
trace:event:process_events processed 3 events
trace:event:process_events ButtonRelease for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events
trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events

window unselected, becomes selected via click
trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events
trace:event:process_events ClientMessage for hwnd/window 0x10020/3a00007
trace:event:handle_wm_protocols got take focus msg for 0x10020, enabled=1,
visible=1 (style 96000000), focus=0x10020, active=0x10020, fg=0x10020,
last=(nil)
trace:event:set_focus setting foreground window to 0x10020
trace:event:process_events processed 1 events
trace:event:process_events EnterNotify for hwnd/window 0x10024/3600001
trace:event:process_events KeymapNotify for hwnd/window (nil)/0
trace:event:process_events ButtonPress for hwnd/window 0x10024/3600001
trace:event:process_events processed 3 events
trace:event:process_events ButtonRelease for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events
trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events

unselected, click, remains unselected (right after starting the app)
(Click would then not toggle boolean button).
trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events
trace:event:process_events EnterNotify for hwnd/window 0x10024/3600001
trace:event:process_events KeymapNotify for hwnd/window (nil)/0
trace:event:process_events ButtonPress for hwnd/window 0x10024/3600001
trace:event:process_events processed 3 events
trace:event:process_events ClientMessage for hwnd/window 0x10020/3a00007
trace:event:handle_wm_protocols got take focus msg for 0x10020, enabled=1,
visible=1 (style 96000000), focus=0x10020, active=0x10020, fg=0x10024,
last=(nil)
trace:event:set_focus setting foreground window to 0x10020
trace:event:process_events processed 1 events
trace:event:process_events ButtonRelease for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events
trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001
trace:event:process_events processed 1 events

Note the different order of events in the last case.
All traces where taken with focus_mouse "sloppy".

[Bug 9301] windows almost never focussed or loose focus

http://bugs.winehq.org/show_bug.cgi?id=9301

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #5 from Vitaliy Margolen   2007-08-14 08:16:12 ---
Jörg Höhle, DO NOT PASTE LOGS! If you can't read, here it is again:
Please do not PASTE logs and back traces, (attach them instead).

And I told you, that what you describing is the functionality of the window
manager. Wine does not implement all of it for the virtual desktop.

[Bug 9301] windows almost never focussed or loose focus

http://bugs.winehq.org/show_bug.cgi?id=9301

--- Comment #6 from Jörg Höhle   2007-08-14 11:46:38 ---
Sorry for posting log snippets.

I found out that the order of EnterNotify vs ClientMessage/takefocus depends on
whether the window will be selected at the end:
- EnterNotify then take focus: unselected at end
- take focus, then EnterNotify: selected
> The change you talking about happened in wine-0.9.42.

Confirmed. I changed server/window.c:is_top_level_window() to what it was
before and the iconify & input problems went away (mentioned refresh problems
and winecfg accepting clicks despite not being shown active and remaining
inactive are still there), even with focus_mouse "sloppy".

Regards,
 Jörg Höhle

[Bug 9301] windows almost never focussed or loose focus

http://bugs.winehq.org/show_bug.cgi?id=9301

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Austin English   2008-09-17 08:51:20 ---
Closing WONTFIX.