Making big downloads resumable in Firefox

Original Article ↗ Hacker News Discussion ↗

Firefox’s long-standing unreliability with resuming large downloads prompts complaints, with some users resorting to manual file tricks or external tools like aria2, wget, JDownloader, and classic download managers from the 2000s. Commenters argue that modern browsers still handle interrupted transfers poorly—especially on unstable or high-latency connections—despite decades of prior art in dedicated download software. There is skepticism that simple configuration tweaks truly fix the problem, and broader frustration that browser development prioritizes UI polish over robust fault-tolerant downloading.

Firefox download reliability & related bugs

  • Many commenters report longstanding instability with resumable downloads in Firefox, sometimes going back to the mid‑2000s, while others say they routinely resume downloads without issues.
  • Some suggest reproducing problems systematically and inspecting source code, but others note the difficulty of knowing where to look.
  • Additional Firefox issues are highlighted: broken “modal” search highlighting, awkward behavior of “Whole Words” vs. “Match Diacritics,” downloads via service workers canceling at exactly 30 seconds, and UI freezes under CPU load.

Workarounds & external download tools

  • Strong preference by many to bypass browsers entirely for large files: aria2, wget -c, curl, axel, JDownloader, IDM/NDM, and historical tools like GetRight, Go!Zilla, FlashGet, DownThemAll, etc.
  • Pros cited: robust resume, multiple connections, better handling of flaky networks, integration with cookies (e.g., --load-cookies, browser extensions), and persistent downloads.
  • Cons: some tools are seen as bloated, slow, or “shady” (bundled software, non‑open components), and not trivial to use when logins, captchas, or wait timers are involved.

One-time URLs & resumption semantics

  • A manual trick is described: restart a download to get a new .part file, swap in the old partial file, then resume.
  • Caveat: if the server now serves a different file, Firefox will splice mismatched content, silently corrupting the result; hashes are recommended when available.
  • Discussion notes that one‑time URLs returning 410/400 on reuse make robust in‑browser resumption hard, since the browser can’t know two URLs represent the same file.

Network conditions & engineering priorities

  • Several comments argue browser engineers implicitly target fast, stable connections and powerful machines, neglecting users with high latency, jitter, or unreliable power.
  • Examples are given from cross‑border links, rural connections, and specific ISPs; this is framed as a socioeconomic blind spot.

Debate on configuration fixes & correctness

  • One commenter claims adjusting network.http.response.timeout helps; another counters this is “placebo,” citing Firefox code paths where the pref is ignored when TCP keepalive is enabled and only applies before the first byte.
  • It’s asserted that Firefox does not do hidden retries beyond this.

Broader browser & AI commentary

  • Frustration that browsers still “struggle” with downloading decades after classic download managers solved it; some feel browser teams prioritize visual polish (rounded corners, minimal chrome) over robustness.
  • Alternatives like dedicated download managers and a new browser project with better download handling are mentioned.
  • There is meta‑discussion about hostility toward LLM usage and about using AI to clone or re‑implement download tools, with security concerns raised about relying on AI‑generated code.