Browser.ExecScript() przestał działać po aktualizacji okna

Question

Wcześniej skonfigurować prosty testowe dla Watin (wersja 2.1), który brzmi:

var browser = new IE(); 

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

ta działa tylko wtedy, gdy nie jest zainstalowany KB3025390. Zainstalowanie go zrywa powyższy test z wyjątkiem UnAuthorizedAccessException, dla którego HRESULT ma wartość E_ACCESSDENIED. Co daje? Czy istnieje jakieś obejście?

Aktualizacja: Używanie IWebBrowser2.Navigate2 wraz z „javascript: console.log (123)” typ skryptów działa jednak

• to sprawia, że ​​czuję się nieswojo pomocą takiego osobnym kanale
• skrypty uruchamiane przez ten kanał zaplecza .Navigate2() może mieć maksymalną długość około 2070 znaków (dać lub zabrać) inaczej zostaną siłą przycięte do tej długości, prowadząc do błędów javascript po próbie uruchomienia ich
• przy użyciu .Navigate2() , nawet przy najbardziej banalnym skrypcie, spowoduje zapchanie stanu gotowości przeglądarki Internet Explorer na dobre, w tym sensie, że zostanie ustawione na READYSTATE_LOADING bez żadnej nadziei na pozbycie się tego. Mówiąc prosto, oznacza to, że gdy użyjesz tego hacka, musisz wykonać każdą kolejną operację w WatiN w sposób "nie czekaj na stronę do obciążenia" (GoToNoWait, ClickNoWait itp.), Aby twój kod się nie zawiesił czekam, aż przeglądarka wróci do READYSTATE_COMPLETE (która nigdy nie nadejdzie, jak już wspomniano).
• wydaje się, że tutaj jest o wiele szerszy problem w tym sensie, że nie mogę uzyskać dostępu do właściwości obiektu IHtmlWindow2 p.e. window.document ponownie wyrzuca nieautoryzowany wyjątek, co sprawia, że ​​praktycznie niemożliwe jest przeniesienie do świata C# wartości zwracanych skryptów, które używam (używając Expando itp.) dla dokumentów innych niż window.top.document (dla window.top .document okno jest IWebBrowser2.Document który załatwia sprawę)

Aktualizacja # 2: ludzie nad w projekcie selenu również zauważyli ten problem:

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

raport błąd został utworzono również:

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

Aktualizacja # 3: IHTMLWindow2.setInterval i IHTMLWindow2.setTimeout również rzucają wyjątki UnauthorizedAccess. Metody te nie są oznaczone jako przestarzałe w:

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

jeszcze mają rannych cierpiących na tych samych cięć wszystko jedno.

Aktualizacja # 4: Dałem podejścia zalecanego w tym poście strzał:

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

Aby dynamicznie powołać się na „eval” metody obiektu IHTMLWindow2 (lub jakąkolwiek inną metodę naprawdę). Otrzymałem ten sam "System.UnauthorizedAccessException" jak wyżej. Więc nie ma tu żadnej radości.

Firma Microsoft zaleca używanie "eval" zamiast "execscript", jednak po powyższym eksperymencie podejrzewam, że odnoszą się one do dostępu do "eval" tylko z poziomu przeglądarki.

O ile wiem, jak dotąd, jeśli chodzi o pełnoprawne IE11 + używanie "eval" poza procesem (przez COM) wydaje się być całkowicie zabronione wraz z innymi funkcjami-inwokacją obiekt window, jedynym wyjątkiem jest back-kanał wyżej wymienionego .Navigate2().

Answer 1

Okazuje się, że Microsoft w końcu wycofał się z decyzji o zabiciu .execScript na poziomie COM. Po prostu zainstaluj najnowsze aktualizacje dla systemu Windows, w tym kb3025390: Jedna z aktualizacji dla IE, która pojawiła się po Kb3025390 przywraca funkcjonalność .execScript na poziomie COM

Pamiętaj jednak, że .execScript nie jest już dostępny za pośrednictwem javascripta IE. W tym kontekście zniknęło na dobre.

Answer 2

FYI: ten nie jest również praca

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

wypróbować ten pracował dla mnie w niektórych miejscach ale nie wszystkie miejsca

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

lub

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

próbuje teraz aby znaleźć rozwiązanie za pomocą eval

Answer 3

Znalazłem sposób obejścia problemu aktualizacji instalującej się automatycznie. Możesz po prostu utworzyć prosty plik wsadowy z następującą treścią.

{kod} @echo off

wusa/uninstall/kb: 3025390/quiet/norestart

END {kod}

Następnie przejdź do harmonogramu zadań , utwórz nowe zadanie dla tego pliku wsadowego, które będzie uruchamiane co godzinę lub dzień zgodnie z Twoimi wymaganiami. Dodaj go jako zadanie systemowe, aby działał w tle i nie wpływał na działające automatyzacje.