Concepts

Automation Targets

Automation Targets

Selenium's JavaScript Injection Override

WithJavaScript swaps Selenium's normal element interaction for direct JavaScript injection. An escape hatch that's only meaningful for Selenium, since Puppeteer and OttoMagic have no equivalent 'normal' interaction to override in the first place.

WithJavaScript: Bypassing Selenium's Own Methods

By default, a Selenium-based selector interacts through Selenium's own element APIs -- element.Click(), SendKeys(), and so on. WithJavaScript overrides that for a specific element and instead injects JavaScript that manipulates the element directly: setting .value, dispatching events, or calling .click() in the page's own script context. This matters for elements that resist Selenium's normal interaction -- inputs controlled by a JS framework that ignores SendKeys, elements visually covered by an overlay that blocks Selenium's click point, or elements Selenium can locate but can't reliably interact with.

// Normal Selenium interaction

browser

.WithSelector("#normal-input")

.FillInFrom("value");

// This input ignores SendKeys because a JS framework owns its value -

// inject JS to set the value and fire the events the framework listens for

browser

.WithSelector("#framework-controlled-input").WithJavaScript

.FillInFrom("value");

WithSelenium: Switching Back

WithSelenium is the reciprocal of WithJavaScript (and of WithHardware). It returns an element to Selenium's normal interaction. This is only needed if a broader override is in effect, such as a global WithJavaScript or WithHardware setting that you want to opt a specific selector out of. Like WithHardware and WithJavaScript, it can be applied globally, inline after WithSelector, or on a reusable Selector definition, with the most specific level winning.

TIP

WithJavaScript, WithHardware, and WithSelenium are all ways of choosing how a Selenium-based selector is interacted with. They only make sense because Selenium's default interaction model is something you might want to step around.

Why Puppeteer and OttoMagic Don't Have This

Puppeteer's automation engine talks to the browser via the Chrome DevTools Protocol (CDP). There's no separate 'Selenium-style' element API to override in the first place. CDP itself sometimes uses JavaScript evaluation under the hood for certain operations, but that's an implementation detail, not a choice GPAL exposes as an alternative interaction type. OttoMagic is built entirely on in-page JavaScript via its browser extension. It IS the JavaScript approach, with nothing else to fall back to or override. WithJavaScript is documented as Selenium-only for this reason: for Selenium, it's a real alternative to that engine's own element API, while for Puppeteer and OttoMagic there's no separate 'non-JavaScript' mode for it to switch away from. WithHardware is a different story and remains available on all three engines. It overrides any of them with real OS-level input, so Puppeteer and OttoMagic each have their normal interaction plus the hardware override, just not a JavaScript-injection override on top of that.

WARNING

Setting WithJavaScript while the base engine is Puppeteer or OttoMagic doesn't fail, but it doesn't change anything either. Those engines have no alternate 'non-JavaScript' interaction mode for it to override. Treat it strictly as a Selenium tool.

On this page

Automation Targets
Selenium's JavaScript Injection Override
  • WithJavaScript: Bypassing Selenium's Own Methods
  • WithSelenium: Switching Back
  • Why Puppeteer and OttoMagic Don't Have This