7

I've set up a simple testbed for WatiN (ver 2.1) which reads:

var browser = new IE();

browser.GoTo("http://www.google.co.il"); // webpage doesn't matter really
browser.RunScript("alert(123)");

This works only if KB3025390 is not installed. Installing it breaks the above test with an UnAuthorizedAccessException which has HRESULT set to E_ACCESSDENIED. What gives? Is there any workaround?

Update: Using IWebBrowser2.Navigate2 along with "javascript:console.log(123)" type of scripts works however

  • it makes me feel uneasy using such a backchannel
  • the scripts run through this back-channel of .Navigate2() may only have a max length of about 2070 chars (give or take) otherwise they get forcibly truncated to this length leading to javascript errors upon attempting to run them
  • using .Navigate2(), even with the most trivial script, will clog the ready state of Internet Explorer for good in the sense that it will be set to READYSTATE_LOADING without any hope of getting rid of it. In simple terms this means that once you use this hack, you either have to perform every single subsequent operation in WatiN in a "dont-wait-for-webpage-to-load" fashion (GoToNoWait, ClickNoWait etc) lest your code freezes upon waiting for the browser to turn back to READYSTATE_COMPLETE (which will never come about ofcourse as already mentioned).
  • there appears to be a much broader issue here in the sense that I can't even access the properties of an IHtmlWindow2 object p.e. window.document throws an unauthorized exception again making it virtually impossible to transfer over to the C# world the return-values of the scripts I'm running (using Expando etc) for documents other than window.top.document (for the window.top.document window there is IWebBrowser2.Document which does the trick)

Update#2: The folks over at the selenium project have also noticed this issue:

https://code.google.com/p/selenium/issues/detail?id=8302

A bug report has been created as well:

https://connect.microsoft.com/IE/feedback/details/1062093/installation-of-kb3025390-breaks-out-of-process-javascript-execution-in-ie11

Update#3: IHTMLWindow2.setInterval and IHTMLWindow2.setTimeout also throw UnauthorizedAccess exceptions. These methods are not marked as deprecated in:

http://msdn.microsoft.com/ko-kr/library/windows/desktop/aa741505%28v=vs.85%29.aspx

yet they have wounded up suffering from the same cutbacks all the same.

Update#4: I gave the approach recommended in this post a shot:

https://stackoverflow.com/a/18546866/863651

In order to dynamically invoke the "eval" method of the IHTMLWindow2 object (or any other method really). Got the same "System.UnauthorizedAccessException" as above. So no joy here either.

Microsoft recommends using "eval" over "execscript" however after the above experiment I suspect that they are refering to accessing "eval" only from within the browser.

As far as I can tell thus far, when it comes to the full-fledged IE11+ using "eval" out-of-process (via COM) appears to have been completely prohibited along with any other function-invocation of the window object, the only exception being the back-channel of the .Navigate2() mentioned above.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
XDS
  • 3,786
  • 2
  • 36
  • 56
  • What about `browser.Eval("alert(123)");`? – Greg Burghardt Dec 19 '14 at 13:38
  • I'm also wondering if `browser.GoTo("javascript:alert(123)")` would work as well. Maybe it's got something with how the alert is being called? – Greg Burghardt Dec 19 '14 at 13:41
  • .Eval() fails with the same HRESULT. The .GoTo() approach seems to work though at least on trivial tests. On a different note: I fiddled with the security settings of IE in the Internet Zone and nothing came out of it. Thanks for looking into this. – XDS Dec 19 '14 at 15:38
  • Another thing I noticed is that browser.Eval() of WatiN essentially falls back internally to using window.execScript() like browser.ExecScript() and this is why it makes no difference at the end of the day. Read update#4 on how to invoke the "real" eval of the window object (only to still fail though). – XDS Dec 22 '14 at 18:12
  • I think your only solution is to remove the update that broke this. Which version of Visual Studio are you using? Maybe an update to VS will fix this? – Greg Burghardt Dec 22 '14 at 18:21
  • You are absolutely right Greg. Removing the update does indeed fix this. I'm using Visual Studio 2013. Thing is that the company I'm working for cannot afford to use the aforementioned solution in each and every one of our client's machines since we have no control over them (our platform is distributed globally). We're between a rock and a hard place unfortunately. – XDS Dec 22 '14 at 19:24
  • I've been dealing with this issue since released and I can confirm that there's no way around it (at that I could find) and the only way to solve it is by removing the patch but, as xDisruptor pointed out, there are many cases where this is out of our hands. It's time to start fully implementation of Chrome in WatiN. – ProgrammerV5 Dec 23 '14 at 15:18
  • I've found a way to patch-werk a utility function which emulates the functionality provided by .execScript but it has its shortcomings. I might post it (for all the good it's going to do) when I have some time on my hands. Microsoft is probably gonna kill off the trick my workaround relies on as well pretty soon since it's on the "same wavelength" as execscript. – XDS Dec 24 '14 at 23:38

3 Answers3

3

It turns out Microsoft eventually backpedaled on its decision to kill off .execScript at COM-level. Just install the latest updates for Windows including kb3025390: One of the updates for IE that came after kb3025390 brings back .execScript functionality at COM-level

Note, however, that .execScript is not accessible through IE's javascript anymore. In that context it's gone for good.

XDS
  • 3,786
  • 2
  • 36
  • 56
1

fyi: this one is also not working 

ieInstance.Document.Script.<methodNameString>(<commaSeperatedParameterString>)

try this worked for me at some places but not all places 

ieObject.Navigate "javascript:<methodNameString>(<commaSeperatedParameterString>)", Null, "_parent"

or

ieObject.Navigate2 "javascript:"<methodNameString>(<commaSeperatedParameterString>)", Null, "_parent"

now trying to find out solution using eval

ManishSingh
  • 1,016
  • 11
  • 9
0

I have found a way around the problem of an update installing automatically. You can just create a simple batch file with following content.

{code} @echo off

wusa /uninstall /kb:3025390/quiet /norestart

END {code}

Then go to task scheduler, create a new task for this batch file to run every one hour or day as per your requirements. Add it as a system task so it runs in the background and does not affect the running automations.

AJ.
  • 1,146
  • 11
  • 33
NiksGr8
  • 21
  • 3
  • Thank you for the effort you've put into this. It would be interesting to probe in the same spirit if it's possible to uninstall the update once and then 'hide' it from the windows update (aka add it to the undesired/blacklisted list of updates). My two concerns with this approach is, first, whether windows update will be smart enough to automatically blacklist future updates that depend on this update and second, how will this chain of dodged updates will affect system security in client machines. Just my 2c. – XDS Jan 13 '15 at 11:51
  • Actually I am using Selenium (which becomes useless after the update) on client server which comes under the group policy. So hiding the update was not helping me , update was getting installed after every 72 hours. That's why i looked for another approach rather uninstalling it after every 72 hours. So I made this simple scheduling task. Regarding your doubt , I hope internet explorer will fix this issue as there are lots of dependent systems getting crashed because of this , this specific update is for IE only hence not uninstalling it will not raise any security concerns – NiksGr8 Jan 13 '15 at 18:04