The Surprising Complexity of Injecting a UI into Someone Else's Web Page

Parvej Shah's team at Leadswave, a LinkedIn brand assistant Chrome extension, overcame significant technical hurdles including style collisions, service worker lifecycle issues, and Manifest V3 constraints. They used Shadow DOM for style isolation and direct API calls from content scripts to handle service worker termination, while also optimizing AI context extraction to reduce token usage.

Originally published at parvejshah.com/blog/building-manifest-v3-ai-chrome-extensions by Parvej Shah . When we started building Leadswave — a LinkedIn brand assistant Chrome extension — the plan seemed straightforward. Detect LinkedIn post elements in the feed, attach a small AI companion button to each one, let users generate engagement responses without leaving the page. A week's work, maybe two. Three weeks later we were still fighting style collisions, service worker lifecycle bugs, and a Manifest V3 API constraint we hadn't anticipated. This is what we learned. When your content script injects HTML into LinkedIn's document, you're working inside a page you don't control, with styles you didn't write, against a DOM structure that changes in LinkedIn's deployments without your knowledge. The first version of Leadswave simply appended a styled div to each post element and mounted a React component inside it. It worked locally. On the actual LinkedIn feed, our Tailwind utility classes either had no effect because LinkedIn's CSS specificity was higher or caused unintended effects in LinkedIn's own components because our styles bled into their DOM nodes . The fix is Shadow DOM. Every modern browser supports the ability to attach a shadow root to a host element, creating an isolated DOM subtree that is completely separate from the main document's style cascade. js function mountAssistantWidget hostElement: HTMLElement : HTMLElement { const container = document.createElement "div" ; container.id = "lw-assistant-root"; // Attach a shadow root — this creates the style isolation boundary const shadow = container.attachShadow { mode: "open" } ; // Our styles live inside the shadow — they can't bleed out, // and LinkedIn's styles can't bleed in const styleSheet = document.createElement "link" ; styleSheet.rel = "stylesheet"; styleSheet.href = chrome.runtime.getURL "content/styles.css" ; shadow.appendChild styleSheet ; const mountPoint = document.createElement "div" ; shadow.appendChild mountPoint ; hostElement.appendChild container ; return mountPoint; } Manifest V2 allowed persistent background pages — JavaScript modules that stayed alive indefinitely and could hold state in memory. Manifest V3 replaced this with service workers. Service workers can be terminated by the browser at any point when they appear idle. This is easy to forget when developing locally, because Chrome is less aggressive about terminating service workers during active development. In production, with a real user who opens LinkedIn once, reads through their feed over 20 minutes, and then triggers the assistant widget — the service worker has almost certainly been terminated in the interim. // Don't rely on module-level variables for persistent state // This will be undefined after the service worker restarts: // let cachedApiKey: string | null = null; // BAD // Instead, always read from storage: async function getApiKey : Promise<string | null { const result = await chrome.storage.local.get "apiKey" ; return result.apiKey ?? null; } async function saveUserSettings settings: UserSettings : Promise<void { await chrome.storage.local.set { userSettings: settings } ; } For the assistant response generation — which requires sending post context to an API and streaming back a response — the content script makes the API call directly rather than routing through the service worker. This avoids the service worker lifecycle problem entirely for latency-sensitive operations. The AI generation requires understanding the content of the LinkedIn post the user is looking at. Passing raw innerHTML is wasteful and noisy — LinkedIn embeds tracking attributes, SVG icon paths, interaction counters, and other noise that consumes tokens without contributing to useful context. js function extractPostContext postElement: HTMLElement : PostContext { const authorElement = postElement.querySelector ".update-components-actor name" ; const author = authorElement?.textContent?.trim ?? "Unknown"; const bodyElement = postElement.querySelector ".update-components-text" ; const bodyText = extractTextNodes bodyElement .filter text = text.trim .length 0 .join " " .replace /s+/g, " " .trim ; return { author, bodyText, extractedAt: Date.now }; } function extractTextNodes el: Element | null : string { if el return ; const texts: string = ; el.childNodes.forEach node = { if node.nodeType === Node.TEXT NODE { texts.push node.textContent ?? "" ; } else if node.nodeType === Node.ELEMENT NODE { texts.push ...extractTextNodes node as Element ; } } ; return texts; } The extracted context is typically 200 to 400 tokens — clean, structured, and representative of what the post actually says. This keeps API costs predictable and response generation fast. There's no way to make a content script robustly stable against DOM changes in a host page you don't control. LinkedIn deploys frontend changes regularly, and CSS class names can shift. We partially mitigate this with attribute-based selectors where possible — data- attributes tend to be more stable than utility class names — and by maintaining a small compatibility shim that detects structural changes and reports them. When the extension breaks on a LinkedIn update, we want to know within hours, not days. The real answer is humility: DOM scraping is inherently fragile, and the architecture needs to be designed with that fragility in mind rather than pretending it won't happen. Parvej Shah is a Lead Full-Stack Web Developer & Platform Architect based in Dhaka, Bangladesh. Explore full architecture case studies and production code at parvejshah.com.