Runbook — multi-step form autofill for developers

Runbook replays multi-step form flows on web apps you configure. Instead of hand-typing the same sample data through a seven-screen wizard every time you need to reach screen five, you describe the path once and run it with one click. Built for developers and testers working on internal applications. It was written against Axon Ivy / JSF / PrimeFaces process screens and is equally at home on an Angular app — or on any other http/https page, server-rendered or single-page. Setting up a flow 1. Open your app in a tab and click the Runbook icon. If nothing is configured for that URL yet, the popup offers to set the site up and creates an app entry with the origin already filled in. 2. Add a flow and build its steps in the editor: choose an action from a dropdown and fill in only the fields that action takes. No JSON knowledge needed. 3. Use Pick next to any selector field instead of hunting through DevTools. Runbook brings the app tab forward, outlines whatever you hover, shows the selector it would write, and warns you when that selector matches more than one element. Arrow up and down walks the element tree when it snapped to the wrong node; click or Enter takes it, Esc cancels. 4. Press Run while you are still editing, as often as you like. The flow runs in the open app tab as edited, saved or not, and the editor names each step as it executes — so a flow that breaks tells you which step broke and why. 5. Save. From then on the flow is one click in the popup. Flows are driven by the extension's background worker, so they keep going after the popup closes. Reopen it and it shows where the run got to, including the failing step and its error message. Stop cancels a run in progress. What a flow can do • Enter values — fill (native setter plus input/change/blur, so React, Angular and JSF ajax bindings notice), type (character by character, never blurs), autoComplete (types and picks the matching suggestion in one step), setText for contenteditable hosts, select, selectOne (picks a dropdown option by its visible label, framework widget or native select alike), check, uncheck • Press things — click, clickByText (matches the visible label of a button or link), radioByLabel (picks a radio option by its group and its label text), hover for menus that open on mouseover, pressKey to send Enter or Escape to the app's own handlers • Control timing — waitFor a selector, until it is actually rendered or until it disappears (ajax spinners, blocking overlays); waitForNavigation between wizard screens; goto to open the entry URL first, so a flow can start from anywhere; sleep for everything else • Check the outcome — expectText asserts that a screen says what it should, and fails the run with expected-versus-found • Reuse — runFlow runs another of the app's flows by name, so a shared login is written once; values can contain {{rand}} and {{today+3}} templates, resolved fresh on every run for forms that insist on unique or current data • Every element step waits for its own selector (5 seconds by default, overridable per step), and a step marked optional is skipped when its element is absent instead of failing the run • A flow stops at the first step that fails, and says which one and why The awkward parts it handles Click-recording autofill tends to fall apart on enterprise form frameworks. Runbook has specific handling for the usual traps: • Generated ids. JSF ids like form:j_id_2j change between deployments, so clickByText and radioByLabel target visible text instead. Picked selectors prefer [id$=':lastSegment'], so renaming a surrounding container does not break the flow. • Tabs that are already in the DOM. PrimeFaces TabView renders every tab up front, so waiting for a selector to exist returns instantly and the ajax response then discards whatever you typed. Waiting for it to be rendered lands on the right moment. • Autocompletes that only search on keystrokes. p:autoComplete clears itself on blur, so a plain fill leaves it empty. autoComplete types without blurring, waits for the suggestion list and clicks the right entry — one step instead of a fragile three-step dance. • Dropdown panels built lazily on first open — selectOne opens the widget and clicks the option by its visible label, waiting for the panel to exist. Ajax that swaps nodes mid-flow and real page loads between screens: after a navigation the worker re-injects its step executor and carries on, so one flow can walk an entire multi-page wizard. • Single-page apps. On an Angular app, fill goes through the native value setter and fires input, change and blur, so form bindings and touched-state validation react as if you had typed. A router change is not a page load, so you wait for an element of the next view rather than for navigation, and one flow walks the whole app just the same. What it does not do Worth knowing before you install: • There is no recorder. You write the flows yourself. The picker does the fiddly part, finding a selector that survives a redeploy, but the steps and their order are yours. • Top frame only. Elements inside an iframe or a shadow root are out of reach. • http and https pages only. It cannot run on chrome:// pages, the Web Store, or the pages of other extensions. • It is not a test framework. expectText gives a flow one basic assertion — the screen says what it should — but there are no reports and no CI integration. It gets you to the screen you care about; judging everything else on that screen is still your job. • Page access is granted one origin at a time, at run time, from your own click. The extension asks for nothing at install. A flow that navigates to an origin you have not granted stops and says so, and you can revoke any origin from chrome://extensions. • Flow values are stored as plain text and appear in exported files. Use test data. Do not put real credentials or customer data into a flow. C…