Notes from Create and connect to new Chrome profiles with AutoHotkey
00:09 There’s been a lot of confusion on Chrome profiles. What they are, why you should concern yourself with them when using AutoHotkey.
00:23 Your Chrome profile is what keeps you logged into websites, connected to Google, etc. Most of the time you won’t need access to your entire Chrome profile. But you might want to start with a blank slate if you’re distributing your code to people. Or you want to create a new instance of Chrome that you don’t want attached to an existing Chrome tab. For any of those, you need to have a Chrome profile
01:17 This is because most people don’t have the remote debugging flag on their default shortcut. If you launch chrome with debugging code, it will automatically group it with the current process window.
02:38 So instead of spawning a new Chrome window that is listening to the debug window, it will open a new page on the existing Chrome instance without the debugging access (even though you specified debugging)
02:52 So in order to get Chrome to open a new instance, you need to use the Chrome profile.
03:51 Create a folder (name it what you want) and tell Chrome to use it the profile flag. “–user data-dir” with your directory i.e. “–user data-dir-C:\temp\newProfile”
05:18 Looking in the profile folder, you can see Chrome has generated a bunch of files. Things like Cookies, browser history, etc. Everything Chrome remembers…
05:47 If you’re targeting portable Chrome, making sure you have this profile set correctly can be a big deal! If you use AutoHotkey to launch portable Chrome, it might still load the default profile. Make sure you specify the Chrome profile!
07:32 Everywhere you would have used Chrome. In your script, use ChromeInst. (i.e. Instead of Chrome.GetPage use ChromeInst.GetPage.
07:32 That tells Chrome to look for this new / specific instance of Chrome instead of the default version. Remember, it’s only “new” right after you make it.
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
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, http://127.0.0.1:9222/json 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
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:40Websockets 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
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.