References

Automation Engines

Three Stacks, Nine Variants

PuppeteerPort is the default engine and works out of the box. It talks to Chrome directly over the Chrome DevTools Protocol using SDi's own CDP implementation -- no separate driver binary required. PuppeteerPipe is the same engine with its commands carried over a pipe the browser inherits at launch instead of a debugging port.

Selenium is the long-established WebDriver standard. It supports Chrome, Edge, and Firefox but requires a WebDriver binary that matches your installed browser version.

OttoMagic is GPAL's exclusive extension-based stack. It communicates with the browser through GPALRestAPI -- a local REST server -- and a browser extension that must be installed in the profile you are automating.

Each stack has a Hardware (HW) variant that adds real OS-level mouse and keyboard events. Selenium additionally has a JavaScript (JS) variant that interacts with elements by injecting JavaScript instead of using WebDriver's own DOM interaction.

Mixing Interaction Types

Hardware can be chosen for everything with a hardware engine, set on GPAL or on one browser. Hardware and JavaScript can both be chosen at the UOW level inline after WithSelector(), or per selector definition. This lets you mix interaction methods within a single workflow. Hardware for one element, Selenium for another, JavaScript for a third. JavaScript injection works on Selenium and Puppeteer; OttoMagic already drives the page through JavaScript. Hardware emulation works across all three stacks.

// Global engine setting

GPAL.WithAutomationEngine(

AutomationEngine.Selenium);


// Inline UOW-level override

browser

.LeftClick("#normal-btn")


.WithSelector((Selector)"#stubborn-btn")

.WithHardware

.LeftClick()


.WithSelector((Selector)"#js-field")

.WithJavaScript

.FillInFrom("value");

NOTE

The WithJavaScript interaction type applies on Selenium and Puppeteer engines, which then click by injected JavaScript. On OttoMagic it changes nothing, because OttoMagic already works through JavaScript.

Choosing Your Engine

All three stacks cover Chrome and Edge. Selenium and OttoMagic also support Firefox; the Puppeteer-based engines do not. In terms of what they can automate, they are roughly equivalent -- the same workflow runs on any of them with no code changes.

Puppeteer is built in and needs no setup, making it the natural starting point. Selenium has been the industry standard for years and has broad tooling support, but its WebDriver fingerprint is well-known and easily detected by bot-protection systems.

OttoMagic runs as a REST server paired with a browser extension, which makes the browser profile look like a normal user session. Its events are mostly synthetic, with clicks on form fields going through the browser's own input pipeline, so fingerprinting at the event level remains possible. Puppeteer communicating over CDP with no injected extension is likely the stealthiest of the three. In practice all three perform extremely well across a wide range of real-world sites.

NOTE

PuppeteerPipe and PuppeteerPipeHW drive Chrome and Edge exactly as PuppeteerPort and PuppeteerPortHW do. The only difference is how the commands reach the browser: over a pipe it inherits at launch, not a debugging port.

💬 Ask GPAL