Installation of KB3025390 breaks out-of-process JavaScript execution in IE11 - by Jim Evans _home_

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


ID 1062093 Comments
Status Closed Workarounds
Type Bug Repros 27
Opened 12/21/2014 9:45:55 AM
Duplicates 1063540 Access Restriction Public

Description

When using the C/C++ COM APIs provided for automating Internet Explorer from out-of-process, all attempts to execute JavaScript on the loaded page produce an 'access denied' HRESULT. While IHTMLWindow2::execScript is listed as deprecated in IE11, it has been working up until the release and installation of KB3025390. Furthermore, attempting to use the recommended approach of using 'eval' doesn't work either, yielding the same HRESULT. This issue effectively breaks the Selenium project's Internet Explorer driver implementation for the WebDriver API. The same code works when used in IE6-10 and in IE11 prior to the installation of the aforementioned update.
Sign in to post a comment.
Posted by Evil Dauphin on 2/11/2015 at 8:55 AM
Hi Diego & Derek
I can confirm that KB3021952 fixes the issue for us.

Thanks
Adam
Posted by diego2k3 on 2/10/2015 at 4:27 PM
This issue should be fixed with the IE cumulative update out today (KB 3021952)
Posted by Colby.N on 2/10/2015 at 9:39 AM
I found a workaround that was mentioned at the following site: https://code.google.com/p/selenium/issues/detail?id=8302

I tried the workaround and so far it is working.

Here is the posts from the site that mention specifically what they did:


#17 timofey....@xored.com
I've found a workaround, which essentially undoes one of the changes made by the update, but I believe it should be used responsibly:

(for 32-bit IEDriverServer):
Change value "iexplore.exe" from 0 to 1 at:
HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_DISABLE_INTERNAL_SECURITY_MANAGER
Dec 23, 2014 #18 jsimm...@jeremysimmons.net
@Timofey's fix worked for me.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_DISABLE_INTERNAL_SECURITY_MANAGER]
"iexplore.exe"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_DISABLE_INTERNAL_SECURITY_MANAGER]
"iexplore.exe"=dword:00000001
Posted by _Stano on 1/29/2015 at 5:08 AM
Hi Everybody,

Does someone have any news on this issue?
We are using a C# application that hosts IE we run a JavaScript from the code to ensure some functionality using execScript. I was not able yet to found any workaround that would not include removing updates. Since execScript is deprecated i have tried to work with eval but didn't find any way how to use it properly. If anyone could provide me with some good example of how to use eval or some workaround for this issue i would be most grateful.
Posted by Dennis Garavsky on 1/21/2015 at 1:25 PM
Hello Derek,
 
We have also encountered this issue at DevExpress with the home-grown functional testing engine for our eXpressApp Framework (XAF) product. Sadly, it nearly caused the delay of the maintenance release for our own clients as this issue broke a good number of internal automated tests and it took us some time to research the cause and then apply workarounds from https://code.google.com/p/selenium/issues/detail?id=8302, which worked fine for us at that time. So, we are looking forward to a fix as well. Thanks!
Posted by Evil Dauphin on 1/20/2015 at 8:14 AM
Hi Derek
That is great news. Do you have an approximate timeframe of that update?
The update is breaking our automated testing tool's ability to test applications using IE.
Thanks
Adam
Posted by Derek Smith [MSFT] on 1/14/2015 at 4:48 PM
Thank you. We're aware of this issue and on track to release a fix as part of the next IE cumulative update.
Posted by kad0t on 1/13/2015 at 8:51 AM
The same issue. Did someone find a solution?
Posted by drdrdrdr on 1/9/2015 at 2:07 AM
Many companies have switched to Selenium-based Web testing (including ours) which is effectively not possible anymore with this update. Please resolve that situation in a favorable way soon.
Posted by kchute on 1/8/2015 at 12:53 PM
We are in the same boat as others here. Our clients are unable to launch XBAP windows from within our web application unless they uninstall KB3025390 which is needed to correct another problem with modal dialogs introduced by KB3008923.
Posted by Paul.N on 1/7/2015 at 2:22 AM
After wasting valuable time "chasing ghosts", we've now realised that this update has broken key functionality in our product WITHOUT warning.
Like many others here and on the web, we are getting many support calls because our product (which integrates externally with IE), now no longer functions.

We need to know what Microsoft's intention was for this update. If this break in compatibility was planned, then why weren't we warned and given alternative solutions.

For now, our only option is to suggest our customers remove this "security update"
(which, as you can imagine, is not going to sit well with most network admins!)

Looking forward to a swift resolution from Microsoft on this.

Kind regards
Posted by Jorge Ribeiro on 1/6/2015 at 2:35 AM
We have some products that use xbap component hosted in an HTML and the xbap interacts with the html script. This update broke this functionality and we cannot find a solution or workaround yet. Is it planned some sort of fix to this serious problem? Our customers are constantly calling our support line because they can't use our applications since the installation of this KB and the only solutions is uninstalling it.
Please help!

Thank you
Posted by NvdC on 1/5/2015 at 2:22 AM
The vbs script we are using created an IE pop-up window. We get the error "Permission denied: 'screen'" when using document.ParentWindow.screen.availWidth. Uninstalling the KB3025390 update fixes the problem, but is unacceptable. Please provide a new fix asap.
Posted by mirko99 on 12/31/2014 at 1:00 PM
This is not the only functionality that is broken. document.frames... and Document.location.href also give "Access denied."
This is just NOT ACCCEPTABLE. Some minor security update breaks functionality of dosen applications. It has to be corrected A.S.A.P.
Posted by M. Clark 256 on 12/30/2014 at 12:48 PM
This problem has disabled several major features of our product. Microsoft has documented no workaround or solution. This is very disappointing. I hope Microsoft will reconsider this patch and find an alternative approach to whatever they are trying to accomplish with this.
Posted by dominick_wa on 12/22/2014 at 10:22 AM
http://stackoverflow.com/a/18546866/863651

I followed the approach outlined in the above post of stackoverflow in order to dynamically invoke in C# any function under the window object. All methods (eval included) kept throwing "Unauthorized" exceptions. Am I right to assume that KB3025390 essentially killed any and all capabilities in terms of invoking out-of-process any javascript function of an IHTMLWindow2 object whatsoever? Are there plans to kill this type of functionality for the .Navigate2("javascript:console.log(123);") type of scripts as well?

As a side-note, the changes introduced by this particular update have wreaked havoc in an section of our platform essentially condemning it to wither and die unless a decent workaround is found. We simply need a way to run scripts out-of-process inside IE like we used to? Is crafting an IE addon (for IE11+ at least) the only way to achieve this from now on?

Thanks in advance.