Use JavaScript in the browser to manipulate the DOM, handle events and make asynchronous requests

<button id="load">Load users</button>
<ul id="users"></ul>

const button = document.getElementById("load");
const list = document.getElementById("users");

button.addEventListener("click", async () => {
  try {
    const response = await fetch("/api/users");
    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }
    const users = await response.json();
    list.innerHTML = "";
    for (const user of users) {
      const item = document.createElement("li");
      item.textContent = user.name;
      list.appendChild(item);
    }
  } catch (err) {
    list.innerHTML = `<li>Error: ${err.message}</li>`;
  }
});

Walkthrough: select the button and the list with getElementById, attach a click handler with addEventListener, fetch the JSON over HTTP, and rebuild the list. await pauses inside the async function until the response and JSON parse complete. Setting textContent (not innerHTML) prevents XSS if a user name happens to contain HTML.

Markers reward a real event listener (not inline onclick), fetch with await, error handling for non-2xx responses, and use of textContent rather than innerHTML for user-controlled data.

document.getElementById("total").textContent = "Done";

Marking criteria: 1 mark for correctly selecting the element by id, 1 mark for using textContent (not innerHTML) to set the text safely.

const agree = document.getElementById("agree");
const submit = document.getElementById("submit");

agree.addEventListener("change", () => {
  submit.disabled = !agree.checked;
});

Marking criteria: 1 mark for selecting both elements, 1 mark for listening to the change event, 1 mark for correctly toggling disabled based on agree.checked.

fetch() returns a Promise immediately and hands control back to the calling code before the network request completes, exactly as the diagram shows the Promise sitting in a "pending" state while the request travels to the server and back. Because JavaScript in the browser is single-threaded and non-blocking, any code written directly after the fetch() call (without await or a .then() callback) executes straight away, using the still-unresolved Promise object rather than the eventual response data. Only code inside an await expression (inside an async function) or inside a .then() callback attached to the Promise is guaranteed to run after the response has arrived and been parsed.

Marking criteria: 1 mark for stating that fetch() returns a Promise immediately, 1 mark for linking this to the diagram's pending state, 1 mark for explaining that the main thread continues executing subsequent code without waiting, 1 mark for correctly stating that only await/.then() code runs after resolution.

The code is vulnerable to cross-site scripting (XSS). Because name is taken directly from a URL query parameter, an attacker can craft a link where name contains an HTML payload such as <img src=x onerror=alert(1)>. Assigning this string to innerHTML causes the browser to parse it as HTML rather than plain text, so the injected onerror handler executes in the victim's browser session, potentially stealing cookies or session tokens.

Safe rewrite:

document.getElementById("greeting").textContent = "Hi " + name;

textContent inserts the string as literal text; any HTML-looking characters are displayed as plain characters, not parsed as markup, which removes the injection vector entirely.

Marking criteria: 1 mark for naming the vulnerability (XSS), 1 mark for explaining how untrusted input flows into innerHTML, 1 mark for a correct working fix using textContent, 1 mark for explaining why the fix closes the vulnerability.

Awaiting each fetch() one after another means the browser waits for each request to fully complete before starting the next, so the total time is the sum of the three: $220 + 180 + 260 = 660$ ms.

If the three requests do not depend on each other's results, they can be started at the same time and combined with Promise.all, which waits for all of them to settle concurrently rather than sequentially:

const [a, b, c] = await Promise.all([
  fetch("/api/counts/a").then(r => r.json()),
  fetch("/api/counts/b").then(r => r.json()),
  fetch("/api/counts/c").then(r => r.json()),
]);

Because the requests overlap, the total wait time becomes the time of the SLOWEST request, not the sum: $\max(220, 180, 260) = 260$ ms, a saving of $660 - 260 = 400$ ms.

Marking criteria: 1 mark for identifying that sequential await calls sum their times (660 ms), 1 mark for correctly using Promise.all in code, 1 mark for explaining that concurrent requests are bounded by the slowest one, 1 mark for the correct concurrent time (260 ms), 1 mark for the correct time saved (400 ms).

Issues to evaluate.

1. No debouncing. Firing a request on every keystroke floods the server and wastes bandwidth; a user typing "laptop" fires six requests when only the last is useful.
2. Race condition. Because requests can resolve out of order, an earlier keystroke's slower response can arrive after a later one and overwrite the newer, more relevant results.
3. XSS via innerHTML. Rendering server text with innerHTML executes any HTML/script content embedded in it, which is dangerous if the search results ever echo back user-supplied text (e.g. "no results for <script>").

Rewritten implementation.

const input = document.getElementById("search");
const results = document.getElementById("results");
let timeout = null;
let requestId = 0;

input.addEventListener("input", () => {
  clearTimeout(timeout);
  const thisRequest = ++requestId;
  timeout = setTimeout(async () => {
    const q = encodeURIComponent(input.value);
    const response = await fetch(`/api/search?q=${q}`);
    const items = await response.json();
    if (thisRequest !== requestId) return; // stale response, discard
    results.innerHTML = "";
    for (const item of items) {
      const li = document.createElement("li");
      li.textContent = item.title;
      results.appendChild(li);
    }
  }, 300);
});

Why each change fixes an issue. The 300 ms setTimeout debounce collapses rapid keystrokes into a single request once typing pauses. The requestId counter tags each request and discards any response that is not the most recent, eliminating the race condition. Building list items with createElement and textContent instead of innerHTML renders result text safely regardless of its content.

Marking criteria: 1 mark for identifying the missing debounce, 1 mark for identifying the race condition, 1 mark for identifying the XSS risk, 1 mark for a correct debounce fix, 1 mark for a correct stale-response guard, 1 mark for a correct textContent/createElement fix.