Web Platform & Browser APIs Interview Questions

Web Storage stores only strings. The number 42 is coerced to the string "42" on write, and getItem returns a string (or null for a missing key). Serialize structured data with JSON.stringify on write and JSON.parse on read.

sessionStorage is scoped to a single tab/browsing context and is cleared when that tab closes, so other tabs cannot see it. localStorage is the one shared across all tabs of the same origin and persists until explicitly cleared.

popovertarget only does something when its target is an actual popover — i.e. the element carries the popover attribute. Here the <div> has hidden but not popover, so the button controls nothing and the click is a silent no-op. Fix: <div id="menu" popover> (and drop the manual hidden/display:none — a popover is hidden by default and the browser manages its visibility in the top layer). popovertarget correctly references the id, a <button> is a valid invoker, and popover invoker buttons don't submit forms.

setItem(key, value) writes a string entry and getItem(key) reads it (returning null for a missing key). Both store strings only — serialize objects with JSON.stringify first. removeItem(key) deletes one entry and clear() empties the store.

The popover attribute marks the element as a popover (hidden until invoked, shown in the top layer). A button with popovertarget="<id>" toggles it with no JavaScript. The imperative equivalents are showPopover(), hidePopover(), and togglePopover(), plus the :popover-open pseudo-class and beforetoggle/toggle events.

fetch only rejects on network failures (DNS error, offline, aborted, CORS block). Any completed HTTP response — including 404 or 500 — resolves the promise. You must check response.ok (or response.status) yourself and throw to treat error statuses as failures.

Long polling inverts ordinary request/response timing: the client sends a normal HTTP request, but the server deliberately does not answer until it has something to deliver (or a server-side timeout fires, returning an empty response). The moment a response arrives, the client issues the next request, so there is almost always one request "parked" on the server — that's the pending-for-seconds-then-instantly-replaced pattern in the network tab. Short polling looks different: requests complete immediately and recur on a fixed interval, wasting round trips when nothing has changed. A WebSocket would appear as a single upgraded connection, not a stream of separate HTTP requests. Long polling remains a useful fallback where WebSockets or SSE are blocked by an intermediary, because every hop sees only ordinary HTTP requests.

An auto popover renders in the top layer (escaping z-index/overflow/clipping traps that plague hand-rolled menus), gets light-dismiss for free (outside click or Esc), and participates in a one-at-a-time stack so opening an unrelated auto popover closes the others. What it deliberately does NOT do is trap focus or make the background inert — popovers are non-modal by design. If you need a modal that blocks the rest of the page, that's <dialog>.showModal(), not a popover.

When shown, a popover is promoted to the top layer — a browser-managed layer that sits above the entire normal document, outside every stacking context and clipping ancestor. That is exactly the problem it solves: tooltips, menus, and dropdowns built with ordinary positioned <div>s get clipped by overflow: hidden parents or lose z-index wars, while a top-layer popover (like a modal <dialog>) is immune to both.

fetch resolves with a Response; res.json() returns a promise that resolves to the parsed body, so the second .then receives { count: 5 } and logs data.count, which is 5. The .catch only runs on a network failure or a JSON parse error, neither of which occurs here.

Passing the controller's signal to fetch ties the request's lifetime to the controller. controller.abort() runs synchronously right after the request starts — long before the slow endpoint responds — so the fetch promise rejects and the .then never runs. The rejection reason is a DOMException whose name is "AbortError", so the .catch logs AbortError. This is the standard way to cancel in-flight requests (e.g. abandoning a stale search-as-you-type request); note that abort produces a rejection, not a resolved response, so it flows through the same path as a network failure.

The choice is about dismissal semantics. auto suits menus, dropdowns, and tooltips that should close when the user clicks away; manual suits UI that must stay put until the code or the user explicitly dismisses it. Both render in the top layer either way.

WebSocket and SSE differ on three real axes: duplex direction (WebSocket both ways, SSE server-to-client only), payload type (WebSocket binary-capable, SSE text-only), and reconnection (SSE's EventSource retries automatically, WebSocket leaves it entirely to your code). The proxy claim is backwards: SSE, being ordinary long-lived HTTP, passes through more intermediaries unmodified, while WebSocket's Upgrade handshake is exactly the kind of thing some corporate proxies and older infrastructure block — one real reason to keep SSE or long polling as a fallback.

Structured clone — the algorithm postMessage uses to copy data across the thread boundary — has an explicit list of cloneable types, and DOM nodes aren't on it (neither are functions). Passing one throws a synchronous DataCloneError immediately, before any message is sent. There's no way to hand a live DOM node to a worker at all, since workers have no DOM access regardless; the fix is always to extract the data you actually need (text, attribute values, a serializable object) and send that instead. The other options describe failures this code doesn't have: getElementById finding the element is assumed by the scenario, postMessage is routinely called from the main thread to a worker, and relative worker URLs are the normal case.

Each stage gates the next: a worker can't install before it's registered, can't activate while an old worker still controls a page (that's what waiting protects against — no mixing old and new logic on one open page), and doesn't control anything until activation completes. This is exactly why refreshing a tab isn't enough to pick up a new service worker version — the outgoing page is still 'controlled' by the old worker during that very reload, so the new one stays in waiting unless the app calls skipWaiting()/clients.claim() to force through.

A Web Worker runs script on a background thread, so long computations don't block the UI. It has no access to the DOM, window, or document; it communicates with the page only via postMessage and the message event, and data is copied (structured clone) or transferred.

It does not break, but you must guard it: document.startViewTransition is simply undefined in unsupporting browsers, so calling it throws. The standard pattern feature-detects — if (!document.startViewTransition) { updateDOM(); return; } document.startViewTransition(updateDOM); — so the DOM still updates everywhere, just without the animation where it isn't supported. That's progressive enhancement: the transition is a visual upgrade, never a requirement for the content to change.

The DOM is mutated on line 2, before startViewTransition runs, so by the time the API captures its 'old' snapshot the panel already shows the new content — old and new states are identical and there is nothing to animate. The mutation must happen inside the callback: document.startViewTransition(() => { panel.innerHTML = html; });. The empty callback on line 3 does no work at all.

The key precondition trips people up: registering a worker does nothing to the page that registered it until that page is controlled, which normally only happens on the next navigation after the worker activates (or immediately, if the worker calls clients.claim()). From then on, requests within the worker's scope dispatch a fetch event in the worker; the handler answers with event.respondWith(...) — commonly caches.match(request) with a fetch(request) fallback. Not calling respondWith is a deliberate escape hatch: the request falls through to the network exactly as if no worker existed.

Workers share no memory with the main thread, so all communication is message-passing. Structured clone copies most data; the transferable-objects optimization hands ownership of a buffer to the other side without copying.

Unnamed content gets a single root cross-fade; named elements are lifted into their own transition groups so the browser can animate them independently. Names must be unique among elements present at a given snapshot, which is why you often assign them dynamically to just the pair being morphed.

The sequence is the whole reason the DOM mutation must live in the callback: old snapshot → callback mutates the DOM → new snapshot → animate between them. The ViewTransition object exposes this as promises — updateCallbackDone resolves after the callback, ready once the pseudo-element tree is built and the animation is about to run, and finished when it completes.

MutationObserver callbacks are delivered as microtasks, batched: the observer queues a record when the mutation happens, but the callback doesn't run until the current synchronous script finishes and the microtask queue drains. So the synchronous console.log('1') and console.log('2') both run first — the appendChild in between only queues a mutation record, it doesn't invoke the callback inline — and 'observed' logs last, after the script completes. This is a deliberate change from the old, removed Mutation Events API, which fired synchronously per-mutation and could recursively trigger more mutations mid-handler; batching into one microtask callback with an array of records avoids that entirely.

IndexedDB treats schema changes as a distinct, versioned event: opening with a higher version number is the only trigger for upgradeneeded, and the versionchange transaction it provides is the only context where the database structure can change. This is why IndexedDB code always tracks and bumps a version number rather than checking 'does this store exist yet' at runtime — the browser enforces the schema-change boundary for you.

The callback is a synchronization point, not just a convenience. The browser must own the timing so it can sandwich the DOM mutation between an old-state capture and a new-state capture; surrendering that ordering (mutating outside) destroys the 'from' state the animation interpolates out of. This is also why the callback can return a promise — the browser waits for the new state to settle before capturing it.