[Bug 27190] New: Incorrect focus and Alt+Tab order with Delphi MDI application

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

Summary: Incorrect focus and Alt+Tab order with Delphi MDI
                    application
           Product: Wine
           Version: 1.3.19
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: user32
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

1. Make sure to keep running an application (e.g.: text editor or terminal,
preferred non-MDI) that opens a window selectable in Alt+Tab keyboard function
of the window manager (tested on Metacity), used to switch windows on the
desktop environment.

2. Download sample application and run it on wine:

http://www.torry.net/vcl/forms/other/mditab.zip

3. The application shows the main window, which gains focus of the window
manager (Metacity).

4. Select File on main menu, then choose New.

5. A new child window is opened inside main window. Both main and child windows
are focused.

6. When pressing Alt+Tab on keyboard, the first selected window is the child
window of the wine application itself. On MS-Windows the first selected window
would be the one of another application.

7. When pressing Alt+Tab again to return to wine application, only the child
window is focused.

8. With only the child window focused, pressing Alt+Tab again first selects
window of another application as happens on MS-Windows.

Expected behavior: when the Alt+Tab function is used, the first selected window
should be of another application. Also, when focus returns to the MDI
application, both main and child window should be focused, not only child
window. Using other non-Delphi MDI applications (eg: Wine File Manager), when
switching back to it with Alt+Tab, both main and child window are focused, as
happens on MS-Windows.

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

Jarek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

--- Comment #1 from Jarek  2011-06-22 14:45:24 CDT ---
I confirm the issue with EditPad Pro 7. Debian, openbox. And I have yet another
problem I could describe as:

9. Although while Alt is being pressed it seems that the other window will get
focus it finally fails. The other window blink for the moment as active and I
again fall into partially focus Delphi window.

Additional remark:
Editpad pro 6 used some older version of Delphi and its behaviour was then
different. It sometimes had problems with activating the menu because of the
Alt key being depressed, which event should be intercepted by system itself.
This older version presented no wrong point 9 behaviour.

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

--- Comment #2 from Mateus César Gröess  2011-07-02 16:00:54 CDT ---

I have done further investigation of this problem, because is annoying have to
alternate frequently between applications and have a different behaviour for
the Delphi one. Please consider I'm a sysadmin (development is not my job
currently) and a newbie in Windows, Wine and X11 development APIs. A simpler
MDI Delphi application is the attachment 1054 (of bug 1719), posted here:

http://bugs.winehq.org/show_bug.cgi?id=1719#c4

I will use it as reference instead of the sample application linked at
description of this bug.

First, a correction. In point 6, the first window in Alt+Tab list is not the
child MDI window of the application running on wine. Instead it is the special
main application window, used by Delphi applications, not visible but present
in the task bar. The child MDI window is focused after the hidden window is
selected, I guess by some internal focus control, that does not focus also the
entire visible window where that child is. To explain by example, after
started, for the simpler MDI app referenced by this comment, the window manager
will manage two windows, as shown in the output of the "wmctrl -l" command:

0x03a00001  0 localhost Project1
0x03a00003  0 localhost Form1

The user will only see a window titled "Form1", but the button in task bar is
named "Project1". There's no Project1 window, it seems to be zero-sized and
serve only to control operations. The Form1 window is not in task bar because
in its _NET_WM_STATE property is the _NET_WM_STATE_SKIP_TASKBAR flag (a "WM
hint"), as seem using the "xprop -id 0x03a00003" command for the example.
Metacity has a rule that ignores windows with that flag in Alt+Tab list:

https://bugzilla.gnome.org/show_bug.cgi?id=106249

So, because the visible window of the application is not in the list, the
first selected window will be the hidden window of the application itself,
instead one of another app. I have tested the behaviour on MS-Windows XP and
the window listed in Alt+Tab is Form1, not Project1, but Project1 is the one
used in the task bar like happens on Metacity. There's a way to obtain the same
Alt+Tab behavior, by showing the button Form1 in the task bar and hiding
Project1, but needs change of window hints while the application is running,
using these commands in the example:

wmctrl -v -i -r 0x03a00003 -b remove,skip_taskbar
wmctrl -v -i -r 0x03a00001 -b add,skip_taskbar

But hidding the special window as a workaround for Alt+Tab will break some
operations, like no button in task list when minimizing, as seem in wine bug
26670. If only the first command is run, two buttons will appear, but after the
visible window is minimized, it will not reappear in task bar when restored
unless the same command is run again.

I don't know if there's a way to solve this problem. Seems like Metacity
would need to ignore Project1 window in Alt+Tab list, but not in task bar, and
ignore Form1 window just in task bar, but not in Alt+Tab list. The window
manager specifies the list by the following definition in its file
src/core/display.c:

#define IN_TAB_CHAIN(w,t) (((t) == META_TAB_LIST_NORMAL &&
META_WINDOW_IN_NORMAL_TAB_CHAIN (w)) \
    || ((t) == META_TAB_LIST_DOCKS && META_WINDOW_IN_DOCK_TAB_CHAIN (w)) \
    || ((t) == META_TAB_LIST_GROUP && META_WINDOW_IN_GROUP_TAB_CHAIN (w,
get_focussed_group(w->display))))

The macro META_WINDOW_IN_NORMAL_TAB_CHAIN is defined in
src/core/window-private.h, and has the condition, added in the previously
mentioned bug in Gnome bugzilla, to ignore windows not in task bar:

#define META_WINDOW_IN_NORMAL_TAB_CHAIN(w) \
  (((w)->input || (w)->take_focus ) && META_WINDOW_IN_NORMAL_TAB_CHAIN_TYPE (w)
&& (!(w)->skip_taskbar))

Would be possible to specify another Window Type for one of the two windows
used by the Delphi MDI application, that would allow the desired behavior?
Other solution?

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

--- Comment #3 from Jarek  2011-07-03 11:40:13 CDT ---
Mateus, together we're getting closer and closer to it :)
With your simple application and
WINEDEBUG=+message wine Project1.exe
I discovered that set_active_window (dlls/user32/focus.c) is called twice while
it should be called only once.

Here's the output of

CHAR szWnd[200];
GetWindowTextA(hwnd, szWnd, 199);
printf("//BS set_active_window %s %lu (prev %lu, prevAct %lu)\n", szWnd, hwnd,
prev ? *prev : 0, previous);

put at the beginning of set_active_window

Proper behaviour (mouse activation):
//BS set_active_window Form1 853072 (prev 0, prevAct 0)

Bogus behaviour (keyboard activation)
//BS set_active_window Project1 853094 (prev 0, prevAct 0)
//BS set_active_window Form1 853072 (prev 0, prevAct 853094)

When the second activation is executed, kill focus is send to Project1 window
and we're struck :(

And what's interesting even the initial sequence of activation creates ill
state with the main window out of focus. Here's the log:
//BS set_active_window Form1 853072 (prev 0, prevAct 0)
//BS set_active_window Form1 853072 (prev 0, prevAct 853072)
//BS set_active_window Project1 853094 (prev 0, prevAct 853072)
//BS set_active_window Form1 853072 (prev 0, prevAct 853094)

At the moment I'm tired and let up. I'll come to it back later if no one fixes
that.

What I'm afraid of is that it may be hard to correct. I remember Jack having
problems with getting out of visibility when switching windows through Alt-tab.
It was corrected like a year ago. If less windows get activated, some apps may
become invisible again.

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

--- Comment #4 from Jarek  2011-07-03 14:09:27 CDT ---
I forgot to add that I don't know wine. I am a developer but having
insufficient  wine knowledge I probably said a few stupid things.

Nevertheless I made another discovery. When the app is in a bogus state (active
child window, inactive main window), the actual active window is the main
window. I figured it adding another debug output showing the active window. So
the main window (Form1) is actually active (from windows/wine point of view),
but looks like it is inactive. I gather that it is inactive in linux (window
manager) point of view.

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

--- Comment #5 from Jarek  2011-07-03 15:23:19 CDT ---
I have a dumb fix for the issue.

+all reported:

002c:trace:x11drv:update_net_wm_states setting wm state 4 for unmapped window
0xd019c/2000003

Thus editing dlls/winex11.drv/window.c and update_net_wm_states(), commenting
lines:

if (!(ex_style & WS_EX_APPWINDOW) && GetWindow( data->hwnd, GW_OWNER ))
        new_state |= (1 << NET_WM_STATE_SKIP_TASKBAR);

prevents the skip taskbar flag for the Form1 window. So then both windows are
on a task bar.

I don't know why the window is unmapped and how it should work in a smart way.
That would set skiptaskbar on Project1 and not Form1.

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

--- Comment #6 from Jarek  2011-07-04 09:08:21 CDT ---
(In reply to comment #5)
> I have a dumb fix for the issue.

Yes, dumb and being a worse copy of a resolution to bug 26670. I made some
further conslusions there and don't know where the discussion will continue.

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
      Fixed by SHA1|                            |002f85a275c81e0797ffd244942
                   |                            |c938643ececf6
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #7 from Alexandre Julliard  2012-02-01 11:24:54 CST ---
Should be mostly fixed by 002f85a275c81e0797ffd244942c938643ececf6.

[Bug 27190] Incorrect focus and Alt+Tab order with Delphi MDI application

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

Alexandre Julliard  changed:

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

--- Comment #8 from Alexandre Julliard  2012-02-02 13:37:46 CST ---
Closing bugs fixed in 1.4-rc2.