Consider the following scenario:
You use an application that creates WebBrowser controls.
The application uses a SessionStorage object to store sessions in Internet Explorer 11 on a computer that is running Windows 7 or Windows 8.1.
In this scenario, you encounter the following issues:
When the application creates a control on the same thread, the data of the SessionStorage object is shared incorrectly.
Note This issue also occurs when the application creates a control on different threads. See article KB2980020 for more information.
When the application creates controls repeatedly, Internet Explorer becomes slow.
To resolve this problem, install the most recent cumulative security update for Internet Explorer. To do this, go to Microsoft Update. Additionally, see the technical information about the most recent cumulative security update for Internet Explorer.
Note This update was first included in the November cumulative security update for Internet Explorer (MS14-065).
When the script code on the page executes the window.open method, the application handles a NewWindow event and creates a new instance of the WebBrowser control. After you apply the security update MS14-037: Cumulative security update for Internet Explorer: July 8, 2014 that is described in article KB2980020, the virtual tab ID of each instance of the WebBrowser control is retrieved from TLS. If two WebBrowser controls are on the same thread, they share the same virtual tab ID. During the initialization of the a WebBrowser control for the new window, session storage for all WebBrowser controls that use the virtual tab ID is loaded into the new WebBrowser control. The size of the array of CStorageHelpers doubles with each new WebBrowser control.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
See the terminology that Microsoft uses to describe software updates.