http://bugs.winehq.org/show_bug.cgi?id=30421
Bug #: 30421 Summary: obscure GDI Message Queue + Focus bug Product: Wine Version: 1.3.37 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: lkcl@lkcl.net Classification: Unclassified
ok, this is a rather obscure bug that i've been experiencing for quite some time, but hadn't got a handle on any of the functions being used, so couldn't really provide a useful report. as i am now running pyjamas-desktop which uses python ctypes bindings to gdi32 (!!) i can now provide useful feedback.
please see the following file, the GetMessage loop towards the end: http://pyjs.org/pygit/#file=pyjd/mshtml.py&id=0d4b6787d01c3d90f2c8801c5c...
basically, the repro is as follows:
* run wine python.exe Hello.py (an example) * move the mouse out of the GDI32 (IWebBrowser2 OLE control) window * move the mouse into the xterm where wine was fired up * press ctrl-c
now, _normally_, under xp, nothing happens... and nothing _should_ happen... ever. ctrl-c should be *completely* ignored. but, continue:
* move the mouse _back_ into the GDI32 window * the program exits
the exit should *not* be happening when the mouse is moved back.
which brings me on to the various experiences that i've had with focus issues, especially dialog boxes. maybe this is because i'm using fvwm2, but the behaviour of focus on dialog boxes and especially inputboxes within dialog boxes is _very_ erratic. the mouse is needed to be moved into the parent window in order sometimes for keyboard focus to arrive on the inputbox within the dialog box! sometimes that doesn't work, and the mouse is required to be moved onto the bar at the top of the parent window (the one with the title - the x-windows / fvwm window bar!)
all very odd, and probably a different bug, but hey :)
http://bugs.winehq.org/show_bug.cgi?id=30421
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2012-04-12 13:44:56 CDT --- fvwm doesn't always properly assign focus on take focus. File a bug there.
http://bugs.winehq.org/show_bug.cgi?id=30421
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |UPSTREAM
--- Comment #2 from Austin English austinenglish@gmail.com 2012-04-12 17:39:19 CDT --- (In reply to comment #1)
fvwm doesn't always properly assign focus on take focus. File a bug there.
Then it's UPSTREAM.
https://bugs.winehq.org/show_bug.cgi?id=30421
Luke Kenneth Casson Leighton lkcl@lkcl.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|UPSTREAM |---
--- Comment #3 from Luke Kenneth Casson Leighton lkcl@lkcl.net --- ok: i spoke to upstream. they informed me that they are getting rather tired of having to inform the wine developers that the issue is in fact in wine (ignoring certain window manager hints) so they have stopped bothering.
let us try one more time, then we will not bother either.
* there is a bug.
* it is in wine.
* wine is not properly handling window manager hints for focus events.
* there is an unusual feature of X11 involving window focus events.
* fvwm is one of the few window managers that uses this feature of X11.
* the fvwm developers have been forced to advise users of fvwm that because the wine developers refuse to deal with the problem, the users are forced to add in a "workaround" into the fvwm config file.
* it is such a common problem because the wine developers refuse to acknowledge the problem that there is even an FAQ entry for it:
http://www.fvwm.org/documentation/faq/#6.10
is this clear enough?
if any part of this is unclear please do advise and we can provide further information.
https://bugs.winehq.org/show_bug.cgi?id=30421
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Luke Kenneth Casson Leighton from comment #3)
it is such a common problem because the wine developers refuse to acknowledge the problem that there is even an FAQ entry for it:
is this clear enough?
That FAQ entry is completely missing any technical information: what hints they are talking about and what exactly Wine is doing wrong.
https://bugs.winehq.org/show_bug.cgi?id=30421
--- Comment #5 from Luke Kenneth Casson Leighton lkcl@lkcl.net --- dmitri, thanks for responding. i'll have to ask the fvwm developers and get back to you, because they are more familiar with the issue (i am just an end-user with a clear repro case and a description of a long-standing known problem).
https://bugs.winehq.org/show_bug.cgi?id=30421
--- Comment #6 from Luke Kenneth Casson Leighton lkcl@lkcl.net --- If Lenience fixes the problem, the window is not indicating that it accepts input.
Here's the section of the Fvwm man page:
The ICCCM states that windows possessing the property
WM_HINTS(WM_HINTS): Client accepts input or input focus: False
should not be given the keyboard input focus by the window manager. These windows can take the input focus by themselves, however. A number of applications set this property, and yet expect the window manager to give them the keyboard focus anyway, so fvwm provides a window style, Lenience, which allows fvwm to overlook this ICCCM rule. Even with this window style it is not guaranteed that the application accepts focus.
also there is this:
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2013-01-02 05:54:18 CST --- Setting the input hint to False is correct, along with WM_TAKE_FOCUS it specifies that we use the Globally Active model. Whatever the bug may be, that's not it.
Does fvwm send the WM_TAKE_FOCUS client message as described in http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7?
that's what i have in my inbox when this was last raised.
basically i think the two teams should get in touch and sort this out, it's no good end-users being in the middle and being forced to a) edit window manager config files as workarounds b) play the "let's raise a bugreport and have it closed by the wine team yet again" game.
https://bugs.winehq.org/show_bug.cgi?id=30421
--- Comment #7 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine?
https://bugs.winehq.org/show_bug.cgi?id=30421
--- Comment #8 from Luke Kenneth Casson Leighton lkcl@lkcl.net --- hi austin, the entry is still in the fvwm2 FAQ http://www.fvwm.org/documentation/faq/#6.10 so i'd say it was safe to say that yes, the bug of the interaction between wine and fvwm2 is still present.
as someone who is on the outside of this bug as an end-user, it appears to be a misunderstanding of the window manager / x11 standard, between the wine and the fvwm2 teams. the last entry on this bug report was a recommendation that the wine developers get in touch with the fvwm2 developers to properly resolve this issue, and, logically, if that doesn't happen then, it's safe to say that the bug will not only remain, but that other people will continue to raise duplicates until it's resolved.
https://bugs.winehq.org/show_bug.cgi?id=30421
Carlo B castro8583bennett@gmx.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |castro8583bennett@gmx.com
--- Comment #9 from Carlo B castro8583bennett@gmx.com --- It's good to see that folks at wine and fvwm2 cooperate so well for community ;) ,https://promokodi.com.ua/
-
wine-bugs＠winehq.org