Concepts

Core Concepts

Core Concepts

Fallback Actions: Automatic Recovery on Error

When a Selenium action throws, GPAL does not just give up. It logs an EXCEPTION event and retries the action, usually via JavaScript injection, so the workflow keeps moving. WithNoFallbackActions(true) turns this safety net off for workflows that should fail loudly at the first sign of trouble.

Selenium Fails, JavaScript Takes Over

Selenium's WebDriver calls can throw for reasons that have nothing to do with whether the element is actually interactable. A stale element reference after a re-render, a click intercepted by an overlay, an input type SendKeys does not handle well. By default, GPAL catches these exceptions in ElementHelper, publishes an EXCEPTION event describing what went wrong, and retries the action by injecting JavaScript directly against the element. Clicking it, setting its value, focusing it, scrolling it into view. Whatever the original action needed to do. Most of the time the workflow simply continues as if nothing happened.

Recovery Covers More Than Clicks and Typing

The same flag governs several related recovery paths: a stale element reference triggers GPAL to re-find the element (or refresh the page) and retry; a click intercepted by a popup or overlay triggers a scroll-into-view and another attempt; a hardware click that resolves to invalid screen coordinates falls back to a JavaScript, Puppeteer, or OttoMagic click instead. Even Puppeteer CDP clicks fall back to JavaScript if the CDP command fails. Subscribe to GPAL.ExceptionHandler or GPAL.InformationHandler to watch every recovery attempt as it happens.

// Default behavior - no extra code needed

browser.WithSelector("#tricky-input")

.FillInFrom(data);

// If Selenium SendKeys throws, GPAL logs an EXCEPTION event

// and retries by setting the value via JavaScript instead.

TIP

GPAL never fails silently, and it never recovers silently either. Each fallback publishes an EXCEPTION (or INFO/WARNING) event naming the selector, the original error, and what GPAL is trying next. So you can see exactly how often a workflow relies on the safety net, even when it does not fail outright.

Turning It Off: WithNoFallbackActions

GPAL.WithNoFallbackActions() switches off all of this. The first exception is published and the action simply fails, with no retry and no JavaScript fallback. This is the right call when a workflow should fail fast and loud, such as in CI, where a silent recovery could mask a real regression in the page under test.

// Strict mode - fail immediately, no recovery attempts

GPAL.WithNoFallbackActions();

browser.WithSelector("#tricky-input")

.FillInFrom(data);

// If Selenium SendKeys throws here, GPAL publishes the

// EXCEPTION event and stops - no JavaScript fallback is tried.

WARNING

NoFallbackRecoveryActions defaults to false. Fallback and retry behavior is active in every new GPAL workflow unless WithNoFallbackActions() is called. This makes workflows resilient out of the box, but it also means a page that is quietly broken (e.g. An input that no longer accepts native SendKeys) can keep passing because GPAL JavaScript fallback is doing the real work. If a workflow seems to be passing for the wrong reasons, try WithNoFallbackActions() temporarily to see what actually fails.

On this page

Core Concepts
Fallback Actions: Automatic Recovery on Error
  • Selenium Fails, JavaScript Takes Over
  • Recovery Covers More Than Clicks and Typing
  • Turning It Off: WithNoFallbackActions