[Bug 18531] New: FontValidator (.NET based app) needs OleInPlaceObject_InPlaceDeactivate properly implemented

wine-bugs at winehq.org wine-bugs at winehq.org
Tue May 19 15:13:28 CDT 2009


           Summary: FontValidator (.NET based app) needs
                    OleInPlaceObject_InPlaceDeactivate properly
           Product: Wine
           Version: 1.1.21
          Platform: Other
               URL: http://www.microsoft.com/typography/FontValidator.mspx
        OS/Version: other
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: shdocvw
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: focht at gmx.net


now that some urlmon MIME support patches are on the way which are essential
for this app ("text/xml" MIME is later needed to show XML content in embedded
browser window) I file an "intermediate" bug that needs to be fixed before we
can verify the new functionality with real apps ;-)

The story is basically about in-place activation and deactivation of embedded
browser control.
The current shdocvw OleInPlaceObject_InPlaceDeactivate stub is mostly harmless
for many embedded browser control hosting apps because they don't rely on the
fact that in-place deactivation doesn't really take place (control will be
destroyed shortly anyway).
This app use case is a bit special hence the current in-place deactivation stub
becomes the culprit. 

Steps to reproduce:

2. winetricks -q dotnet20
3. start app, "Font files" -> "Add..." -> select whatever true/opentype font
from your system
4. "Table tests" -> "Clear All" -> select only "BASE" (shortens test)
5. "Rasterization" -> deselect "Test rasterization of TrueType outlines"
(shortens test)
6. hit "Start validation"

The .NET 2.0 app creates an embedded browser control:

--- snip ---
0029:trace:ole:CoCreateInstance (rclsid={8856f961-340a-11d0-a96b-00c04fd705a2},
pUnkOuter=(nil), dwClsContext=00000001,
riid={00000000-0000-0000-c000-000000000046}, ppv=0x32e2a4) 
0029:fixme:shell:URL_ParseUrl failed to parse L"Interop.SHDocVw" 
0029:trace:win:WIN_CreateWindowEx L"Shell Embedding" L"Shell Embedding"
ex=00000100 style=46010000 0,0 0x0 parent=0x500b4 menu=(nil) inst=0x61020000
0029:trace:win:WIN_CreateWindowEx created window 0x100b6
0029:trace:shdocvw:create_shell_embedding_hwnd parent=0x500b4 hwnd=0x100b6 
0029:trace:shdocvw:OleObject_DoVerb (0x136d00)->(-5 (nil) 0x3c80034 -1 0x500b4
0029:trace:shdocvw:OleObject_DoVerb OLEIVERB_INPLACEACTIVATE 
0029:trace:win:DestroyWindow (0x500b4)
--- snip ---

and a "parking window" to host the control in inactive/hidden state until the
real hosting window is about to be created and displayed to avoid runtime
penalties of destroying and recreating browser control each time.

This blog gives some insight in the world of "parking windows":

--- snip ---
0029:trace:win:WIN_CreateWindowEx L"WindowsFormsParkingWindow"
L"WindowsForms10.Window.8.app.0.378734a" ex=00010000 style=02010000 0,0 0x0
parent=0xfffffffd menu=(nil) inst=0x400000 params=(nil) 
0029:trace:win:WIN_CreateWindowEx created window 0x100b8
0029:trace:win:show_window hwnd=0x100b6, cmd=0, wasVisible 1
0029:fixme:shdocvw:OleInPlaceObject_InPlaceDeactivate (0x136d00)
0029:trace:shdocvw:WebBrowser_AddRef (0x136d00) ref=11
0029:trace:ole:GetErrorInfo (0, 0x32d9b0, 0x19a9c4)
(0x136d00)->({df0b3d60-548f-101b-8e65-08002b2bd119} 0x32d9a8) interface not
0029:trace:shdocvw:WebBrowser_Release (0x136d00) ref=10
0029:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b84385b
ip=7b84385b tid=0029 
0029:trace:win:WIN_SetWindowLong 0x100b6 -4 61031784 W
0029:trace:win:alloc_winproc reusing 0xffff0057 for (nil)/0x61031784
0029:trace:win:WIN_DestroyWindow 0x500b4
--- snip ---

The CLR exceptions resulting from E_NOTIMPL of
OleInPlaceObject_InPlaceDeactivate are handled gracefully.

The window which is the real target for the browser control gets created later:

--- snip ---
0029:trace:win:WIN_CreateWindowEx L"C:\\windows\\temp\\tmp47b0.tmp.report.xml"
L"WindowsForms10.Window.8.app.0.378734a" ex=00050040 style=46cf0000
-2147483648,-2147483648 376x358 parent=0x10088 menu=(nil) inst=0x400000
0029:trace:win:WIN_CreateWindowEx hwnd 0x600b4 cs 0,0 376x358
0029:trace:win:show_window hwnd=0x600b4, cmd=5, wasVisible 0
0029:trace:shdocvw:WebBrowser_AddRef (0x136d00) ref=11
0029:trace:shdocvw:OleObject_DoVerb (0x136d00)->(-5 (nil) 0x3c80034 -1 0x600b4
0029:trace:shdocvw:OleObject_DoVerb OLEIVERB_INPLACEACTIVATE
0029:trace:shdocvw:WebBrowser_Release (0x136d00) ref=10
0029:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b84385b
ip=7b84385b tid=0029
0029:trace:seh:raise_exception  info[0]=80131509
0029:trace:seh:raise_exception  eax=7b82ca1d ebx=7b8c2918 ecx=00000000
edx=0032d958 esi=0032d958 edi=e0434f4d
0029:trace:seh:raise_exception  ebp=0032d920 esp=0032d8bc cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00000246 
--- snip ---

The CLR exception leads to following backtrace dialog (and abort):

--- snip ---
************** Exception Text **************
System.InvalidOperationException: Unable to get the window handle for the
'AxWebBrowser' control. Windowless ActiveX controls are not supported.
   at System.Windows.Forms.AxHost.EnsureWindowPresent()
   at System.Windows.Forms.AxHost.InPlaceActivate()
   at System.Windows.Forms.AxHost.TransitionUpTo(Int32 state)
   at System.Windows.Forms.AxHost.CreateHandle()
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl()
   at System.Windows.Forms.Control.WmShowWindow(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ContainerControl.WndProc(Message& m)
   at System.Windows.Forms.Form.WmShowWindow(Message& m)
   at System.Windows.Forms.Form.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr
wparam, IntPtr lparam) 
--- snip ---

The activate_inplace() OLE verb bails out early because Wine thinks the control
is in-place activated (This->inplace) -> real in-place deactivation never took
.NET runtime tries to fetch hosted control's window handle which fails because
no parent switch was done.

Adding simple in-place deactivation (releasing IOleInPlaceSite, resetting
This->inplace) lets this app succeed, having windows properly


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.

More information about the wine-bugs mailing list