Jump to content

Browser object invalid when web page is from localhost


Recommended Posts

My environment:

Windows 7 Enterprise, Service Pack 1

Internet Explorer 9, Version 9.0.8112.16421

Apache 2.2

PHP 5.4.0

MySQL 5.5.22

AutoIt 3.3.8.1

My two line script:

#include <IE.au3>
$b=_IECreate("http://localhost/ost/index.php")

Generates this error:

Line 560 (File "C:\Program Files(x86)\AutoIt3\Include\IE.au3):

WEnd

Wend^ ERROR

Error: The requested action with this object has failed.

It has also failed at Line 549 and line 625 with the same message

It is like the object goes away and then comes back at some point

in the loop while the IE UDF is checking for the document to

finish loading.

A workaround to these errors was the following script

#include <IE.au3>
$b=_IECreate()
sleep(1500)
_IENavigate($b,"http://localhost/ost/index.php")
sleep(1500)

The document loads and I don't get any errors,

However if I try to do anything with the browser

object, it fails with with an "interface unknown" message.

MSDN explaing that message as follows:

Error Message: The interface is unknown.

Explanation: In a distributed (RPC) application, servers present objects known as interfaces to clients.

These interfaces have unique identifiers. The distributed application tried to use an interface that does not exist.

User Action: Contact the supplier of the running distributed application.

Another way to avoid the error was to copy the web site from

my local machine, to a web hosting company and changing the url

to point to to it. When the loaded web page was on a different

server, autoIt appeared to work as documented.

How can I change my environment so that I can run autoit,

against an instance of IE that is rendering a page that is served by a

local web server?

Thanks in advance for your generous assistance.

Link to comment
Share on other sites

Maybe this:

#include <IE.au3>
AutoItSetOption("WinTitleMatchMode", 3);exact match
Global $WinTitle, $oIE
_IEErrorHandlerRegister()
ShellExecute("iexplore.exe", "about:blank");start fresh instance of IE
WinWait("Blank Page - Windows Internet Explorer")
$oIE = _IEAttach("about:blank", "url");attach to fresh instance & get a handle
_IELoadWait($oIE)
_IENavigate($oIE, "http://www.autoitscript.com/forum/topic/140653-browser-object-invalid-when-web-page-is-from-localhost/");navigate to url
Do
Sleep(100);to avoid cpu hogging
$WinTitle = WinGetTitle("active");to retrieve most recently active window title
If $WinTitle = "Internet Explorer cannot display this page" Then __Terminate()
Until $WinTitle = "Browser object invalid when web page is from localhost - AutoIt Forums - Windows Internet Explorer"
;your code here
Func __Terminate()
Exit 1
EndFunc   ;==>Terminate
Exit
Link to comment
Share on other sites

I used your proposed code, exactly as written with the exception that I inserted the line:

msgbox(0,'Terminated',$WinTitle)

as the first line of the terminate function.

and I inserted the line:

msgbox(0,'Fell through the Until',$oIE.document.title)

after the until

The script enters the do loop and does the sleep (i have increased the sleep to 5000, it does not change what happens next) then assigns the active title to $WinTitle. Despite there being lots of windows, one of which is

active, the function assigns an int32 with a value of zero to the title which the function is documented as meaning "no matching title was found in any window". This contradicts the documentation which says that if you pass "active" you will get the title of the active window. The only way you should get zero in that case is if there were no windows at all.

The int zero returned value mean if statement evaluates to true and the __Terminate function is called on the first pass through the loop. My msgbox is invoked, the title is shown to be 0 and the script exits,

without displaying the message box I inserted after the until even though the title displayed on the active window is in fact

So how is it that the if statement could evaluate to true? I have to believe that it is because $WinTitle was returned as an integer so autoit cast the second operand of the IF expression to an integer, which would be a zero and since zero does equal zero, the terminate branch was taken.

So I changed the comparison operator to == which forces the title to be cast as a string. Now the IF fails and the until would be evaluated. Since the condition on the UNTIL suffers from the same casting issue as the IF did, it would fall through the loop because 0=0. But I changed that = to == as well which puts the script into an infinite loop because "0" never equals the literal string.

So why is the title always 0? It seems like a bug to me but hopefully some one can explain. But as an attempt to bypass that question, I changed the assignment from WinGetTitle to $oIE.document.title. That also loops indefinitely because the title of the document in the browser is different than the title in windows (it does not have " - internet explorer" at the end of it) so I changed the UNTIL statment to: Until $WinTitle=='Browser object invalid when web page is from localhost - AutoIt Forums' Now your script performs as expected so we get to the real test and I change the URL to localhost which is my original problem.

I get a somewhat improved result, but not ideal. It seems that the browser object returned by IEAttach is valid, and I can access it for read and write up until the point that I navigate to local host, at which point it seems to be abandoned by ie. It is still a valid object but the properties are empty and if I set any of them, nothing visible happens to the document currently rendered by ie. I tried setting the title and the href for example, that did not cause any errors, but nothing appened to the ie instance, leading me to believe that by navigation caused a new browser window object to be created. This might have something to do with ie's security zones. I have observed in ie that when navigating to a site in a different zone, you get a different instance of ie or the site opens as a tab on a different instance, one that matches the zone of the site being opened. Also, Watir has a requirement that to use Watir, you have to set all of your zones the same (something that I could not do due to a group policy on my machine) which is what led me to switch from watir to autoit to begin with.

Based on the presumption, that I need to get a reference to the new browser object, I attempted to attach using title, which failed but did not error out. It returned a valid browser object, but again, it was empty.

So I tried to attach using the url. This succeeded. Using the new browser object I am able to traverse the DOM of my target

site. I can read and write DOM properties and execute DOM methods! This is huge with one exception which is send keys.

I can not get $oIE.Send() to send any keys to the target instance of IE. I think this is a different issue than the one that I started this thread for so I will search the forum for similar issues. If I don't find anything, I will start a new thread. As to this thread, I have a work around, that solves my short term goal, but if I could get some feedback from experienced users, confirming my conjecture, perhaps we could update the autoit documentation to warn of the issue and document workarounds or to update the IE UDF to automatically detect and handle a zone change the way I did so future users wont have to burn the man hours on this that I did.

Edited by ted
Link to comment
Share on other sites

tl;dr

How to access a local html file by your browser depends on the system you run.

If you have a web server running on your local PC then you can use protocol HTTP, if not you need to use protocol File.

#include <IE.au3>
$b=_IECreate("file://c:\temp\test.html")

With 3.3.8.1 I get:

C:\Program Files (x86)\AutoIt3\Include\IE.au3 (560) : ==> The requested action with this object has failed.:
WEnd
WEnd^ ERROR
->16:22:01 AutoIT3.exe ended.rc:1
>Exit code: 1   Time: 2.755

With 3.3.9.4 (beta) it runs without problems.

My UDFs and Tutorials:

Spoiler

UDFs:
Active Directory (NEW 2022-02-19 - Version 1.6.1.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2017-07-21 - Version 0.4.0.1) - Download - General Help & Support - Example Scripts
OutlookEX (2021-11-16 - Version 1.7.0.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX_GUI (2021-04-13 - Version 1.4.0.0) - Download
Outlook Tools (2019-07-22 - Version 0.6.0.0) - Download - General Help & Support - Wiki
PowerPoint (2021-08-31 - Version 1.5.0.0) - Download - General Help & Support - Example Scripts - Wiki
Task Scheduler (NEW 2022-07-28 - Version 1.6.0.1) - Download - General Help & Support - Wiki

Standard UDFs:
Excel - Example Scripts - Wiki
Word - Wiki

Tutorials:
ADO - Wiki
WebDriver - Wiki

 

Link to comment
Share on other sites

@water

Thanks for the response but I always get the correct content in the browser. That was never the issue. The issue was getting a valid browser object to that content.

Yes I have a web browser running on the local PC. I documented that at the top of the posting. It is Apache 2.2 with PHP and MySQL. The http based URL was always getting the correct content and displaying it in the browser. I was just having difficulty getting a valid browser object to work with it.

@All, I resolved my send issue after reading another forum post. Thanks for your help

Link to comment
Share on other sites

Could you please describe what solved your problem or post the link to the thread? So users having the same problem in the future can find the solution too ;)

My UDFs and Tutorials:

Spoiler

UDFs:
Active Directory (NEW 2022-02-19 - Version 1.6.1.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2017-07-21 - Version 0.4.0.1) - Download - General Help & Support - Example Scripts
OutlookEX (2021-11-16 - Version 1.7.0.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX_GUI (2021-04-13 - Version 1.4.0.0) - Download
Outlook Tools (2019-07-22 - Version 0.6.0.0) - Download - General Help & Support - Wiki
PowerPoint (2021-08-31 - Version 1.5.0.0) - Download - General Help & Support - Example Scripts - Wiki
Task Scheduler (NEW 2022-07-28 - Version 1.6.0.1) - Download - General Help & Support - Wiki

Standard UDFs:
Excel - Example Scripts - Wiki
Word - Wiki

Tutorials:
ADO - Wiki
WebDriver - Wiki

 

Link to comment
Share on other sites

  • 5 weeks later...

It is a shame that people do not post their solutions. I wish more people had a 'help the community' approach instead of 'help me'. I have been spending hours trying to accomplish the same task as ted's original post. Whether I load a file locally ("file://") or via a localhost webserver, I get the same problems - as soon as the page is done loading, it 'loses' the $oIE object. Monitoring 'readystate' with IEPropertyGet goes from '4' (loaded/ready) to '0' (doesn't exist) in a matter of moments, and any attempts to access the DOM are met with an error (doesn't exist).

If I find a solution I'll update.

Link to comment
Share on other sites

Ha! Mere moments after posting this, and using a few new keywords tipped off on the above post, I found my solution. (The key term was 'local zone'). The problem is listed in the help file, I guess in my growing frustration I just didn't see this note:

New security in Windows Vista causes a new browser window to be created when a browser is instructed to navigate to a URL in a different security zone. This occurs as well with the initial creation and navigation initiated with _IECreate. The new window is a new browser instance and the previous browser object variable no longer points to it. There are several workarounds: 1) add #RequireAdmin to your code (this is required even if the account is part of the Administrator's Group and will propmt for credentials if necessary), 2) use _IEAttach to connect to the new browser window 3) add the target website to the Trusted Sites security zone in IE, 4) turn off "Protected Mode" in IE, or 5) disable UAC. Care must be taken to understand the implications of disabling IE security features when accessing untrusted sites.

Simply adding '#RequireAdmin' solved my problem immediately.

(Windows 7, IE9, for what it's worth)

Link to comment
Share on other sites

  • 10 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...