Hello,
I am working on a problem with IE where if you start the application in full screen mode:
(start IE, change to full screen using view->full screen, shutdown IE, restart IE)
the keyboard focus never gets given to the application so you cannot enter any information into forms.
Looking into this i found that we where never being given any ClientMessage events to take focus nor any FocusIn events. So the keyboard focus remains on whatever app last had it, such as the terminal used to start IE.
A very simple, shotgun, way to solve this is this attached patch. Thinking about windows architecture i was trying to think of a time where a window would receive a button click and would not be given input focus (yes the app may modify focus but it would do that anyway)
However this change is HUGE and will affect alot and wanted to bounce it off people before continuing to investigate it.
This look ok to people? Other ideas on proper ways to deal with this issue?
thanks -aric
Index: dlls/x11drv/event.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/event.c,v retrieving revision 1.30 diff -u -w -r1.30 event.c --- dlls/x11drv/event.c 5 Dec 2003 04:45:50 -0000 1.30 +++ dlls/x11drv/event.c 16 Dec 2003 19:02:57 -0000 @@ -287,6 +287,14 @@ break;
case ButtonPress: + /* + * I am sort of unsure about this however + * there should not be a case where the button is clicked somewhere + * and windows does not assume focus is sent there. + * + * it also fixes a bunch of input problems for forms in IE + */ + set_focus(hWnd,CurrentTime); X11DRV_ButtonPress( hWnd, (XButtonEvent*)event ); break;
"Aric Stewart" aric@codeweavers.com wrote:
I am working on a problem with IE where if you start the application in full screen mode:
(start IE, change to full screen using view->full screen, shutdown IE, restart IE)
the keyboard focus never gets given to the application so you cannot enter any information into forms.
Looking into this i found that we where never being given any ClientMessage events to take focus nor any FocusIn events. So the keyboard focus remains on whatever app last had it, such as the terminal used to start IE.
That sounds like a bug either in Window Manager you are using or in x11drv code not properly initializing XSetWindowAttributes.event_mask (FocusChangeMask). You need further investigate what happens.
On Wed, 2003-12-17 at 03:15, Dmitry Timoshkov wrote:
That sounds like a bug either in Window Manager you are using or in x11drv code not properly initializing XSetWindowAttributes.event_mask (FocusChangeMask). You need further investigate what happens.
Isn't this the same bug that kills us in gaming, ie we create unmanaged windows for fullscreen and X finds it hard to handle? If so then real fix would seem to be making fullscreen windows managed (there is a NETWM protocol for fullscreening something which works very well, but unfortunately win32 has no equivalent so I guess we'd have to go by screen co-ords or something equally hackish).
Yes i do believe this is the same bug.
humm, i will investigate more about full screen windows and X although i am no expert with the x level windows in wine.
-aric
Mike Hearn wrote:
On Wed, 2003-12-17 at 03:15, Dmitry Timoshkov wrote:
That sounds like a bug either in Window Manager you are using or in x11drv code not properly initializing XSetWindowAttributes.event_mask (FocusChangeMask). You need further investigate what happens.
Isn't this the same bug that kills us in gaming, ie we create unmanaged windows for fullscreen and X finds it hard to handle? If so then real fix would seem to be making fullscreen windows managed (there is a NETWM protocol for fullscreening something which works very well, but unfortunately win32 has no equivalent so I guess we'd have to go by screen co-ords or something equally hackish).
"Mike Hearn" mike@theoretic.com wrote:
Isn't this the same bug that kills us in gaming, ie we create unmanaged windows for fullscreen and X finds it hard to handle?
It must be the same bug, if the full screen window was really created as a not managed one. Aric, could you confirm that?
If so then real fix would seem to be making fullscreen windows managed (there is a NETWM protocol for fullscreening something which works very well, but unfortunately win32 has no equivalent so I guess we'd have to go by screen co-ords or something equally hackish).
Yes, probably that's a way to go.