Interview Questions: Browser Functionalities (BOM, Storage, Fetch)

Model answers for BOM vs DOM, location / history, Web Storage vs cookies, and fetch error handling.

How to use this material (instructions)

1. Read lessons — README.md → 1.16.a–1.16.d.
2. Practice out loud — 1–2 minutes each.
3. Exercises — 1.16-Exercise-Questions.md.
4. Quick revision — 1.16-Quick-Revision.md.

---

Beginner (Q1–Q4)

Q1. What is the Browser Object Model (BOM)?

Why interviewers ask: Separates browser services from document tree APIs.

Model answer:

The BOM is the set of objects the browser exposes for navigation, environment, timers, dialogs, and more — centered on window. The DOM (document, elements) is how you manipulate page content. In practice document is reachable as window.document, so the boundary is conceptual: DOM standards vs broader Web IDL / HTML specs for window, navigator, location, history.

---

Q2. Explain localStorage vs sessionStorage.

Why interviewers ask: Tab-scoped UI state vs persistent preferences.

Model answer:

Both are same-origin key–value Web Storage APIs with string values. localStorage persists until cleared by code or the user; it is shared across tabs/windows of the same origin. sessionStorage is scoped per browser tab (top-level browsing context) and is cleared when the tab closes. Use sessionStorage for wizard steps or ephemeral UI; localStorage for theme, language, or client caches that should survive restarts.

---

Q3. Does fetch throw when the server returns 404?

Why interviewers ask: Extremely common bug — silent failures.

Model answer:

Usually no. fetch resolves with a Response whose ok is false and status is 404. The promise rejects mainly on network errors (offline, DNS failure, blocked requests). You must if (!res.ok) throw … or branch before parsing. CORS failures can surface as network errors or opaque responses depending on mode — another interview talking point.

---

Q4. What is window.location used for?

Why interviewers ask: URL manipulation and redirects are daily tasks.

Model answer:

window.location is a Location object describing the current URL (href, pathname, search, hash, …) and supporting navigation: assigning location.href, assign, replace, and reload. It is how SPA code reads query params or triggers navigations. location.replace is used when you do not want the current page to remain in history (e.g. post-login redirect patterns).

---

Intermediate (Q5–Q7)

Q5. Compare cookies to localStorage for storing a session token.

Why interviewers ask: Security architecture (XSS vs CSRF trade-offs).

Model answer:

localStorage is readable by any JavaScript on the page — if XSS exists, attackers can exfiltrate tokens. HttpOnly cookies are not readable from JS, reducing XSS token theft, but cookies are sent automatically on requests — you need CSRF protections (SameSite, tokens) for state-changing requests. Many apps use short-lived access tokens in memory, refresh via HttpOnly cookie, or full cookie sessions — choice depends on threat model and architecture.

---

Q6. What is history.pushState and what must you handle after using it?

Why interviewers ask: SPA routing fundamentals.

Model answer:

history.pushState(state, title, url) updates the URL and adds a history entry without loading a new document from the network. The page must update its own UI to match the new URL. You should listen for popstate to synchronize UI when the user navigates Back/Forward, otherwise the URL and displayed content desync. Title parameter is largely ignored; use document.title explicitly.

---

Q7. Why are Web Storage values strings?

Why interviewers ask: Serialization and type bugs.

Model answer:

The Storage interface stores DOMString values. Numbers and objects are coerced to strings ([object Object] for naive object assignment). Developers JSON.stringify objects and JSON.parse on read, with try/catch for corrupted entries. This is simpler than IndexedDB for small prefs but not a typed database.

---

Advanced (Q8)

Q8. Outline the steps to safely fetch JSON from an API.

Why interviewers ask: Production-ready error handling.

Model answer:

1. await fetch(url, options) inside try/catch for network failures.
2. Check response.ok (or exact status) — throw or return structured error on 4xx/5xx.
3. await response.json() once — handle parse errors if body is not JSON.
4. Validate shape of JSON (schema, TypeScript, runtime checks) before using in UI.
5. For cross-origin APIs, ensure server CORS headers allow the browser origin.

---

Quick-fire

#	Question	One-line
1	Global object in browser	window
2	Tab-only storage	sessionStorage
3	Read JSON from fetch	await (await fetch(url)).json() (after ok check)
4	Navigate without new history entry	location.replace(url)

---

← Back to 1.16 — README