• Become a Power user Intro to AutoHotkey Intermediate AutoHotkey Intermediate Objects GUIs are Easy w/AutoHotkey Painlessly switch from V1 to V2

02: Connecting & starting a page in Chrome and AutoHotkey

Chrome and AutoHotkeyConnecting & starting a page in Chrome and AutoHotkey

In this session GeekDude shows me several ways to connect to an existing Chrome page.

donate to GeekDudeIf you’re loving this, please consider donating to GeekDude!

Connecting & starting a page in Chrome and AutoHotkey

Connect to tab and page

1:00        Chrome.ahk was developed as a way to connect to Chrome w/o any external tools (unlike Selenium)

1:20        Don’t use Selenium, Use the Chrome.ahk class from GeekDude

1:43        All you need is Chrome and AutoHotkey.  Selenium install can be difficult

2:40        Chrome.ahk talks to Chrome using Chrome’s developer tools protocol.  Meaning if you open-up the page inspector (Control+Shift+I) or “inspect” an element. Anything you can do with the page inspector / debugger, you can do with AutoHotkey on Chrome.

3:20        Because AutoHotkey is external to Chrome you have to start Chrome with a special command line flag.  chrome.exe –remote-debugging-port=9222 . The easiest way to do this is to find your shortcut for launching Chrome (taskbar, Start menu, etc.) go to the shortcut properties and in the “target” add above code.

4:28        Every time you open Chrome, it will allow you to open the devtools window but instead of using the Control+Shift+I shortcut, it uses a network connection which allows you to connect to your Chrome window.

5:07        GeekDude thinks this is a “local” connection (meaning localhost) so it is probably just your computer.

6:16        Close out of any Chrome windows you have open. Be sure you inspect your system tray, Chrome might stay running in the background as will hangouts.  Both of these need to be closed!!!)

6:20        When you reopen, Chrome will be listening for the debugging connections (listening for AutoHotkey to speak to it).

7:10        Create a new AutoHotkey script with your favorite editor.  GeekDude  uses his CodeQuickTester AHK script

7:35        #include your Chrome.ahk class / library.  (I.e.   #Include C:\AutoHotkey_L\Lib\Chrome.ahk)

8:00        Many different ways to start the Chrome Class.  This video we’re connecting to an existing window

8:19        Create a variable Page:=Chrome.GetPage()

9:15        When you’re connecting to Chrome, Chrome separates different items (tabs, Extensions, etc.) into something called a “page”.  Each item has a different logical page.

9:47        Here GeekDude explains how a method in a class works.  Because Chrome is a class and GetPage() is a method in that class, you need to use both to use it  (I was confused because there was no “chrome” variable.    This is called a static Method or static function.  You don’t have to do anything with it, you can just call it.

10:45     Check to confirm the class did find a page.  Use msgbox % IsObject(page).  You should get  1 which means it successfully connected to a page.

12:35     Chrome library on Github has a lot of examples.  We borrow from it to get the page.

13:08     page.Evaluate(“alert(‘hi’);”) ;Call Evaluate on the page variable.

14:01     A method is just a function that acts on an object / class.  You can use Method and function interchangeably here.

14:20     The Evaluate function is sending JavaScript to the debugger console

14:46     The Popup worked, but it was on the “wrong” page.  We wanted the New Tab page

15:02     Go look inside Chrome.ahk and you’ll see several ways to connect to a page.

15:24     GetPage() function but also GetPageByTitle(), GetPageByURL() and GetPageBy()

15:40     The other GetPageBy() methods are less useful for automation.  If you can’t use GetPageByTitle() or GetPageByURL then reach out to him via Discord, email, his website https://www.philipt.net/.

16:31     Change from GetPage to use GetPageByTitle()

17:00     If you have more than 1 tab with the same name, it looks like it gets them in the order they are in (this is in flux)

17:50     Add parameters to the GetPageByTitle to tell it which tab you connect to.  page:=Chrome.GetPageByTitle(“New Tab”, “startswith”,2)

18:49     GetPageByURL – make sure you click several times in Chrome to get the full URL

19:20     You should only need to connect to the page once.  If you connect when it starts, just keep the pointer to that page for the rest of the time.  If you restart your script, you’ll need to reconnect to that page if the title or URL changed

19:52     Currently using the “startswith” matching option.  There is also “contains”  (it can be anywhere in the URL)  e.g. https://www.reddit.com/r/google/ will still be found when searching for “google”.

20:45     “exact” matching is case insensitive.

21:00     Use the various matching to adapt to your needs.

22:11     Change the program to only alert us when it is not an object (!)




01: Chrome and AutoHotkey- Connecting to Chrome with AutoHotkey | Amazing deep-dive into geeky things

Connecting to Chrome with AutoHotkeyConnecting to Chrome with AutoHotkey

This discussion wasn’t meant to be shared.  GeekDude was giving me some background on how we’re connecting to Chrome.  It is a bit “advanced” but some really good background info (especially understanding what a socket  verse WebSocket is).  Below is the video and my transcript-ed notes from the discussion

donate to GeekDudeIf you’re loving this, please consider donating to GeekDude!

Connecting to Chrome with AutoHotkey

1:50        Why starting with remote debugging port

1:41        Pages in debugging environment

2:18        Other browser automation tools like Selenium realized this is a great way to connect

2:53        The debugging tools like Chrome, Selenium, FireFox all adopted this same approach

4:00        Devtools protocol  https://chromedevtools.github.io/devtools-protocol/

4:09        Can I get the protocol as JSON?  If you’ve set –remote-debugging-port=9222 with Chrome, the complete protocol version it speaks is available at localhost:9222/json/protocol (remember to close all instances of Chrome before launching in debug mode)

4:30        The JSON string talks about everything you can do with the protocol

4:55        If you browse to this JSON page,  Chrome will show you all the debugable pages.  Tabs, Plugins, etc.

5:44        In json Look for webSocketDebuggerUrl and pick a “page”.  That will allow you to automate it

6:40        Iframe example with Google Doodle URL.  This will give you just the iFrame.   Get the ” devtoolsFrontendUrl” path then concatenate with your ip& port ( )   for example my hangouts was:

7:23        All you see in the debugger is from that iFrame (because we opened that iFrame directly)

9:06        other things marked as “pages”.  Long strings are probably extensions where someone didn’t fill out their info correctly

10:00     Automate plugins like lastpass.  It’s not documented yet, but you can see how to connect to it

11:00     When create instance of Chrome, it launches the Chrome browser and trys to get a specific debug port and then it saves that number for that instance.

11:37     We could have used the number

11:49     When creating other instances (GetPage() it takes that websocket debugger URL and passes it to the class “page” (in Chrome.ahk).

12:20     If there is a class in future versions of Chrome.ahk, he’ll probably only have the page class.  Because everything being done before you connect to that page is not live.      You have a live connection to the browser.  Everything up to this point wasn’t a “live” connection.  Once you have a connection to the page, it needs to be updated…

12:50     What is a websocket?

13:19     A socket is when you open a connection to another machine and you can send data to it and get data back.  It stays open and you can continue to transfer data back and forth

13:20     A webRequest is where you open a connection to a machine, you ask for a resources, it can wait and, when you get that resources back, you’re “done” an the connection is closed

13:40     Websockets bridge the two.  You start by sending a webrequest that says you want to open a websocket connection so that rather than a get/post winhttprequest, this is a special kind of request.  It “upgrades” that connection to a websocket connection.  From there it is much more similar to a regular socket.  You can send data back and forth.

What are WebSockets

14:29     This has been difficult to do from AutoHotkey because websockets were designed with a lot of abstraction to make things easier for the javascript developer.   A socket is much more loosey-goosey in that you send some bytes, they probably get there, probably not get there all at the same time, you fill up the buffer, occasionally flush the buffer, etc.  Websockets handle all of this for you! You send a “message” and it gets encapsulated.  The browser only exposes to you full messages.

So you don’t have to deal with text encoding, waiting for the full bytes, it all gets handled automatically.  That process takes a lot of extra code.  Even if you ignore the Secure sockets layer (SSL) writing all of that encryption code in AutoHotkey would be borderline insanity.  So it’s just not available.

15:52     That’s why when GeekDude  wrote Chrome.ahk and Discord.ahk, they both just create an instance of IE in the background and use ActiveX / COM to handle the WebSocket code.   This is fast but it is part of the instability.  It works great for the most part, but sometimes it just breaks down.

17:13     If IE dies, are we going to need to find another way?  GeekDude  thinks IE might never go away however he heard about websockets CAPI WebSocket Protocol Component API Functions for doing websockets.   This could be our way to create the WebSocket connection.

17:55     There’s a WebSocketCreateClientHandle function.  He’s not sure what it means, but it looks like a DLL compatible API call.  Hopefully we can use this to ditch IE.  Taking this approach will make it strange to implement Teadrinker’s solution.