I built a Chrome extension where right-click menu items run real JavaScript

The CDN import sample is the one that made this click for me. Once you can pull an arbitrary ESM module at runtime, the extension stops being a snippet runner and becomes a tiny scripting environment sitting on top of whatever page the user is on. That's a genuinely different product than "custom context menu."

Which leads to the thing I'd think hardest about: your distribution model is people sharing scripts. The watermark sample is already 100+ lines with a proxyFetch that bypasses CORS. Most users will not read that before running it, they'll paste it because it does something they want. That's a great growth loop and a real liability in the same mechanism.

Worth deciding early whether you want to own that. A few options that don't kill the magic: show a diff of what permissions a script actually touches before first run, or keep a curated set that you've reviewed separately from arbitrary pasted code so there's a visible trust boundary between "official" and "from a forum."

Also practical: how are you handling the Chrome Web Store review? Remote code execution is one of the specific things their policy calls out, and I'd be curious whether the CDN import survived review or whether you had to frame it a particular way.

proxyFetch is the interesting compromise here: you traded null-origin CORS pain for an explicit host-permission prompt, which is the right direction, but it means the threat model is now "whatever the user pasted" plus "whatever the allowlisted CDNs happen to serve today". That second half is worth hardening before it becomes a Web Store conversation, because importing code from jsDelivr or unpkg at run time sits uncomfortably close to the remotely-hosted-code rule reviewers apply under MV3 — pinning exact versions with an integrity hash instead of latest shrinks the supply-chain surface and gives you a much cleaner answer if review ever asks. On adoption, the bigger constraint is that most people who want a right-click to actually do something won't write the five lines themselves, so a small built-in catalogue of ready-made items (resize an image, copy selection as markdown, look up a highlighted SKU) turns install day into value day and makes the script writers your contributors rather than your whole market. I'd also treat an edit as a new grant: a menu item that quietly acquires a new host after approval is exactly how tools like this lose trust, and re-prompting on capability change is cheap insurance. Are you planning a way for people to share scripts, and if so would you review submissions yourself or rely on per-script permission diffs to keep that safe as volume grows?

The engineering here is the easy part to admire and the hard part to sell, because the group who can write the snippet is much smaller than the group who wants the outcome. The unlock is probably a shared library of ready-made menu items, so people install a script rather than write one and the authors become your distribution. I watched this exact thing in the Microsoft world with PowerShell, where the durable value moved from the runtime to the gallery of scripts people could grab without fully understanding them.

Running dynamic JS directly from the context menu is super useful for quick automations and dev shortcuts. How are you handling CSP (Content Security Policy) restrictions across stricter websites? Neat project!

Awesome project! Being able to trigger custom JavaScript directly from the context menu opens up so many possibilities for quick automation and productivity hacks. As a tech enthusiast studying web development at Universitas Airlangga, seeing creative browser extensions like this is super inspiring for our own side projects. Thanks for sharing this!

One thing worth flagging alongside the per-script capability summary suggestion below: host permissions and script content can drift apart after the fact. If I grant api.github.com for one script today, then edit that same menu item's code next week to also hit a different host or do something riskier, does the extension re-prompt, or does editing silently inherit whatever was already granted?

That gap matters more here than in a typical extension because the "install once, review once" model assumes the code doesn't change after you've vetted it — but the whole pitch of Menu Mod is that editing scripts is the normal workflow, not a rare event. A capability summary at save-time (not just install-time) seems like it'd close that, otherwise the permission grant becomes stale the moment someone tweaks their own script.

“This is a really interesting approach. I especially like the idea of turning the context menu into a real execution layer instead of just another shortcut system. Curious how you handled permissions and security around arbitrary JavaScript execution.”

The scripting part is what got me. I have a few repetitive things that a right-click menu could actually take care of, never thought of wiring them that way. Bookmarking this to try on Monday.

That’s a clear wedge. I’d be nervous about permissions and “this extension can read all sites.” If the landing leads with one boring use case (rename a file, strip a param) instead of “run any JS,” more people will try it.

This is a perfect example of constraints forcing clarity. You started with a question: "what if I could make a right-click menu do something real?" That constraint - the specific UI surface - eliminated a thousand wrong directions. You couldn't confuse this with a general automation tool or a full scripting platform because the right-click menu IS the answer.

Founders often see constraints as limiting, but the clarity they buy is worth more than the breadth you give up. People who want this know exactly what they're buying. No ambiguity about scope.

The moat here is not the runtime, it is the script library, because most people who want this outcome cannot write the snippet themselves. I would ship 20 prebuilt menu items for real jobs (check this SKU price, push this selection to a CRM, run this text through an API) so a non-scripter gets value on install day. That also turns users into your content engine, because every good script someone writes becomes a distribution asset you can publish.

The individual utility is clear, but the team version may be the stronger paid wedge: approved script templates, version history, permission review, an execution log, and an admin-managed allowlist. I would test one shared workflow where five people repeat the same browser action, such as enriching a support ticket or checking an internal record. If the team installs and maintains one script centrally, you are no longer selling convenience to one developer; you are selling a controlled automation layer.

This could be surprisingly powerful for small repetitive tasks. I can imagine using it for formatting text, grabbing page data or automating little workflows without opening DevTools every time. Are there any limits on what the scripts can access?

This sounds like one of those tools where the use cases only become obvious after people start using it. Being able to attach small JavaScript actions directly to the context menu could remove a lot of repetitive browser tasks. Do users create the scripts themselves, or are you planning some kind of shared library too?

This sounds like one of those tools where the use cases only become obvious after people start using it. Being able to attach small JavaScript actions directly to the context menu could remove a lot of repetitive browser tasks. Do users create the scripts themselves, or are you planning some kind of shared library too?

Nice approach, and the sandboxed-Worker choice is a smart way to stay MV3-compliant: user-authored scripts run from a local Blob instead of remote code, so you sidestep the "no remotely-hosted code" rule that kills a lot of extension ideas.

The one thing I'd poke at: a Web Worker has no DOM access and can't see the current page's JS context. So "hit an API" works great (fetch is happy in a worker), but "check a price" - if that means reading the price off the page you're actually looking at - can't work from the worker alone. You'd need a content script to scrape the DOM and message-pass the value in. Might be worth being explicit about that split, because people will assume a right-click script can read the page it was clicked on, and the sandbox is exactly why it can't.

Second thing, more caution than critique: the moment scripts become shareable, you inherit the userscript ecosystem's supply-chain problem - someone pastes a snippet from a forum that quietly fetch()es their session cookies out. Even inside the Worker sandbox, fetch plus whatever host permissions you've granted is enough to exfiltrate. If you ever add an import/share flow, a permission preview ("this script will talk to these domains") would go a long way.

Cool project though - the 5-min budget and return cap show you've already thought about runaways.

Being able to handle image tweaks or quick API lookups right from the context menu via OffscreenCanvas is brilliant. I can think of three annoying micro-tasks I do every day—like fetching quick stats or reformatting selected text—where I usually alt-tab to a terminal or web app. Replacing all that with a 5-line right-click script is huge.

Nice work on the MV3 wrangling. One thing I'd want spelled out in the docs: where does that 5 minute worker actually live? The service worker gets torn down after 30 seconds idle, and Chrome only lets an extension keep one offscreen document open at a time, so if that's the host then two long scripts fired back to back are sharing it. Does the second one queue, get its own worker inside the same document, or clobber the first?

The MV3 constraint work is actually the moat here — most developers who wanted this gave up when Manifest v3 closed the easy path. The fact that you've solved the CORS proxy, the null-origin worker isolation, and the storage cap means this isn't a weekend project that breaks in three months. That's worth communicating clearly in the positioning.

The distribution question I'd be thinking about: the person who knows they want "a right-click that hits an API" is a developer who could build their own extension. The person who'd pay for this without knowing the technical framing is the ops or power user who just knows they do the same five things every day and wants a shortcut.

Those two audiences need completely different onboarding — one wants the script editor open by default, the other wants a working script library they can deploy with one click without ever seeing code.

Which of those two actually shows up first when someone installs it today?

The five-minute worker budget is what makes this more than a fancy search menu. Before adding more actions, I'd build a dry-run view. It could show the selected text, hosts contacted, and commands that would run, without actually running anything. That would make copied scripts easier to inspect and debug, especially when a chain ends by copying to the clipboard, downloading something, or opening a URL. A one-click test run with sample context could also save you a pile of support tickets.

The ability to turn a right-click into an actual script execution is a pretty interesting upgrade from the usual custom menu extensions. Curious what people end up using scripting for first.

The per-host permission gate feels like the right primitive here. One thing I'd consider is making permissions visible per script, not just globally: a small capability summary (reads selected text, contacts api.github.com, copies to clipboard, opens a URL) before saving or running would make shared snippets much easier to trust. Are host grants currently scoped to the whole extension or to each menu item?

A few more scripting samples

1: CDN import

const { default: dayjs } = await import('https://cdn.jsdelivr.net/npm/[email protected]/+esm')

const formatted = dayjs().format('dddd, MMMM D, YYYY')

return `Today is ${formatted}`

2: One click image watermarker

// Global Configuration & Constants
const WATERMARK_URL = 'https://cats-nine-zeta.vercel.app/cat.png'
const WATERMARK_SCALE_FACTOR = 0.1 // Target 10% of the host image's matching shortest side
const CANVAS_PADDING_FACTOR = 0.01 // 1% margin responsive to each respective side's dimension

const DEFAULT_MIME = 'application/octet-stream'

// Directory support for organized downloads
const SAVE_FILENAME = `MenuMod_Watermarks/watermarked_image-${Date.now()}.png`

const base64ToBlob = (base64, mimeType) => {
  const binary = atob(base64)
  const bytes = new Uint8Array(binary.length)
  for (let i = 0; i < binary.length; i++) {
    bytes[i] = binary.charCodeAt(i)
  }
  return new Blob([bytes], { type: mimeType })
}

// Note: Grant the target host in Settings -> Host Permissions.
try {
  // 1. Safely extract the dynamic target URL using optional chaining to prevent crashes if context is missing
  const targetUrl = context?.srcUrl || ''

  // 2. Guard clause: Ensure we actually have an image to work with before hitting the network
  if (!targetUrl || targetUrl.trim() === '') {
    throw new Error('No valid image URL found. Try right-clicking on an image.')
  }

  // 3. Fetch both assets through the extension's CORS-bypassing proxy concurrently
  let targetResult, watermarkResult

  try {
    ;[targetResult, watermarkResult] = await Promise.all([proxyFetch(targetUrl, { responseType: 'arraybuffer' }), proxyFetch(WATERMARK_URL, { responseType: 'arraybuffer' })])
  } catch (netErr) {
    throw new Error(`Network request failed. Ensure host access permissiom is granted in Settings -> Host Permissions.`)
  }

  if (!targetResult.ok) {
    throw new Error(`Failed to fetch target image (Proxy status: ${targetResult.status}${targetResult.error ? ` - ${targetResult.error}` : ''})`)
  }

  if (!watermarkResult.ok) {
    throw new Error(`Failed to fetch watermark image (Proxy status: ${watermarkResult.status}${watermarkResult.error ? ` - ${watermarkResult.error}` : ''})`)
  }

  // 4. Decode the Base64 bodies into Blobs concurrently (MIME pulled from response headers)
  const targetMime = targetResult.headers['content-type'] || DEFAULT_MIME
  const watermarkMime = watermarkResult.headers['content-type'] || DEFAULT_MIME
  const [targetBlob, watermarkBlob] = await Promise.all([base64ToBlob(targetResult.body, targetMime), base64ToBlob(watermarkResult.body, watermarkMime)])

  // 5. Decode binary data into hardware-accelerated ImageBitmaps in parallel
  const [targetImg, rawWatermarkImg] = await Promise.all([createImageBitmap(targetBlob), createImageBitmap(watermarkBlob)])

  // 6. Calculate proportional dimensions where the shortest host side scales the corresponding watermark side
  let watermarkWidth, watermarkHeight
  const aspectRatio = rawWatermarkImg.height / rawWatermarkImg.width // Dynamically handles any image scale

  if (targetImg.width <= targetImg.height) {
    watermarkWidth = targetImg.width * WATERMARK_SCALE_FACTOR
    watermarkHeight = watermarkWidth * aspectRatio
  } else {
    watermarkHeight = targetImg.height * WATERMARK_SCALE_FACTOR
    watermarkWidth = watermarkHeight / aspectRatio
  }

  // 7. Spin up an isolated OffscreenCanvas mapped exactly to the host image sizes
  const canvas = new OffscreenCanvas(targetImg.width, targetImg.height)
  const ctx = canvas.getContext('2d')

  // 8. Enforce high-quality resampling filters to prevent pixelation during scaling
  ctx.imageSmoothingEnabled = true
  ctx.imageSmoothingQuality = 'high'

  // 9. Composite the graphics: draw the base image, then calculate bottom-right coordinates
  ctx.drawImage(targetImg, 0, 0)

  const paddingX = targetImg.width * CANVAS_PADDING_FACTOR
  const paddingY = targetImg.height * CANVAS_PADDING_FACTOR
  const x = targetImg.width - watermarkWidth - paddingX
  const y = targetImg.height - watermarkHeight - paddingY

  // Scale and stamp the watermark asset directly onto the canvas context
  ctx.drawImage(rawWatermarkImg, x, y, watermarkWidth, watermarkHeight)

  // 10. Asynchronously encode the canvas pixel array into a standard PNG Blob
  const finalBlob = await canvas.convertToBlob({ type: 'image/png' })

  // 11. Synchronously convert the binary blob into a Base64 Data URL for message passing
  const reader = new FileReaderSync()
  const dataUrl = reader.readAsDataURL(finalBlob)

  // 12. Return the actionable download payload out of the worker context
  return {
    action: 'downloadFile',
    payload: {
      url: dataUrl,
      filename: SAVE_FILENAME
    }
  }
} catch (error) {
  // Catch ALL errors—whether it's an undefined context, network failure, or canvas issue
  throw new Error(`Watermark & Download Script Error: ${error.message}`)
}

The proxyFetch + OffscreenCanvas work is clever, you've made the right-click menu a scripting surface nobody's built. But the sharp thing isn't technical, it's who this is for: what makes it powerful caps who adopts it.

"Same rule you'd apply to anything you paste into a console" is the tell: this is a power tool for people who think in JS snippets. A real, underserved audience (devs automating browser tasks) but narrow. Marketing it as a general "custom right-click menu" pulls in people who bounce the moment they see code. Lean INTO the dev framing: "bind a JS snippet to a right-click" self-selects who'll use it.

The moat is the ceiling: it's for people who can write the script. Growth becomes "where do those devs gather."

Most common script your users bind so far?