Renderer process crashes permanently on articles containing a <geolocation> tag
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:
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 (<geolocation>), 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 <geolocation> |
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>:
<description><![CDATA[<p>x <geolocation> 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