Farrow v1.0.18

• Prefer curl / web_fetch over the internal browser for public APIs and static HTML. Use web_, x_, fb_* only when Firefox is needed (login, clicks, JS, CAPTCHA).
• New web_fetch tool: plain HTTP GET/HEAD, no browser.
• Crypto tools via Coinbase Exchange (Revolut has no public crypto trading API — Business API is fiat accounts/FX only):
  • Public, no key: crypto_markets, crypto_ticker, crypto_candles, crypto_orderbook, crypto_backtest (SMA crossover).
  • With API key (Settings → Shizuku, accessibility & Git → Crypto exchange): crypto_balance, crypto_order_status.
  • Live trading off by default: crypto_place_order, crypto_cancel_order (confirm=true, only when you ask with size/pair).

Farrow v1.0.17

• Colorful chat avatars. Each chat has a stable soft color and an icon that fits its topic (posting, travel, search, code…), or its first letter.
• x_post_beta is now x_post one-for-one, with one difference: it types the text instantly instead of letter by letter. It stays off by default under Tools as "Beta: faster X posting". x_post is unchanged.
• New tool reset_browser, on by default. It does the same as Settings > Internal browser setup > Reset browser, waits until the browser is back, and reports ok/error and how long it took. The agent uses it when browser tools hang or fail repeatedly.

Farrow v1.0.16

Fixes for x_post_beta (the opt-in tool under Tools > "Beta: faster X posting"):

• Checks that X really registered the text: the editor holds it and the Post button is enabled. Each attempt logs the editor length and the button state.
• If the text isn't registered, it falls back to a paste with the page window focused, then to keystrokes. A disabled Post button is never clicked; the beta stops with "nothing was posted".
• The Post click is fired without waiting for X's handler, and the posted check runs in separate short evals.
• After a failure, the beta empties and closes the composer, discards a "Save post?" prompt (never Save), stops running calls and returns to /home.
• A first page check that doesn't answer is skipped instead of forcing a browser restart.

x_post is unchanged.

Farrow v1.0.15

• New opt-in tool x_post_beta. It is off by default; turn it on under Tools as "Beta: faster X posting". It uses one browser eval per phase, does JS actions first and falls back to the TBP click only when the JS action had no effect, and inserts the text in a single step. It returns timings_ms.
• x_post is unchanged. The agent keeps using it unless you turn the beta on or ask for it.

Farrow v1.0.14

Fixes slow x_post clicks (30 s+) and the browser getting stuck afterwards.

• Cause: TBP's click --human re-read the viewport through the DevTools console every 2 s while it held TBP's global command lock. On a phone, that made one click take tens of seconds and blocked every other browser command.
• Clicks keep Farrow's human-like mouse path but use TBP's plain click. A click attempt is now capped at 10 s (was 30 s).
• Each step has a hard timeout. When it hits, the new bridge cancel command kills the hung call and the app waits until the browser is idle.
• If the browser is wedged before any text is typed, x_post restarts it once and retries. It never retries after the Post click.
• Bridge 1.15.0.

Farrow v1.0.13

• Faster X posting: x_post's waits now poll and return as soon as their condition holds (shorter settle sleep, 200 ms polls, quicker navigation check). The post confirmation also recognises an emptied compose box, so it no longer has to wait out its full 25 s timeout. Focus, typing and clicks are unchanged.
• x_post results now include timings_ms per step (browser bridge 1.14.0, updates itself).

Farrow v1.0.12

• Markdown tables in chat: header row, zebra rows, inline formatting, horizontal scroll.
• Chart tool: bar / line / pie / scatter / table charts rendered natively in the chat; tap for fullscreen, share as PNG.
• Chat archive: deleting a chat (swipe or long-press) moves it to the archive with Undo; Settings > Archive to open read-only, restore or delete permanently. Archiving stops a running task.

Farrow v1.0.11

Restore working X posting; remove an unreliable experimental feature

Farrow v1.0.10

v1.0.10

• Root cause, reproduced on the box with the phone's stack: Firefox ESR, TBP (xdotool plus DevTools-console evals) and this tbp_bridge.py, against tools/draftjs-repro/. That page is X-like and uses the real draft-js 0.11.7: a home inline composer, plus a reply modal with "Replying to @…", autofocus and a focus trap. Both editors carry data-testid="tweetTextarea_0".
  • The steps passed X's generic composeText selector to the bridge. document.querySelector returns the FIRST match, which is the home composer behind the modal, so editor_type focused that box. TBP evals run in the DevTools window, so the focus was only applied when Firefox's window was re-activated.
  • With X-like focus-trap behaviour, the keys went into the modal (the caret blinked there), but the bridge verified the home box and saw 0 chars. Its console execCommand('insertText') fallback then knocked the Draft.js modal out of the page in the fixture.
  • Without a focus trap, the keys went into the hidden home box and the bridge reported success, while the modal stayed empty.
  • x_post has the same latent bug whenever /compose/post shows the home timeline behind the modal. Its composeSubmit (tweetButton, tweetButtonInline) also resolves to the first match.
• Fix, app side: the target step (after waitFor composeText, before any click or typing) now picks THE composer: the box in the topmost open dialog, else the first box. It marks the editor data-farrow-compose="1" and that composer's own submit button data-farrow-submit="1". The following click, editor_type, settleSubmit, submit and waitPosted steps use these unique marks. The step log shows when the first match was another box. This applies to both x_post and x_reply, because both use the same implementation.
• Bridge 1.12.0 editor_type:
  • It takes a unique selector (it warns when the selector is not unique), or active: true, which types into document.activeElement.
  • For single-line ASCII it types a 3-character probe with xdotool, verifies THAT element, then types the rest and verifies again.
  • If the probe did not land, and for non-ASCII or multi-line text, it does a real clipboard paste (xclip + ctrl+v), which Draft.js handles. These choices are proven on the fixture: xdotool drops é/✓ and loses characters after shift+Return, and a synthetic ClipboardEvent from the console is ignored by Draft.js.
  • It fails fast (about 9 s on the box) with diagnostics: the target, the number of matches, activeElement, and where the text went.
  • Console insertText is no longer used.
• App verification: the app reads the marked editor's text back after the bridge reports success. On a bridge-1.12 failure it fails at once with the bridge's diagnostics.

Farrow v1.0.9

v1.0.9

• x_reply now uses x_post's implementation (SocialAutomation.composeAndSubmit, shared by both). The separate reply typing path is removed: replyAttempts, openComposer, focusAndType, the snapshot-mark editor, submitOnce, confirmReply and the stray/post-page retries. Only the opening differs, plus a "Replying to @author" pre-check.
• What x_post did differently from x_reply (v1.0.8):
  • URL: x_post opens https://x.com/compose/post with a goto step (nav, 40 s). x_reply opened intent/post?in_reply_to=<id>, which redirects, with a 10 s nav.
  • Editor: x_post uses x.json's plain composeText = [data-testid="tweetTextarea_0"] everywhere (TBP click, editor_type, settle). TBP resolves it with document.querySelector, i.e. the first match in the document. x_reply typed into an element it had resolved and marked itself (data-farrow-i from a page snapshot, then data-farrow-editor inside [role=dialog]).
  • Waits: x_post waits up to 45 s for composeText and goes straight to the click. x_reply waited 15 s for the dialog's box, then ran a stray-dialog cleanup, a page snapshot, a context eval and an editor-resolve eval before clicking.
  • Click: both use sturdyClick, but x_post allows 30 s for the TBP click and x_reply allowed 10 s.
  • Typing: both use typeIntoEditor / bridge editor_type, but x_post's budget is 45 s + 400 ms/char and x_reply's was 12 s + 150 ms/char. x_reply also added its own verify/insertText/paste retry.
  • Submit and confirmation: x_post runs settleSubmit on composeText/composeSubmit, clicks composeSubmit (ctrl+Return fallback) and waits for the success toast or the box closing (waitPosted). x_reply clicked a marked send button once and polled its own toast/emptied-box probe.
• x_reply now:
  • Path A: /compose/post?in_reply_to=<id>, then x_post's steps. The new target step runs right after waitFor composeText. It logs what x_post's selector resolves to (testid, class, rect, inDialog, inConversation, inArticle, focused, number of boxes, chars, URL). For x_reply it also requires that box to be inside the composer dialog with "Replying to @author" (polled for up to 4 s). This happens before anything is clicked or typed.
  • Path B (pre-check failed, e.g. the first composeText is the home box behind the modal): the post page, then x_post's steps on the conversation's inline reply box under the post. The reply bubble is clicked only when there is no inline box.
  • Any other step failure stops x_reply ("…; nothing was posted"), or reports "submitted, not confirmed" after the submit click.
• x_post is unchanged apart from the logging target step (8 steps).
• The x_reply budget is now 90 s (two opens with x_post's own waits). The step log keeps the v1.0.8 diagnostics: the target line and per-path timings with a summary.