Although It Comes with a Bit of a Learning Curve, the Chrome.ahk AutoHotkey Library Offers More Precise Source-Level Web Page Automation

(Updated November 5, 2020) Last time, I highlighted the limited techniques available for automating Web pages at the screen-level. The Web browser insulates the user from the underlying HTML and Javascript page code preventing the use of control names for automating Web pages.

This time, I introduce source-level Web page automation running a short test script after installing a set of Google Chrome AutoHotkey source-level Web page automation tools—Geekdude’s Chrome.ahk Library. I’ve set up a test page called “Jack’s AutoHotkey Chrome Test Page” for a quick trial of the tools. (When initially viewing the test Web page, you should see a set of three empty input fields: First Name, Last Name, and Street Address.) In this blog, I discuss how to install and set up the Chrome.ahk tools—then access the setup by running a sample AutoHotkey script that automatically fills in the three input fields:

If you can get this test script running with your Chrome browser, then a totally new world of Web page automation opens up.

Creating the Source-Level Connection

For source-level AutoHotkey Web page automation, we use GeekDude’s Chrome.ahk Library—tools for directly accessing the inner workings of a Web page via the Chrome DevTools Protocol. Implementing the library requires a number of installation/setup steps—then a little knowledge of HTML and Javascript to put the tools into action.

In this blog, I concentrate on installing the Chrome.ahk Tools and running the test script. In future blogs, I plan to introduce how to automate a Web page using these AutoHotkey tools with a little HTML analysis and Javascript code. (I’ll keep the HTML and Javascript as simple as possible.)

Note: While, personally, I did not find it easy to get the Chrome.ahk Library up and running, it’s quite possible that you may find success with the test script on your first try. I include a troubleshooting section in this blog for those who (like me) always seem to run into trouble. The following discussion includes the steps necessary for success.

Chrome.ahk Installation

Before running the test script, take the following actions:

1. Download the Chrome.ahk Library
2. Add the Chrome debugger switch to the target of the System Tray shortcut in order to connect to Chrome through the DevTools Protocol on LocalHost
3. #Include the correct Chrome.ahk path in the test script.

1. Download the Chrome.ahk Library

The first step requires you to download the Chrome.ahk ZIP file and extract its contents. Be sure you download the ZIP file which contains all the required pieces (Chrome.ahk_v1.2.zip).

Extract (unzip) the files to the location where you normally run your AutoHotkey scripts. I use C:\AutoHotkey as my primary script folder, but your folder may differ. Make sure you change the #Include path for the Chrome.ahk file in the test script to match your expanded ZIP file location.

Note: Although the ZIP file includes example scripts, when I attempted to run them, they seemed pretty enigmatic. That’s why I set up a simple bare-bones test Web page for testing the tools. Also, the video by GeekDude and Joe Glines available at the AutoHotkey forum (through no fault of their own) came across at a level slightly over my head. I had to watch the video a couple of times for the techniques to sink in. Eventually, the light turned on.

2. Add Debugging Port to Chrome Shortcut

To connect to the Chrome backdoor, you must append code to the Target of the Chrome shortcut in the System Tray.

1. Right-click on the Chrome icon in the System Tray.
2. Right-click on “Google Chrome” in the main menu.
3. Select “Properties” from the menu.

The “Google Chrome Properties” window opens.

Select the Shortcut tab and append (with a leading space) the following (in red) to the Target file path:

--remote-debugging-port=9222

When appended to the primary Google Chrome target file (EXE) path, this argument opens debugging tool access to Chrome.

Before running the test script, close all other Chrome windows—at least initially. An open Chrome window without the debugger access can interfere with Chrome.ahk operations on a Web page.

Note: I ran into a number of issues causing me temporary setbacks:

1. In the beginning, I was frustrated by the http.send() error (discussed below). Eventually, I found a solution through one of the comments in the AutoHotkey forum. If you already use remote access (or other localhost applications) with your computer, you may not encounter this error.
2. The first time I run the test script after rebooting, it tends to fail. However, on the second run, it starts working again(?). Try again.
3. Sometimes, after a period of time, the test script just stopped functioning. Rebooting usually restored function.

Run the Test Script

The following test script may run perfectly after installing the Chrome.zip files and modifying your Google Chrome shortcut target:

; Adjust path to location of Chrome.ahk
#Include C:\AutoHotkey\Chrome.ahk_v1.2\Chrome.ahk

; Required to initiate profile
 FileCreateDir, ChromeProfile
 ChromeInst := new Chrome("ChromeProfile")
 Sleep, 1000

; Connect to the newly opened tab and navigate to another website
; Note: If your first action is to navigate away, it may be just as
; effective to provide the target URL when instantiating the Chrome class
PageInstance := ChromeInst.GetPage()
PageInstance.Call("Page.navigate", {"url": "http://www.computoredge.com/AutoHotkey/ChromeTestPage.html"})
PageInstance.WaitForLoad()

; Execute some JavaScript
PageInstance.Evaluate("document.getElementById('fname').value = 'Jack'")
PageInstance.Evaluate("document.getElementById('lname').value = 'Dunning'")
PageInstance.Evaluate("document.getElementById('street').value = '1000 Main Street'")
PageInstance.Evaluate("alert('Hello World!');")

; Close the browser (note: this closes *all* pages/tabs)
PageInstance.Call("Browser.close")
PageInstance.Disconnect()

ExitApp
return

Update November 5, 2020: My frustration with the http.send() error continued in a random fashion—although worse at various times. I tracked it down to the ChromeInst := new Chrome("ChromeProfile") line of code and added a Sleep, 1000 command (line 7) to allow time for the the script to complete the connection. The script works more reliably now, although you may need a longer (or shorter) time period for your system. I speculate the reliability of this fix depends upon the speed of the computer processor and the demands on it. This does not override the original http.send() error discussed below.

If (after ensuring you inserted the correct path into the #Include statement) running this test script inserts my name and a fake street into the test Web page, then you don’t need to proceed any further in this blog. It’s working!

Tip: Whenever writing new scripts, ensure the code contains the required ProfilePath—Chrome user profile—relative to the working directory:

FileCreateDir, ChromeProfile
ChromeInst := new Chrome("ChromeProfile")

For the Chrome.ahk tools to run properly, this snippet must appear in any new script.

If the test script fails (i.e. nothing happens or the page opens with blank fields), continue reading for troubleshooting tips.

Troubleshooting When the Script Finds No Connection to Chrome

The most common error I received pointed to http.send() as its source. The hookup between the script and Chrome failed—a broken connection.

This error dogged me right from the beginning. It took a while to find a fix. At times, I thought about giving up but I eventually stumbled across the technique below.

Note: I’m not sure how the various Windows settings discussed in this blog interact. Some people may find the following works while others may need the answer found toward the end of this blog. During testing, I turned a number of settings on and off—ultimately finding that I must activate Windows Internet Information Services (IIS—a local Web server) in some form.

Turning on Windows Internet Information Services (IIS)

Depending upon how you use your computer (e.g. remote connections to your computer), your Windows Internet Information Services (IIS) may or may not be active. IIS can turn your computer into a remote Web server capable of hosting Web pages for remote browsers. (Generally, if turned on, you can access this local Web server using the browser address localhost or 127.0.0.1 in your Web browser.) If you have never installed software which requires IIS, then you may need to activate a piece of the service to allow access for the Chrome.ahk tools. I did!

While my setup didn’t require activation of the entire set of IIS, at a minimum, I had to turn on Web Management Tools.

I followed these steps:

1. Open the Control Panel Programs and Features window.
2. Click “Turn Windows features on or off” on the left side of the window.
3. Activate “Web Management Tools” in the “Internet Information Services” section.

1. Programs and Features/ Windows Features

Open the Control Panel and access Programs and Features.

2. Turn Windows Features On and Off

Click “Turn Windows features on or off” on the left side of the window to open the Windows Features window.

Check the boxes Internet Information Services and Web Management Tools, then OK. The Windows operating system then locates the required system files and implements the changes. (Be patient. Windows can take a while to complete this process.)

After activating the new setup, the test script should start working. If not, try rebooting—although sources say you should not need to restart your system.

Note: You don’t need to implement all of the World Wide Web Services but, if you would like to see what they do, check the World Wide Web Services box in the Windows Features window before clicking OK. Then, open “localhost” or “127.0.0.1” in your Web browser view the local Web hosting system:

Still not working? Try the following.

I tested this recommendation but it had no effect on my situation—either when turned on or off. However, it seemed to work for other people. Go figure. Since I don’t really know how all these features (and possible security settings) actually interact, I take the position that you should keep trying things until something works.

Hopefully, you now have the test script running—inserting my name into the test page. If you run into other problems and none of my tips help, yet you manage to get the Chrome.ahk tools working, please leave a comment about your experience.

Next time, as an introduction to automating Web pages with Chrome.ahk tools, I’ll explain how the pieces of the test code work with simple HTML and Javascript tips.

Click the Follow button at the top of the sidebar on the right of this page for e-mail notification of new blogs. (If you’re reading this on a tablet or your phone, then you must scroll all the way to the end of the blog—pass any comments—to find the Follow button.)

This post was proofread by Grammarly
(Any other mistakes are all mine.)

(Full disclosure: If you sign up for a free Grammarly account, I get 20¢. I use the spelling/grammar checking service all the time, but, then again, I write a lot more than most people. I recommend Grammarly because it works and it’s free.)

Find my AutoHotkey books at ComputorEdge E-Books!

Find quick-start AutoHotkey classes at “Robotic Desktop Automation with AutoHotkey“!