Microsoft KB Archive/253219

= PRB: WebBrowser Control Disappears When Script Calls window.close =

Article ID: 253219

Article Last Modified on 4/21/2006

-

APPLIES TO


 * Microsoft Internet Explorer 4.0 128-Bit Edition
 * Microsoft Internet Explorer 4.01 Service Pack 2
 * Microsoft Internet Explorer 4.01 Service Pack 1
 * Microsoft Internet Explorer 4.01 Service Pack 2
 * Microsoft Internet Explorer 5.0
 * Microsoft Internet Explorer 5.01
 * Microsoft Internet Explorer (Programming) 5.01 SP1

-



This article was previously published under Q253219



SYMPTOMS
When the script on a Web page calls the window.close property on itself, the WebBrowser control may disappear from the window. This article explains how to determine when this has occurred and how to take appropriate action.



RESOLUTION
In Internet Explorer 5.5, the WebBrowser control's default source interface, DWebBrowserEvents2, exposes a new event called WindowClosing. You can sink DWebBrowserEvents2 and set the Cancel parameter of the event to TRUE to prevent the close from occurring, or you can close the host windows.

In Internet Explorer 5.01 and earlier, the WM_PARENTNOTIFY message is sent to the parent of a child window when the child window is created or destroyed, or when the user clicks a mouse button while the cursor is over the child window. Thus, the hosting container of the WebBrowser control can watch for a WM_DESTROY notification message. If LOWORD of the wParam field of the WM_PARENTNOTIFY message is set to WM_DESTROY, the HIWORD of wParam contains the child window identifier, and the lParam field contains the hWnd of the child control. If the hWnd in lParam matches the hWnd of the WebBrowser control, you can determine that the WebBrowser control is being destroyed. You can then take the appropriate action, which typically means to close the child window for multiple-document interface (MDI) applications and quit the applications for single-document interface (SDI) applications.



MORE INFORMATION
When the script calls window.close, the WebBrowser control destroys its window, but the control is still in its "running" state (that is, the control is not completely destroyed). The WebBrowser control does not inform its container on deactivation through the IOleInPlaceSite::OnUIDeactivate method.

Handling the WM_PARENTNOTIFY message
  Add a handler prototype for the OnParentNotify function to the CHtmlView-derived class: afx_msg void OnParentNotify( UINT message, LPARAM lParam );   Add a WM_PARENTNOTIFY handler to the message map: BEGIN_MESSAGE_MAP(CQ253219View, CHtmlView) . .   ON_WM_PARENTNOTIFY . . END_MESSAGE_MAP   Implement the WM_PARENTNOTIFY event handler. For example: void CQ253219View::OnParentNotify(UINT message, LPARAM lParam ) {      if ((LOWORD(message) == WM_DESTROY) && ((HWND)lParam == m_wndBrowser)) {          // Close the parent frame window. GetParentFrame->PostMessage(WM_CLOSE, 0, 0); }      else CHtmlView::OnParentNotify(message, lParam ); }                   

Steps to Reproduce Behavior

 * 1) Use the Microsoft Visual C++ AppWizard to create a new MFC EXE project.
 * 2) Choose the defaults for all except the last step. In the last step, change the base class for the View class to CHtmlView, and click Finish.
 * 3) In the OnInitialUpdate function of the View class, browse to an HTML page where the script calls window.close (either from inline script, or on the click of a button).
 * 4) Run the project, and invoke the script that calls window.close. Note that the control disappears from the window, which leaves a blank space.

