Chrome UDF

[JohnOne]

Something is not right here.
Since I re-installed, device manager network tab says I'm uploading at my full capacity.
I don't know what I'm uploading or what is uploading it, I have nothing running which should do that.

EDIT:

For the record.

This issue was with my AV not recognizing new files and uploading them for inspection.

Nothing to do with this UDF or its components.

Edited September 28, 2013 by JohnOne

[lbordier]

Hi Folks, 

I have kind of an issue here:

I've strictly followed the instruction for the installation. But I face kind of a weird situation when I run the script #1.

OS: W7 64-bit.

AutoIt: V3.3.8.1

When I launch the script ( chrome_example.au3 ) ==> Nothing happens or appears...

But When I use the AutoIt debugger tool, it works like a charm. 

Any thought would tremendously appreciated. 

Cheer

L

[seangriffin]

Something is not right here.

Since I re-installed, device manager network tab says I'm uploading at my full capacity.

I don't know what I'm uploading or what is uploading it, I have nothing running which should do that.

 

Hmmm, odd that something is uploading.  There certainly isn't anything in this solution that uploads or downloads.

Here's a description of exactly what the 3 components to the UDF do (in case anyone was wondering):

1. The Chrome UDF - is an AutoIT UDF that sends requests to the Native Messaging Host (below), via a text file, and waits for a response from the Native Messaging Host (below), via a text file.
2. The Native Messaging Host - is a Python application that listens for requests from the AutoIT UDF (above), via a text file, and forwards those requests onto the Chrome Extension (below).  It also listens for output from the Chrome Extension (below) and forwards that back to the AutoIT UDF (above), via a text file.
3. The Chrome Extension - is a collection of Javascript files that wait for a request from the Native Message Host (above), and then injects that request (Javascript) into the page within Chrome to interact with the elements in that page.  The response from this request is then sent back to the Native Message Host (above).

All these components communicate to each other through a combination of text files and stdio.  There are no HTTP requests involved, and as such I wouldn't expect any uploads or downloads to occur through the UDF.

Try Example #2 because it works "offline".  It should work without an internet connection, and that will eliminate any uploading or downloading going on.

Edited September 23, 2013 by seangriffin

[JohnOne]

I noticed now that native messaging host is no longer starting with chrome when the example is started.

I've tried a number of things, with chrome already running and without.

If I manually start messaging host, it ends when example is ran.

Is the value in registry supposed to be an escaped path...

"C:UsersJOHNAppDataRoamingAutoIt3Chrome Native Messaging Hostmanifest.json"?

I don't see any other paths in registry where the backslashes are escaped.

Edited September 23, 2013 by JohnOne

[seangriffin]

I noticed now that native messaging host is no longer starting with chrome when the example is started.

I've tried a number of things, with chrome already running and without.

If I manually start messaging host, it ends when example is ran.

Is the value in registry supposed to be an escaped path...

"C:UsersJOHNAppDataRoamingAutoIt3Chrome Native Messaging Hostmanifest.json"?

I don't see any other paths in registry where the backslashes are escaped.

 

Yes, it might seem odd that the registry value is escaped, though it must be this way or the native messaging host won't start.  That's my experience.

Here's more information to help in troubleshooting.  Thanks for spending the time on this.  Might help others too.

To confirm the native messaging host is starting with Chrome as expected, I would first try starting Chrome on it's own, without loading any pages or using the UDF.  Then go to Windows Task Manager and you should see the a process named autoit-chrome-native-messaging-host.exe.   This will confirm that the registry value above is set correctly, as this points Chrome to the location of the Native Messaging Host such that it can start it when Chrome starts..  

If autoit-chrome-native-messaging-host.exe isn't running when you start Chrome then get the value of the registry key above, and in Windows Explorer go to this location (i.e. C:UsersJOHNAppDataRoamingAutoIt3Chrome Native Messaging Host).  Check the file  autoit-chrome-native-messaging-host.exe and manifest.json exist.  Open manifest.json in Notepad.  Make sure "path" is set to the full path of autoit-chrome-native-messaging-host.exe, and the path includes double-backslashes.  Also make sure the value for "allowed_origins"opmlbgppkkdeleedejakphgmgiigjjga/) matches the value in the ID field of the Chrome Extension.  Check this by opening Chrome and go to the Tools -> Extensions menu item.  In the Extensions page make sure Developer mode is ticked, and then locate the ID field for the AutoIT for Chrome extension.  This value should match the value for "allowed_origins" in the manifest.json file.

If the settings above are correct, then every time you start Chrome, irrespective of whether you are using AutoIT or not, you should also have the autoit-chrome-native-messaging-host.exe process running.

The next step is to confirm if the AutoIT UDF is talking properly to the Native Messaging Host (autoit-chrome-native-messaging-host.exe).  Run an AutoIT script that uses the UDF (Chrome.au3), like one of the Examples from the top post.  When a function in the UDF is called, it should create a file named input.txt in the same location as autoit-chrome-native-messaging-host.exe (i.e. C:UsersJOHNAppDataRoamingAutoIt3Chrome Native Messaging Hostinput.txt).  This file should contain some Javascript relating to the UDF function called (i.e. document.getElementsByName('ExampleForm')[0].method;).  If Chrome and the Native Messaging Host (autoit-chrome-native-messaging-host.exe) are running, then the Native Messaging Host should immediately detect this file (i.e. C:UsersJOHNAppDataRoamingAutoIt3Chrome Native Messaging Hostinput.txt) whenever it's created, read it's contents and remove the file.  The Native Messaging Host is so fast at doing this that you may not even see the existence of input.txt.  Try running a UDF function without Chrome running and make sure input.txt is created. 

If input.txt is successfully created, then autoit-chrome-native-messaging-host.exe should automatically consume it (as described above), pass the Javascript onto the Chrome Extension, which uses it in Chrome and sends a response back to autoit-chrome-native-messaging-host.exe which should in turn create an output.txt file in the same location as input.txt.  The Chrome UDF then detects this file, reads in the response, and the UDF function completes.

[JohnOne]

allowed_origins"opmlbgppkkdeleedejakphgmgiigjjga/ was incorrect.

I copied the value from extension to json, still not starting messaging host.

continuing.

[lbordier]

Hi Folks, 

I have kind of an issue here:

I've strictly followed the instruction for the installation. But I face kind of a weird situation when I run the script #1.

OS: W7 64-bit.

AutoIt: V3.3.8.1

When I launch the script ( chrome_example.au3 ) ==> Nothing happens or appears...

But When I use the AutoIt debugger tool, it works like a charm. 

Any thought would tremendously appreciated. 

Cheer

L

 

Mhmhmmh here is the deal:

The library use "@ProgramFilesDir" which return the directory for 64 bits. But Chrome is still 32 bits. 

So I used this code:

$ProgramFilesDir = EnvGet('ProgramFiles(x86)') ; for 64bit Win it will return a valid path.

if not $ProgramFilesDir then $ProgramFilesDir = @ProgramFilesDir ; for 32bit Win this will "repair" the broken return from above.

 

or

 

Func _ProgramFilesDir()

    Local $ProgramFileDir

    Switch @OSArch

        Case "X32"

            $ProgramFileDir = "Program Files"

        Case "X64"

            $ProgramFileDir = "Program Files (x86)"

    EndSwitch

    Return @HomeDrive & "" & $ProgramFileDir

EndFunc   ;==>_ProgramFilesDirh

 

Cheers

L

[chachew]

When i look at the documentation inside the UDF the timeout periods state that the timeouts are for 'X' number of minutes, when you look at the code as well as the console output, the timeout is in 'seconds'

No big deal, just noticed it was documented wrong.

[seangriffin]

V0.5 of the UDF is now released.

Python has now been replaced with AutoIT as the Native Messaging Host.  This brings significant performance improvements over the previous Python solution, and also allows easier maintenance in the future with a complete AutoIT solution.

If you already have a previous version of the UDF installated, then you must repeat Steps 1, 2 and 3 from the INSTALLATION section of the top post.

[levshkatov]

Hi, everybody! 

Great topic, but I didn't find a function that allows me to click on a button with necessary text on it. 

Could you help me with this problem?

Edited November 7, 2013 by levshkatov

[NizonRox]

Is there a way to find a surtend Word and then execute a command? that would be great

[jdelaney]

I don't suppose there would be a way to use objects, since this is all read in from a text file...such as, having multiple windows/documents open, and differentiating between them.  Or looking for an element under an object?

Small fix, the _ChromeDocWaitForExistenceByTitle is not properly comparing the return string, so it always timesout.

Expected return string is like:

{"text":"HTML Form Example"}

if StringCompare($title_from_chrome, '{"text":"' & $title & '"}') = 0 Then

this fixes it ( inside _ChromeDocWaitForExistenceByTitle)

Func _ChromeDocWaitForExistenceByTitle($title, $timeout = 5)

    dim $error = 2, $response = "", $begin, $title_from_chrome

    $begin = TimerInit()

    While TimerDiff($begin) < ($timeout * 1000)

        $title_from_chrome = _ChromeDocGetTitle()
        if StringCompare($title_from_chrome, '{"text":"' & $title & '"}') = 0 Then
            $error = 0
            ExitLoop
        EndIf

        sleep(100)
    WEnd

    SetError($error)

    Return $response
EndFunc

Edited November 18, 2013 by jdelaney

[itotua]

Would this work on a locked Windows like the ControlSend ControlClick commands?

[Azzurr0]

Wow compliments! thank you for the work you are sharing with us!

I'm working on the function _IELinkClickByText 

someone has already done? I'm having trouble!

[nullschritt]

Seems really nice, though I would recommend not using file to communicate between scripts, this would speed up the process considerably, as it takes much longer to read/write data to the hard disk than it does to transfer it in RAM. 

[ddevil]

_IELinkClickByText chrome alternative ?

[Jordanoise]

_IELinkClickByText chrome alternative ?

Too long for a response to this question. Interested in a simple click on the link in chrome. Who knows the answer?

Edited February 20, 2014 by Jordanoise

[McCookieM]

I think I may have stumbled on the cause of the problem that some people are coming across where this UDF does not appear to work.

I too had issues with Chrome opening fine, shutting down fine, but no communication could be made with the messaging host.  Everything always timed out.

My software info:

Win 7 x64

Chome 33

AutoIt 3.3.6

Firstly I discovered that no registry entry had been made for me during installation. I did have a SoftwareGoogleChrome entry under HKEY_CURRENT_USER but no NativeMessagingHosts key.

As per a previous post, I decided to put the keys where specified so had to create a SoftwareGoogleChromeNativeMessagingHosts key tree under HKEY_LOCAL_MACHINE. Still having problems I put the same registry entries under HKEY_CURRENT_USER but still no go (after discovering the actual problem later I think either location should be fine)

After finding the great post detailing a full breakdown of the UDF and how it all works, I went though step by step and discovered that the first time Chrome is run, the autoit-chrome-native-messaging-host process was running.

Now, here comes the root problem (I think). If you run the command _ChromeShutdown() from AutoIt at the beginning of your script (which closes Chrome windows and kills the autoit-chrome-native-messaging-host process), then your next _ChromeStartup command will NOT re-open the messaging process. I think it's down to having multiple chrome processes still running (non-windowed like other plugins) so Chrome doesn't do a fresh startup and doesn't restart it's messaging hosts.

So, short answer just now is to close your chrome windows (and chrome processes) manually and only use _ChromeShutdown() at END of script.

Now the UDF works fine. Although you've still got to end all chrome processes manually before you run your script again.

Over to the developer. Not sure it's the best way, but you could end all chrome.exe processes in the _Shutdown function rather than closing any open Chrome windows. I'm sure you'll find a better way.

Hope this helps some of you.

[ZiFFeL]

Hello, first of all thankyou!!

I have try to use this on local files, but even in your second example is not working for me, online or works fine, but on local doesn´t change any value (inputs (textfield/checkboxes/radio...))

Any idea?

Regards.

[bootybay]

I'm not directly using the chrome UDF but i took a lot of tricks from it that don't work anymore!

For example the basic "[REGEXPTITLE:.*- Google Chrome]" was glorious to get a quick window handle.

But for some reason there is no "- Google Chrome" at the end of tabs anymore (or only rarely instead of on everything)

Do you know how to reenable it?