English for Browser Extension Developers

Browser extension development has its own vocabulary shaped by the browser’s security model and the review processes of extension stores, both of which come up constantly in engineering discussions and in written communication with store reviewers. Precision matters especially in permission requests and store listing descriptions, where vague language can trigger a rejection or a lengthy review delay.

Key Vocabulary

Manifest The configuration file (manifest.json) that declares an extension’s metadata, permissions, and the scripts it runs — the browser reads this file to understand what the extension is allowed to do. Example: “We need to add the activeTab permission to the manifest before this feature will work, since we’re currently missing access to the current page.”

Content script JavaScript that an extension injects directly into web pages, allowing it to read or modify the page’s DOM, but running in an isolated context from the page’s own scripts. Example: “The content script can read the page’s DOM, but it can’t directly call functions defined in the page’s own JavaScript — we need to use message passing for that.”

Background script / service worker A script that runs independently of any specific web page, handling events, maintaining state, and coordinating between content scripts and the extension’s other parts. Example: “We moved this logic into the background service worker since it needs to persist even when the user closes the tab the content script was running in.”

Isolated world The separate JavaScript execution context that content scripts run in, preventing them from directly accessing variables and functions defined by the actual web page’s scripts, and vice versa. Example: “You can’t just call a page function directly from the content script — they run in isolated worlds, so you’ll need to inject a script into the page’s own context or use postMessage.”

Permission (extension permission) A specific capability an extension requests from the user, such as reading browsing history or accessing all websites, disclosed transparently at install time or through runtime prompts. Example: “We’re requesting the broad <all_urls> permission, but the feature only actually needs access to two specific domains — narrowing that will make the store review go faster and reassure users.”

Message passing The mechanism by which different parts of an extension (content scripts, background scripts, popup) communicate with each other, since they run in separate, isolated contexts. Example: “The popup sends a message to the background script requesting the current tab’s saved state, rather than trying to access it directly.”

Store review The process by which a browser vendor’s extension store (Chrome Web Store, Firefox Add-ons, etc.) evaluates a submitted extension for policy compliance before publishing it. Example: “Our last submission got flagged in store review because the permission justification didn’t clearly explain why we needed access to all websites.”

Manifest V3 The current generation of the extension manifest specification, which introduced significant restrictions (like replacing persistent background pages with service workers) primarily for security and performance reasons. Example: “Migrating to Manifest V3 broke our long-running background timer, since service workers can be terminated by the browser when idle.”

Common Phrases

In code reviews:

• “This content script is requesting way more DOM access than the feature actually needs — let’s scope the matches pattern down to just the pages it should run on.”
• “We’re not handling the case where the background service worker gets terminated mid-task — we need to persist state before that happens, not assume it stays alive.”
• “This message handler doesn’t validate the sender, so any other extension or malicious page script could potentially trigger it.”

In standups:

• “Yesterday I migrated the background page to a Manifest V3 service worker; today I’m fixing a bug where state isn’t persisting across worker restarts.”
• “I’m blocked on store review — they rejected our last submission over an unclear permission justification, so I’m rewriting that section of our listing.”
• “I finished narrowing our host permissions from all websites down to the three domains this feature actually needs.”

In writing store submission descriptions or permission justifications:

• “This extension requests access to your browsing history solely to detect and warn you about previously visited phishing domains; no browsing data is transmitted off your device.”
• “We request the storage permission to save your preferences locally, and the activeTab permission to read the current page’s content only when you explicitly click the extension icon.”
• “No data collected by this extension is sold to third parties or used for purposes other than the core functionality described above.”

Phrases to Avoid

Saying “give it all permissions” during development to save time. This creates real risk of that overbroad request making it into a production submission. Say instead: “let’s request only the minimum permissions this feature needs, and expand later if a specific feature requires it” — store reviewers and users both scrutinize permission scope closely.

Saying “the extension broke” for a service worker lifecycle issue. Say instead: “the background service worker was terminated and lost its in-memory state” — this is a specific, well-known Manifest V3 behavior, not a mysterious crash, and naming it precisely points directly at the fix (persisting state instead of relying on it staying in memory).

Saying “it accesses the page” vaguely in a permission justification. Store reviewers expect specificity. Say instead: “it reads the page’s visible text to detect [specific pattern]” — vague permission justifications are one of the most common causes of review rejection.

Quick Reference

Term	How to use it
manifest	”Add the new permission to the manifest before this feature works.”
content script	”The content script reads the page DOM in an isolated world.”
service worker	”State needs to persist since the service worker can be terminated.”
message passing	”The popup uses message passing to request data from the background.”
permission	”We narrowed the permission scope to just the domains we need.”
store review	”Store review rejected us over a vague permission justification.”

Key Takeaways

• Scope permission requests to exactly what a feature needs — both store reviewers and privacy-conscious users scrutinize broad requests closely.
• Understand isolated worlds and message passing precisely; most content-script-to-page communication bugs trace back to a misunderstanding here.
• Describe Manifest V3 service worker termination specifically, rather than calling state loss a mysterious “crash” — it’s expected, documented behavior to design around.
• Write permission justifications with concrete specificity (“reads visible text to detect X”), since vague language is a leading cause of store review rejection.
• Keep development-time permission shortcuts (like requesting everything) explicitly temporary, and narrow them back down before any real submission.