Plugin / Demo / Google & YouTube demo

Remote Tab Opener — Google & YouTube

Open Google, run a search, read the first result, and pass it to a YouTube tab — safely and locally.

This page is a reproducible E2E example using only named actions (no eval()): open, focus, type, submit, read, navigate.

🟩 Install from AMO 📘 Start the guided demo

What you’ll explore on this page

This demo shows how the Remote Tab Opener extension lets an admin page open, focus, type into, submit, and read from another browser tab—then forward what it finds to a second tab (YouTube). Everything runs locally in your browser: no servers, no proxies, no cookie sharing.

The guided journey

  • Step 1 — Open Google: create a controlled tab (tabKey="google") and mirror its status on this page.
  • Step 2 — Style, focus & type: highlight the search box, focus it, and type your query from this page’s input.
  • Step 2 — Submit: trigger the Google search form directly from the admin page.
  • Step 3 — Read a result: fetch the first result (title + snippet) and preview it here, as JSON-backed UI.
  • Step 4 — Bridge to YouTube: open that result URL in a new or existing controlled YouTube tab.
  • Step 5 — Secondary YouTube: spawn a separate controlled tab to illustrate independence between tabs.
  • Step 6 — Read a suggestion: scrape a suggested video in YouTube and preview it locally; optionally open it in the main YouTube tab.
  • Step 7 — Close tabs: cleanly close the controlled tabs and see the live list update.

What you’ll learn

  • Named actions, not code injection: actions like open, focusElement, domType, submit, getHtml are invoked with predefined selectors—never with eval().
  • Two-tab choreography: how to extract data from tab A (Google) and use it to drive tab B (YouTube).
  • Live telemetry: this page mirrors URL and status events emitted by the extension for traceability.
  • Resilience patterns: watchdogs, mutex for getHtml, and busy-state UI to keep flows robust.

Safety & privacy model

  • Allow-list only: actions run inside controlled pages for domains you explicitly allow in the popup.
  • No SOP bypass: the extension never hands cookies or privileged context to this admin page.
  • Local-first: all steps happen in your browser; this page only displays returned snippets/URLs.

What you need before trying

  • Install/enable the extension, then allow-list google.com and youtube.com.
  • Open DevTools (F12) to inspect the JSON payloads for each action.

Common hiccups & quick fixes

  • EXT_NOT_DETECTED → ensure the extension is installed and this page reloaded.
  • DOMAIN_NOT_ALLOWED → add the domain in the extension’s allow-list, then retry.
  • ELEMENT_NOT_FOUND → the selector changed; reload the target page or adjust the selector.
  • NO_CONTROLLED_TAB → (re)open the target tab via Step 1/5.
  • TIMEOUT → wait for page load or reduce competing actions; the mutex prevents interleaved reads.

Tip: this demo is reproducible—copy the page, change selectors, keep the named actions. You get reliable, local E2E control without infrastructure.

Need help writing safe flows?
Try the copilot: Remote Tab Opener Copilot.

Step 0 — Prepare

  • Install/enable the extension, then open this page.
  • In the RTO popup, add google.com and youtube.com to the allow-list.
  • Keep your console open F12 to view JSON returns.

Guided demo — Google → YouTube

Controlled tabs: tabKey="google" and tabKey="youtube". The extension drives non-sensitive fields and submits the Google search.

Step 1 — Open Google

Open https://www.google.com/ in a controlled tab (tabKey="google") with focus. The status mirrors below.

Uses open + focus and emits tabStatus. If you see  Domain not allowed , add google.com.

Step 2 — Style, focus, and type the query

Highlight the Google search box, focus it, and type your keyword.

Sequence: domSetStyle → focusElement → domType → submit.

Step 3 — Read the first Google result

Fetch the first available result (title + snippet) and preview it here.

…

Step 4 — Open the first result in YouTube

Open the extracted URL in the main tabKey="youtube" (creates/focuses it).

First Google result URL:
https://…

Step 5 — Open a secondary YouTube tab

Create an extra controlled tab (tabKey="youtube-extra") to demonstrate independence.

You can click multiple times to spawn multiple RTO tabs.

Step 6 — Read a suggested video

Read a video suggestion from the YouTube tab and preview it here.

…

Why RTO can read
what “View Source” can’t

YouTube’s homepage (and most modern sites) is a Single-Page App. The HTML that gets downloaded is mostly a lightweight skeleton plus a big JSON blob (e.g., ytInitialData). The actual cards—titles, thumbnails, and <a href="/watch?...> links—are created later by JavaScript and web components. In other words, the interesting bits don’t exist in the static source; they’re hydrated into the DOM after scripts run.

What the page download contains (and does not)
  • Skeleton markup: shell elements and placeholders (often “skeleton” blocks).
  • Boot data: a large JS object (ytInitialData) that scripts use to render UI.
  • Missing pieces: no final, clickable /watch links, no hydrated titles/snippets, often no real thumbnails.

That’s why tools that only “download the HTML”
(network scrapers, view-source, plain fetch())
see the skeleton but not the rendered list of videos.
RTO does!

What RTO does differently
  • Talks to the live tab: RTO sends a command to the already-loaded YouTube tab and queries the real, post-JS DOM.
  • Post-hydration access: By the time RTO executes a selector, YouTube’s scripts have created the cards. The DOM now actually contains anchors like a#thumbnail[href^="/watch"] and titles like a#video-title.
  • Shadow DOM & components: Even if elements come from web components, they surface into the composed DOM; RTO queries that composed tree.
  • Safe readout: RTO returns sanitized snippets (e.g., outerHTML or textContent) to the admin page for preview, without dumping arbitrary scripts.
Mental model (one-liner)

Download HTML ≠ Rendered DOM. RTO reads the Rendered DOM inside the real browser tab after JavaScript has done its job.

How we “read a suggested video” in this step
  1. Ensure a YouTube tab is controlled by RTO (the demo opens or reuses one).
  2. Ask RTO to fetch small, specific fragments from the live DOM (e.g., the nth card’s anchor/title/avatar).
  3. Filter out non-video items (Shorts, playlists, radios), pick a candidate, and build a safe preview card.
  4. Cache the absolute https:// URL for the next step (navigation).
Typical teaching selectors
ytd-rich-item-renderer:nth-of-type(N) a#thumbnail[href^="/watch"] ytd-rich-item-renderer:nth-of-type(N) a#video-title
These match real anchors/titles only after YouTube’s JS has hydrated the page.

Verify it yourself

  • Open DevTools → Elements: you’ll see hydrated anchors/titles in the live DOM.
  • Open View Source or save the page: you’ll see the skeleton and boot data, but not those anchors.
TL;DR: Other plugins read the download; RTO reads the browser’s live DOM. That’s why RTO can surface titles, links, and thumbnails that “aren’t in the source.”

Step 6 b — Using the YouTube suggestion

Open the video suggestion into the YouTube RTO tab.
Video URL:
https://…

Step 7 — Close tabs

Closing updates the RTO tabs list below.

Display opened RTO tabs

RTO is exceptional by design

Lots of tools can “fetch HTML.” Very few can teach with it. RTO is built for live, post-JavaScript DOM reading and classroom-friendly control of real tabs, all through a tiny, predictable command set.

What makes RTO different
  • Live DOM, not downloads: queries the rendered page after hydration (post-JS, post-framework).
  • Named tab orchestration: address tabs by human keys (google, youtube, youtube-extra (2)).
  • Deterministic commands: open, navigate, getHtml, highlight, submit, runJs — small, teachable verbs.
  • Safety built-in: sanitized snippets, blocked sensitive inputs, allowlist by host/wildcard.
  • Teaching ergonomics: control banner, transient highlights, preview-ready HTML/texte.
  • Latency aware: gentle focus nudges and short timeouts to keep the UI snappy.
  • MV3-ready core: resilient content injection + alias registry with push telemetry.
Why other approaches struggle
  • “View Source” & raw fetch: see the skeleton, not the hydrated cards/links.
  • Record-and-playback tools: great for macros, brittle for live teaching with previews.
  • Headless scrapers: powerful, but run outside your browser; no immediate classroom feedback.
  • Ad-hoc userscripts: flexible, but you must re-invent messaging, safety, tab registry, timeouts…
Proof points you can demo in seconds
  • Read a YouTube suggestion with getHtml on hydrated selectors (cards that don’t exist in “View Source”).
  • Open/focus by tabKey (no tab explosion), then navigate without losing the teaching context.
  • Show the safe preview: sanitized HTML, links forced to target="_blank".
Typical teaching selectors
ytd-rich-item-renderer:nth-of-type(N) a#thumbnail[href^="/watch"] ytd-rich-item-renderer:nth-of-type(N) a#video-title
These only match after the page’s JavaScript has hydrated the DOM — exactly when RTO reads it.
TL;DR: Most tools read the download. RTO reads the browser’s live DOM, orchestrates named tabs, and hands you sanitized snippets ready for teaching. That’s why it feels “unfairly” good at demos like this one.

Source codes : Base and Assets.

  • index.js
    Shared UI & utilities (detector banner, mirrors, helpers).
    base
  • demo_master.js
    Admin–extension handshake & tiny bus.
    bus
  • router.js
    Light dispatcher binding buttons by data-action.
    router
  • lab_helpers.js
    Minimal helpers for logging, clipboard, postMessage, and ping/waitFor.
    helpers

Need help writing safe flows?
Try the copilot: Remote Tab Opener Copilot.

Live results

Tab info
  • Current URL:
  • Status: closed
Log (action returns)
JSON objects returned by actions will show here.
Note: if nothing appears, ensure google.com and youtube.com are allow-listed and the remote page has finished loading.