# Platform-specific gotchas and conventions

Known DOM quirks and account-flow conventions for specific platforms, gathered from real runs. Check here before assuming a generic extension mode/B approach will work against Instagram, SoundCloud, YouTube Studio, or the others listed below.

## Identity backbone — assume ProtonMail for every account flow

**Standing directive from the user (captured 2026-05-10):**

> Future automation workflows will use ProtonMail accounts for these activities (account creation, verification emails, password recovery, magic-link logins, 2FA recovery codes). While the user has ProtonMail open in an authorized Chrome tab, the agent should set itself up with MCP or API access for ProtonMail so future runs can read verification emails programmatically instead of falling back to "ask the user to paste the code."

**What this means in practice:**

1. **Default to ProtonMail when an automation flow needs a fresh email** — staging accounts, new SaaS signups. Don't propose Gmail; don't ask which provider.
2. **Inventory the ProtonMail tab on every session start.** If `mail.proton.me` is open, persist its target ID so verification reads are a same-session round-trip.
3. **Probe before assuming you can read inbox.** ProtonMail decrypts client-side; the DOM under `[data-testid="message-row"]` *should* be readable once a thread is open, but new clients sometimes virtualize the list. Run a read-only probe first.
4. **Look for a Bridge or API path before scraping the DOM.** ProtonMail Bridge exposes IMAP/SMTP locally on `127.0.0.1` once configured; prefer that over DOM scraping. No official public REST API for inbox reads at the time of writing — DOM-via-Path-A-snapshot is the realistic fallback. Re-check upstream before assuming this is still true.
5. **Never store the user's ProtonMail password or recovery phrase in AutoMem, files, or screenshots.** If a screenshot includes a verification code, it stays under `~/.dev-browser/tmp/` or `~/.browser-hand/screenshots/` and is not committed.
6. **Treat verification codes as ephemeral.** Read → use → don't persist.

If MCP/API access for ProtonMail gets configured later, link to it in this section and prefer that path.

---

## Platform-specific DOM gotchas (grow this list as you hit them)

These apply primarily to **headless/remote-debug mode** (script-driven SPA flows, `references/remote-debug-fallback.md`). extension mode's `snapshot`/`click`/`type` operate on the same DOMs, so the same selectors/quirks apply when targeting via `--selector` or `--text` — just without the QuickJS sandbox limits.

| Platform | Gotcha | Workaround |
|---|---|---|
| Instagram web | Website field is mobile-only. Web edit page shows: "Editing your links is only available on mobile." | Set link slot via IG mobile app. Bios pack should fall back to Linktree URL until the user does this. |
| Instagram web (2026-05-23) | Second manifestation of the same mobile-only constraint: `/accounts/edit/` returns a generic `Something went wrong / There's an issue and the page could not be loaded` error page (title `Page couldn't load • Instagram`) — survives in-app nav, "Reload page" button, AND `page.reload()`. No `aria-label`s, no inputs in the DOM. Observed on the `stacy.offline` session. Profile-grid renders normally; only the edit route 500s. | Treat as functionally equivalent to the mobile-only block. Do NOT attempt mobile-UA spoofing as a workaround on a launch-critical account — anti-bot risk far exceeds the value of one bio link. Stop and report; have the user set the link via the IG mobile app. |
| Instagram web | Submit button is `<div role="button">`, not `<button>`. `page.click('button:has-text("Submit")')` misses it. | Use `evaluate` to find by `textContent` across all `[role="button"]`, or use `page.getByRole('button', { name: 'Submit' })`. |
| Instagram web | Profile edit save confirms via a black toast bar with text "Profile saved." at the bottom of the viewport. | Wait ~2–3s after click, then `evaluate` for an element containing "Profile saved" before declaring success. |
| Instagram web | Avatar upload requires clicking "Change photo" first to mount the action-sheet dialog containing the live file input. Page-load file inputs are decoys — setting files on them does nothing. | Click "Change photo" → wait 1.2s → set file on `div[role="dialog"] input[type="file"]` using the option-B base64 flow. Avatar uploads via a separate API call (not the Submit button), so Submit may stay disabled even when the avatar updates successfully. Verify by capturing the avatar `<img>` src before upload, then reloading and re-reading it — a changed CDN URL is the canonical "upload succeeded" signal. |
| Instagram web (post composer entry, 2026-05) | Left-nav "Create" / "New post" affordance is an `<a href="#">` whose only child is `svg[aria-label="New post"]`. Clicking the SVG itself does nothing; you must click its closest `a/button` ancestor. There is NO intermediate Post/Reel/Live dropdown in the current desktop build — clicking the link jumps directly to a `div[role="dialog"]` with heading `Create new post`. | `document.querySelector('svg[aria-label="New post"]').closest('a,div[role="button"],button').click()` then `waitForTimeout(2200)`. If a future build introduces the menu step, also handle `div[role="menuitem"]` with textContent `Post`. |
| Instagram web (post composer file input) | Inside the `Create new post` dialog the real file input is `div[role="dialog"] input[type="file"][multiple]` with `accept="image/avif,image/jpeg,image/png,image/heic,image/heif,video/mp4,video/quicktime"`. There are 4 other page-level non-multiple file inputs that are decoys (same pattern as the avatar flow). | Use option-B synthetic-File pattern targeting `div[role="dialog"] input[type="file"]`. Same `_valueTracker` reset and focus→input→change→blur dispatch chain. Confirmed working with 1080×1080 PNG. |
| Instagram web (post composer steps) | Three-step flow after upload: dialog heading `Crop` → click `Next` → filter step (no heading) → click `Next` → caption step (`Write a caption...` placeholder). Both `Next` buttons are `div[role="button"]` whose textContent is exactly `Next`. Same Submit-button gotcha pattern — `button:has-text("Next")` will miss because they aren't `<button>`. | Scan `dialog.querySelectorAll('div[role="button"],button')`, match `text === "Next"`, click. After each Next, `waitForTimeout(2200)`. Crop step has aspect-ratio toggles (`Select crop`, `Select zoom`) at the bottom — for square 1080×1080 source, defaults are fine. |
| Instagram web (caption field) | Caption is `[contenteditable="true"]` with `aria-label="Write a caption..."` — NOT a `<textarea>`. `page.fill()` won't work. `document.execCommand('insertText', false, text)` DOES land text but drops `\n` characters (newlines collapse to one paragraph). Char-counter button text `0/2,200` is adjacent — read it back to confirm. | For single-paragraph captions: focus → `execCommand('insertText', false, text)`. For multi-line: split on `\n`, then per line `execCommand('insertText', false, line); execCommand('insertLineBreak')` (verify on your build first). Pre-flattening to one paragraph is acceptable for short copy. |
| Instagram web (Share + confirmation) | Share button is `div[role="button"]` with textContent exactly `Share` inside the caption-step dialog. Confirmation is **dialog-disappears**, not a toast — polling for "post has been shared" text inside `evaluate` is fragile because the dialog may close before the string appears. Polling loops over 30s inside a single `evaluate` will exceed dev-browser's per-script timeout (~30s). | Click Share, host-side `waitForTimeout(8000)`, then `evaluate` for `document.querySelector('div[role="dialog"]')` — `null` means success. Reload the profile and assert `a[href*="/p/"]` count incremented. Keep all sleeps host-side. |
| Instagram web (caption verification) | Live caption is reachable at `instagram.com/<user>/p/<shortcode>/`; the shortcode is the path segment after `/p/` in the `a[href*="/p/"]` from the grid. On the post page the caption lives inside `article` — exact element drifts, but it's a long text node containing the submitted copy. | After Share + reload, capture the first `a[href*="/p/"]` href, `goto(href)`, wait 2.5s, `evaluate` the longest text node inside `article` and assert it contains a distinctive substring of your submitted CAPTION. |
| SoundCloud web | "Update Image" appears THREE times on the profile edit modal: once for the banner/header (DOM-order first, top-right corner around x≈976, y≈142, inside `div.profileHeader__chooserWrapper`), and twice for the avatar (inside `div.editImage__select` at roughly x≈143, y≈267). Clicking the first DOM match opens the HEADER editor (a "Position and resize your profile header" dialog), not the avatar. | Target the avatar button by container class: find a button whose closest ancestor matches `div.editImage__select` (NOT `div.profileHeader__chooserWrapper`). Or sort the three candidates by bounding-rect Y and take the LOWER one for avatar, UPPER one for banner. Always cancel any stuck dialog (`button` with text `Cancel` inside `div[role="dialog"]`) before retrying. |
| SoundCloud web | Country autocomplete suggestions render in `div.comboBoxList` with items `li.comboBoxList__item` (NOT `role="listbox"`/`role="option"`); the `.selected` class marks the current keyboard-highlighted item. | After typing the country, find the matching `.comboBoxList__item` whose textContent equals the target (case-insensitive). Click it directly. Keyboard fallback (`ArrowDown` + `Enter`) also works once the input is focused. |
| SoundCloud web | The Edit Profile modal does NOT use `role="dialog"`. It's `div.modal__content` with an `h2.g-modal-title-h1` heading. `document.querySelector('div[role="dialog"]')` will match the OneTrust cookie panel instead. | Find the modal by walking up from the "Edit your Profile" heading text, or query `div.modal__content` directly. Same applies to sub-modals (avatar editor, headerImageEditModal). |
| SoundCloud web | Form field IDs inside the edit modal are dynamic per-open (e.g. `formControl_2443` one open, `formControl_3115` the next). Caching IDs across opens fails silently. | Re-map labels → IDs on every open: `Array.from(modal.querySelectorAll('label')).reduce((m,l) => (m[l.textContent.trim().toLowerCase()] = l.htmlFor, m), {})`. Use `fieldIds['bio']`, `fieldIds['country']`, etc. |
| SoundCloud web | Cancelling a sub-dialog (e.g. headerImageEditModal) closes the ENTIRE Edit Profile flow, not just the sub-dialog. Any unsaved fields are lost. | Always Save the main edit modal in phases. Do bio/country/city/name first (no sub-dialogs), save. Then avatar (open Edit again, do the upload, save). Then banner (separate flow on the page header, outside the main edit modal). Never combine an image upload with text edits in the same save cycle. |
| SoundCloud web | THREE "Update Image" buttons coexist when both the main edit modal AND a sub-modal (headerImageEditModal) are open: banner button at `div.profileHeader__chooserWrapper` (outside the edit modal), avatar button at `div.editImage__select` whose closest ancestor is `div.profileHeaderInfo__avatar`, and an avatar-preview overlay inside `div.headerImageEditModal__previewOverlayUser`. Picking the first DOM match opens the banner editor not the avatar. | Match by container class: for avatar, find the `editImage__select` button whose `closest('.profileHeaderInfo__avatar')` is truthy AND whose `closest('[class*="headerImageEditModal"]')` is null. For banner, find the `profileHeader__chooserWrapper` button on the page header (it's outside any modal). |
| SoundCloud web | Avatar upload sub-flow: clicking the avatar "Update image" opens a `div.imageChooser` containing `input[type="file"]` (accepts `image/jpeg,image/pjpeg,image/gif,image/png`) AND a sub-modal with heading equal to the user's display name and `Save` / `Cancel` buttons. Setting the file alone does nothing — you must also click the sub-modal's Save. | After clicking avatar Update image, wait ~1.5s, set the file on the input under `div.imageChooser`, wait ~2s for preview, then click `Save` inside the sub-modal (heading matches display name). The button transitions to text "Saving…" — that's the success signal. After it settles, the main Edit modal closes automatically; no need to click "Save changes" on the main modal afterward (it may already be gone). |
| SoundCloud web | Avatar URL on the public profile is a STABLE per-user CDN key (e.g. `avatars-jTyUd9MjBzJyyidt-eEWSWg-t120x120.jpg`) — uploading a new avatar does NOT change the URL. The IG-style "reload + compare URL" verification produces false negatives. | Verify SC avatar uploads by visual inspection of the post-save screenshot (compare the avatar visible in the header to the source file), OR by fetching the CDN URL and comparing `Content-Length`/file bytes pre vs post. Don't rely on URL equality. |
| YouTube Studio | Description is a contenteditable `<div id="textbox">` (with `role="textbox"`), NOT a textarea. Setting `.value` via the React-aware textarea setter does nothing. | Click into the contenteditable div to focus, then use `page.keyboard.type(text, { delay: 5 })`. Optionally `Meta+A` → `Delete` first to clear prefilled content. |
| YouTube Studio | Every visible `ytcp-button` wraps a hidden native `<button>` with the same text. Querying `button, ytcp-button` and filtering by text returns the count doubled (`Publish` matches twice; `Done` matches four times when a sub-dialog is open). | Scope queries to the smallest container that uniquely contains the action (e.g., `document.querySelector('ytcp-banner-editor').querySelector('button')`), or take only the first non-disabled match. The duplicates don't cause click failures — clicking either works — but probe output is confusing if you don't expect it. |
| YouTube Studio | File inputs for profile picture and banner are hidden (`width=0`, `height=0`), parented under `ytcp-profile-image-upload` / `ytcp-banner-upload` custom elements. Setting `.files` directly on these inputs DOES trigger the upload flow — no need to click the visible "Change" button first. | Find by parent class containing `profile-im` or `banner-upl`. Set `files`, dispatch `change`, then wait ~3.5–5s for the editor dialog to mount. |
| YouTube Studio | After upload, a crop/customize dialog mounts (`ytcp-profile-image-editor` or `ytcp-banner-editor`). Both dialogs may persist in the DOM after their first use and stay `display:visible` even when the other is the "active" one — querying any `ytcp-dialog` returns multiple matches, and the wrong "Done" button click leaves your upload pending (Publish stays disabled). | Target the dialog by editor class explicitly: `document.querySelector('ytcp-banner-editor').querySelector('button')` for the banner Done, `ytcp-profile-image-editor` for the avatar Done. If you see Publish stay disabled after clicking Done, you clicked the wrong dialog's Done — re-probe and target the correct editor. |
| YouTube Studio | Save action is "Publish" (top-right). It's greyed until there are unsaved changes, and reverts to greyed after a successful publish. Success signal is a black toast at the bottom of the viewport reading "Changes published" with a "Go to channel" button. | Wait for the toast, not just the click. Re-check Publish-disabled state to confirm save completed. |
| YouTube Studio video details dropdowns (2026-05) | Hidden stale `tp-yt-paper-dialog` dropdowns remain mounted after prior opens. Querying `tp-yt-paper-item` globally can select an invisible stale `English`/`Music` item at rect `0,0`, so the click appears to run but the field does not change. Language dropdowns also render long lists where the target option exists below the visible menu viewport. | Scope option lookup to the currently visible `tp-yt-paper-dialog` (`getBoundingClientRect().width/height > 0`), then scroll that dialog's `.content` container to `item.offsetTop - 250` before clicking by coordinates. Close the menu with `Escape` before clicking `Save`, and verify by re-reading the dropdown text after reload. |
| YouTube Studio | The customization page URL is `studio.youtube.com/channel/<UC...>/editing` (Profile tab is at `/editing/profile`). The public channel page (`youtube.com/channel/<UC...>`) shows a "Customize channel" link that opens Studio — but for automation, navigate the existing tab to the Studio URL directly via `page.goto`. | Use `page.goto("https://studio.youtube.com/channel/<UC...>/editing/profile", { waitUntil: 'domcontentloaded' })` then `waitForTimeout(5000)` because Studio's Polymer/Lit startup is slow. |
| YouTube Studio | Link slots ("Links" section) and the Contact-info Email field have NO `aria-label`. Matching `aria-label` for `link title` / `url` / `email` returns zero — the only stable identifier is `placeholder`. | Match by `placeholder`: `"Enter a title"` for link titles, `"Enter a URL"` for link URLs, `"Email address"` for the contact email. |
| YouTube Studio | The "Add link" button is disabled while any existing link row is still empty. Calling it twice in a row on a fresh page (one empty slot pre-mounted) only fills one row and silently no-ops on the second click. | Fill the visible empty row's title+URL pair first (fires the input/change events), then re-query and click "Add link" — it re-enables once the previous row has both fields filled. |
| YouTube Studio | Public verification for channel links + contact email: server-side render on `/about` page exposes all three. | `curl -sL https://www.youtube.com/@<handle>/about \| grep -oE 'instagram\.com/<...>|soundcloud\.com/<...>|<email>'` — fastest non-DOM verification. |
| Instagram web (caption editor — CRITICAL) | The caption `[contenteditable="true"]` is a **Lexical** editor (Meta's framework, identified by `<span data-lexical-text="true">` wrappers). `document.execCommand('insertText', false, text)` renders the text VISUALLY in the DOM but does NOT reliably commit to Lexical's internal `EditorState`. Share fires the post with the React-state caption (empty) and the post lands with NO caption — but every screenshot you took along the way (composer with caption visible, character counter showing N/2,200) looks fine. Failure mode: 5 posts shipped, all captions blank server-side, undetectable until you reopen the Edit dialog from a fresh navigation. | Use real keyboard events: `page.type('div[role="dialog"] [contenteditable="true"]', text, { delay: 10 })` after `evaluate(() => ce.focus())`. This emits `keydown/beforeinput/input/keyup` which Lexical's listeners require. `page.type` also handles unicode/emoji correctly. After typing, `waitForTimeout(1500-2000)` for Lexical's async reconciliation pass. |
| Instagram web (Done/Submit clicks — CRITICAL) | Clicking a `<div role="button">` via `element.click()` inside `page.evaluate(...)` fires the DOM click event but does NOT reliably trigger React's synthetic event handler on Lexical-backed forms. The Edit dialog's "Done" button closes the dialog visually (so it looks like it worked) but does NOT dispatch the save mutation — the caption stays whatever was on the server before. This is the same root cause as the Share-without-caption failure in the post composer. | Use real mouse events via the host-side API: mark the target with a unique attribute (`done.setAttribute('data-jg-done','1')`), then `page.click('[data-jg-done="1"]')`. `page.click` synthesizes the full `mousedown/mouseup/click` pair which React's event system listens for. Same applies to Share, Next, and any other div-role-button. **The in-evaluate `.click()` works fine on real `<button>` elements; the bug is specific to `<div role="button">` + React synthetic events.** |
| Instagram web (caption-edit recovery) | If posts shipped without captions (Lexical/click bug above), the Edit dialog can backfill them in-place. No need to delete-and-repost. Caption is editable indefinitely on regular feed posts. | For each post: `goto(.../p/<shortcode>/)` → click `svg[aria-label="More options"]` ancestor → click `Edit` button in menu → focus contenteditable → `page.type(...)` the caption → `page.click('[data-jg-done="1"]')` on Done. Verify by navigating away and reopening Edit; `ce.innerText` should match. |
| Instagram web (caption verification oracle) | Standalone post page (`/<user>/p/<shortcode>/`) renders the caption column EMPTY in the desktop logged-in viewport when comment count is zero — this is a layout artifact, NOT a caption bug. The `embed/captioned` view ALSO renders without caption text for cold posts. The FB-crawler-UA fetch of the post page returns `"caption":null` regardless. None of these are reliable. | The authoritative caption oracle is **opening the post's Edit dialog and reading the contenteditable's `innerText`** — that's what's actually stored server-side. Don't trust standalone-page screenshots or embed views; don't trust og:description content; don't trust the FB-UA HTML fetch. |
| Instagram web (per-script timeout budget) | The dev-browser QuickJS sandbox kills any single `run` after ~30s. Multi-post verification or fix loops that exceed 30s get terminated mid-script. Posts that complete before the timeout DO persist (Share/Done already fired), but any post-action verification gets skipped. | Split work into one-post-per-`run` invocations. Use bash to chain them with `sleep` between calls. Move the verification re-open path into a separate `run` that does 2-3 posts per script (each iteration ~10s). Don't bundle all 5 posts into one script. |
| Midjourney v7 web (2026-05-25) | Omni Reference is **NOT** a tab in the "Add Images" drawer. The drawer has exactly three tabs: `Start Frame`, `Image Prompts`, `Style References`. Per MJ docs, Omni Reference (`--oref`) materializes as a **drag-and-drop bin labeled "Omni-reference"** on the prompt bar only **during a drag operation** from the OS / desktop. Static DOM scans find zero `omni`/`oref` markers because the drop bin isn't mounted at rest. Also: **Omni supports exactly ONE image** (not multiple); strength is controlled by `--ow` (range 0–1000, default 100); a lock icon pins the ref to the imagine bar across multiple prompts. | To attach an Omni Reference programmatically: (a) stage the source file locally in `~/.dev-browser/tmp/`, (b) target the prompt bar / textarea container, (c) dispatch synthetic `dragenter`/`dragover` with a `DataTransfer` containing the File to surface the "Omni-reference" drop bin, (d) dispatch `drop` on that bin. This is **untested** on the stacy.offline account — first run should be exploratory with screenshots between each event. Reusing a gallery thumbnail as the Omni source is also untested; documented happy path is local-file drag. |
| Midjourney v7 web (CDN URLs, 2026-05-25) | Gallery thumbnails are served at `cdn.midjourney.com/u/<uuid>/<hash>_384_N.jpg`. Guessed full-res variants (`_N.jpg`, `_1024_N.jpg`, `_2048_N.jpg`, `_full_N.jpg`) return **403** even when the HEAD request is made from inside the authenticated page context. The 384px thumb is the only public CDN size reachable by URL guessing. | To get a higher-resolution copy of a generated/uploaded image: open its job-detail page (`midjourney.com/jobs/<id>?index=<n>`) and read the lightbox `<img src>` from there — the lightbox surface serves a larger size. Path-guessing from the thumb URL is not viable. |
| Spotify for Artists (2026-06-26) | A Spotify **listener session** (nav shows "Log out" + avatar initial) is INDEPENDENT of **artist-dashboard access**. With a session but no claimed artist, `artists.spotify.com/home` renders the *marketing* page (only out-link is "Get access" → `/c/claim`) and the real dashboard route `artists.spotify.com/c/home` 404s ("We couldn't find that page", title → "Error - Spotify for Artists"). Mechanical populate (avatar/header/social links) is impossible until a human completes the `/c/claim` identity flow. | Don't infer dashboard access from "logged into Spotify." Probe the dashboard route `/c/home`: a 404 / "Get access" affordance = not claimed → STOP, report, hand the claim to the human. The SPA also paints a gray skeleton left-rail for ~7s before resolving — wait before trusting empty `innerText`. |
| Spotify for Artists (2026-07-27, post-claim) | Once the roster is granted, routes are artist-scoped under `/c/artist/<spotifyArtistId>/…`, not bare `/c/home`. Confirmed for stacy offline (`14uypNwqTyJY37xXss14Px`): **Home** `…/home`, **Overview** `…/profile/overview`, **Image editor** `…/profile/edit-image` (Header image + Avatar image, each with **Update** + shared Cancel/Save), **About** `…/profile/about` (`edit bio` / `edit more info` aria-labels; social inputs `instagram-link-editor-input-label`, `twitter-link-editor-input-label`, etc.), **Settings** `…/settings` (ad prefs only). Images: click the matching **Update**, set file on the live `input[type=file]` (DataTransfer), **Save** → toast "Your image was saved. It may take up to 72 hours…". Socials: edit more info → fill → Save → "We saved your links…". extension mode under 50+ tabs often thrash (`extension_unstable` / ambiguous multi-tab targets). | Mode B: never re-claim. Prefer one S4A tab. If extension mode flaky, **Chrome AppleScript `execute javascript`** on the S4A tab works for inject+fill (chunked base64 into `window.__*B64`, never use `//` in injected JS chunk math). Bio remains human-only. |
| Apple Music for Artists (2026-06-26) | The marketing page (`artists.apple.com`) ALWAYS shows "Sign In" / "Claim your artist page" regardless of session, so it's useless as an auth oracle. The app surface is `/ui`; hitting it unauthenticated 302s to `idmsa.apple.com/IDMSWebAuth/signin?...&authResult=FAILED` (title "Sign In - Apple"). | Use the **`authResult=FAILED`** query param on the `idmsa.apple.com` redirect as the clean "not authenticated" signal — match on it rather than scraping the marketing page. Sign-in is an Apple ID identity wall (human-only); never click through it. |
| Audiomack (2026-06-26) | Auth state reads straight off the top-nav: `Sign Up` / `Sign In` present = logged out (authenticated users get an avatar/account menu instead). Profile/creator editing lives on a SEPARATE origin — `creators.audiomack.com` (e.g. `/upload`), NOT `audiomack.com`. False-positive trap: trending-tile text puts artist/song names into `/artist/`-ish hrefs (e.g. `/reggie-guyguy/song/me`) that can look like a logged-in account link. | Read auth from the nav `Sign In` presence, not from any `/artist/` href on the page. For mechanical populate, target `creators.audiomack.com` once the human has signed in. |
| Suno web (`suno.com/create` audio upload, 2026-07-02) | Upload entry is a `+ Audio` button (aria-label "Add audio - Browse, upload, or record audio") that opens a 3-item popover: **Browse / Upload / Record**. The `input[type=file]` elements are **detached at `document.body` root** (rect 0×0, no React fiber), so DOM-ancestry/dialog-scoped matching can't find the live one. No "I own the rights" checkbox exists — the only content gate is a 3-step wizard: (a) "Identify audio content" type-selector `<button>`s (toggle aria/magenta state, no inner checkbox), (b) optional "Describe Your Audio" free-text, (c) Continue → "Saving…" → clip lands in the workspace list with an "Upload" badge. | Monkey-patch `HTMLInputElement.prototype.click` to capture `this` when `type==="file"`, then fire the `+ Audio` button's React `onClick` followed by the "Upload" menu item's React `onClick` — the flow calls `.click()` on the real input, which you stash (e.g. `window.__jgUploadInput`). Inject a synthetic File via DataTransfer + `input`/`change` dispatch on the captured input. Verify via the workspace clip list (`a[href*="<song-id>"]`), then `goto` the `/song/<id>` page. |
| Suno web (editing surfaces, 2026-07-02) | Two distinct "Edit" surfaces: the **song page** `Edit` button is a metadata/publish dialog (caption, lyrics, styles, toggles, Delete) — NOT the audio editor. The real audio-editing menu is the workspace row's `More options (…) → Edit` submenu: Extend, Crop, Remove Section, Reverse, Adjust Speed, plus Pro-gated Fade In/Out, Add Instrumental/Vocal, Replace Section, Get Stems/MIDI, Remaster, Open in Studio/Editor. **`Open in Studio` does not respond to programmatic clicks** (React `onClick` and native `.click()` both no-op; Base UI submenu portal timing) — URL stays `/create`. | Use the row context menu for audio operations, not the song-page Edit dialog. For Studio, a human hover on Edit → click Open in Studio is the reliable path; don't burn calls on programmatic attempts. Backgrounded tab (`visibilityState=hidden`) does NOT block uploads or injection. |
| dev-browser relay `evaluate` (general, 2026-07-02) | Async IIFEs ARE awaited and the resolved value returned — but only for **single-expression** code returning a **primitive**. Multi-statement bodies (`window.x=""; "RESET"`) come back `{type:"undefined"}`. Separately, **loopback fetch from an https page silently fails**: `fetch("http://127.0.0.1:<port>/...")` makes the whole eval return undefined (no error surfaces) even though same-origin fetch works — don't build upload flows on a local CORS server. | Rewrite multi-statement evals as comma expressions (`(window.x="", "RESET")`). To move file bytes into the page: base64 the file host-side, split into ~200KB chunks, append each via comma-expression evals into `window.__b64`, then `atob` + `Uint8Array` decode in-page to build the `File`. Verify byte-exactness (decoded length + head/tail compare). |
| Home Assistant web (2026-07-07) | `location.reload()` fired via the relay's `evaluate` can wedge an HA tab: the HA WebSocket dies (`No PONG received` in HA core logs), `hui-view` never mounts (blank dashboard — toolbar/background render fine), NO console errors, and the wedge survives service-worker unregisters, hard reloads, and dashboard-config reverts — every SPA navigation in that tab stays broken, which mimics a server-side failure and sends you chasing ghosts. | Never verify HA changes with reload loops on one tab. Protocol: `open --url <dash> --page-name <fresh-name>` → host-side `sleep ~10` → `screenshot --target-id <id>` (take the id from `open`'s output; `--target-url` is ambiguous once several HA tabs exist). Healthy first loads render in ~5s; a tab that was evaluate-hammered + reloaded is disposable — abandon it and open fresh. |
| (add as encountered) | | |