http://bugs.winehq.org/show_bug.cgi?id=8634
Gareth <tgheretford(a)fast4.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tgheretford(a)fast4.net
--- Comment #5 from Gareth <tgheretford(a)fast4.net> 2008-03-30 10:22:12 ---
I can confirm this still occurs on Wine 0.9.58, using a Zotac Geforce 8800 GT
AMP! Edition.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=4971
Dan Kegel <dank(a)kegel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|1.0.0 |---
--- Comment #17 from Dan Kegel <dank(a)kegel.com> 2008-03-30 09:55:50 ---
Since this is a trick copy protection question,
we probably won't fix it for 1.0. Removing 1.0 tag.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5807
--- Comment #6 from Anastasius Focht <focht(a)gmx.net> 2008-03-30 08:59:32 ---
Created an attachment (id=11740)
--> (http://bugs.winehq.org/attachment.cgi?id=11740)
patch which supplies correct browser dispatch to completion event handlers
Hello,
another random pick (now from 1.0 buglist *g*).
The app was rechristened "Social·fm Desktop" and is now found at:
http://www.mercora.com/product_desktop.php
The GUI is based on dynamic HTML with the usual browser (shdocvw) event
sequence:
BeforeNavigate2
NavigateComplete2
DocumentComplete
In the app "DocumentComplete" handler, NULL interface pointers are referenced
leading to crash.
Was a bit nasty to debug because the app simultaneously loads two pages (main
gui DHTML view) and a splash like DHTML dialog (login window).
The app uses the "NavigateComplete2" event to setup several internal stuff,
e.g. HTML document dispatch from browser (for IID_IHTMLDocument2) and wire up
the event sinks for DHTML events.
Due to a misconception in shdocvw's navigate_complete() this setup phase is
completely skipped, leading to later NULL references when the app's
"DocumentComplete" handler is executed.
The problem basically boils down to app "NavigateComplete2" handler comparing
the dispatch pointer which is supplied as first argument to the browser
dispatch which was stored when the control was initially created.
On mismatch it immediately bails out of the handler.
--- snip dlls/shdocvw/dochost.c ---
static void navigate_complete(DocHost *This)
{
...
hres = IUnknown_QueryInterface(This->document, &IID_IDispatch,
(void**)&disp);
if(FAILED(hres))
FIXME("Could not get IDispatch interface\n");
dispparams.cArgs = 2;
dispparams.cNamedArgs = 0;
dispparams.rgdispidNamedArgs = NULL;
dispparams.rgvarg = params;
V_VT(params) = (VT_BYREF|VT_VARIANT);
V_BYREF(params) = &url;
V_VT(params+1) = VT_DISPATCH;
V_DISPATCH(params+1) = disp; <--- incorrect dispatch supplied!
V_VT(&url) = VT_BSTR;
V_BSTR(&url) = SysAllocString(This->url);
call_sink(This->cps.wbe2, DISPID_NAVIGATECOMPLETE2, &dispparams);
call_sink(This->cps.wbe2, DISPID_DOCUMENTCOMPLETE, &dispparams);
...
}
HTMLDocument IDispatch given to both sinks results in a vtable pointer mismatch
when the handler compares against WebBrowser2 IDispatch.
Attached patch fixes this.
Now the app "NavigateComplete2" handler fetches and stores additional document
interfaces and wires up the event sinks for DHTML events.
When the "DocumentComplete" handler is called, the elements collection is now
correctly accessed with the interface pointers stored.
Unfortunately the app will crash again at later stage.
--- snip ---
0009:trace:mshtml:HTMLDocument_Release (0x15c7f90) ref = 3
0009:Call oleaut32.VariantClear(0033ed78) ret=0058466e
0009:Ret oleaut32.VariantClear() retval=00000000 ret=0058466e
0009:Call KERNEL32.MultiByteToWideChar(00000003,00000000,0060286e
"",ffffffff,00000000,00000000) ret=00425006
0009:Ret KERNEL32.MultiByteToWideChar() retval=00000001 ret=00425006
0009:trace:mshtml:HTMLDocument_AddRef (0x15c7f90) ref = 4
0009:fixme:mshtml:HTMLDocument_get_Script (0x15c7f90)->(0x33edcc)
0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x4cd8aa
0009:trace:seh:raise_exception info[0]=00000000
0009:trace:seh:raise_exception info[1]=ffffffff
0009:trace:seh:raise_exception eax=0060286e ebx=727798bc ecx=00420000
edx=c10ff0ff esi=00000000 edi=00f19340
0009:trace:seh:raise_exception ebp=00f19330 esp=0033edbc cs=0073 ds=007b
es=007b fs=0033 gs=003b flags=00210206
0009:trace:seh:call_stack_handlers calling handler at 0x5d21f3 code=c0000005
flags=0
--- snip ---
This is due to mshtml insufficiency.
--- snip ---
static HRESULT WINAPI HTMLDocument_get_Script(IHTMLDocument2 *iface, IDispatch
**p)
{
FIXME("(%p)->(%p)\n", iface, p);
return E_NOTIMPL;
}
--- snip ---
The app doesn't check the return value and tries to use the dispatch pointer
directly. *boom*
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=2467
Evgeny <eugenekravchenko(a)hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eugenekravchenko(a)hotmail.com
--- Comment #60 from Evgeny <eugenekravchenko(a)hotmail.com> 2008-03-30 07:04:48 ---
It's still an issue in 0.9.58
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #87 from Andrew Charles Hurst <a.hurst(a)shef.ac.uk> 2008-03-30 04:31:01 ---
Vitaliy,
I'm convinced this (virtual pointer) method should work for fullscreen apps, so
if it were restricted to this case, I think the vast majority of dependent bugs
would be solved.
Having said that, I've applied your 3 patches to GIT, and the pointer doesn't
get warped (although it doesn't deadlock either) in AvP (bug 7613)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #86 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-03-30 00:42:06 ---
(In reply to comment #76)
This bug doesn't the oposit does - they always warp mouse which breaks all
other games (see bug 1410). dinput should not warp mouse period. Native doesn't
do it.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #85 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-03-30 00:38:59 ---
(In reply to comment #80)
> I took a glance into mouse.c. Can anyone tell me where the mouse uses X events?
winex11.drv/mouse.c
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #82 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-03-30 00:35:39 ---
Created an attachment (id=11735)
--> (http://bugs.winehq.org/attachment.cgi?id=11735)
winex11.drv: Use ClipCursor to grab/ungrab the pointer
Here are my old 3 patches that moved mouse warping to winex11drv. However they
weren't accepted. While first two will take care of keeping mouse inside Wine's
windows last one actually does the "magic". However it has a problem - it
deadlocks while waiting for the next mouse event.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.