Renderer process crashes permanently on articles containing a <geolocation> tag

Author: TriptoAfsinCreated Sep 18, 2026Updated Sep 18, 2026

Summary

A single article whose text contains <geolocation> permanently bricks the app. The window opens blank, with no error, and stays blank on every subsequent launch — because the item is persisted and re-parsed at startup. The only way out is to delete the IndexedDB article store.

This has now happened three times in three weeks on the same installation, as a story about the proposed <geolocation> HTML element spread across web-dev feeds (stefanjudis.com, css-tricks.com, javascriptweekly.com).

Root cause

htmlDecode() in src/scripts/utils.ts builds a whole HTML document just to decode entities:

typescript
export function htmlDecode(input: string) {
    var doc = domParser.parseFromString(input, "text/html")
    return doc.documentElement.textContent
}

Feeds writing about the element deliver the name entity-escaped (&lt;geolocation&gt;), sometimes double-escaped. rss-parser decodes that once, so contentSnippet contains the literal text <geolocation>. htmlDecode() then parses that text as HTML, Blink instantiates an element named geolocation, and the renderer process is terminated.

Confirmed in the packaged app (1.2.2, Electron/Chromium) by running three snippets in the renderer:

Snippet Result
new DOMParser().parseFromString("x <geolocation> y", "text/html") renderer killed
new DOMParser().parseFromString("x <foobarbaz> y", "text/html") survives
textarea RCDATA decode of &lt;geolocation&gt; survives

Exit code is 0xC0000409 / -2147483645 (STATUS_BREAKPOINT) — a deliberate Chromium abort, not an exception, so no try/catch or React error boundary can contain it. render-process-gone fires with {"reason":"crashed"}.

It is specific to this element name; <foobar>, <webview>, <video>, <dialog>, <selectmenu>, <script> and <style> in the same position are all harmless.

Minimal reproduction

Subscribe to any feed serving this as an item <description>:

xml
<description><![CDATA[<p>x &lt;geolocation&gt; y</p>]]></description>

The renderer dies as the source is added, and again on every launch afterwards.

Impact

  • Blank window, no error message, no recovery path a normal user could find.
  • Survives restart and reinstall (the data lives in %APPDATA%/fluent-reader).
  • Affects every code path that parses article HTML, including the Feedbin / Fever / GReader / Miniflux / Nextcloud adapters.

Fix

PR incoming: route every text/html parse through one helper that neutralises the tag name with a zero-width space first, so the element can never be instantiated. Verified against all three feeds that triggered it.

Worth considering separately: a render-process-gone handler in the main process, so a future content-triggered renderer crash degrades into a reload rather than a permanently blank window.

Source: yang991178/fluent-reader