From 2e433ad088cbd4136809d4e3fa89d14dbe9f4e6e Mon Sep 17 00:00:00 2001 From: Bernardo Magri Date: Thu, 16 Jul 2026 10:29:09 +0100 Subject: [PATCH] docs(agent): file #143 (rofi keeps the row number) and #144 (migration: profiles.ini) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit #143 — Bernardo: type `ca`, move onto ChatGPT, backspace once, and the highlight sits on GHex while Slack is row 1. Upstream rofi 2.0.0, not our config: listview_set_num_elements() re-asserts the OLD index — `listview_set_selected(lv, lv->selected)` — and set_selected only clamps (`MIN(selected, req_elements - 1)`). So the ROW NUMBER survives a refilter, never the entry, and nothing checks it still matches the query. Typing more hides it; backspacing exposes it. No option controls it (auto-select is a different feature). Correction to the report: it is the listview widget, so every rofi surface does it — drun is just where the list is long and (sort = true) reorders each keystroke. #144 — "I lost all my thunderbird accounts and emails" was a missing profiles.ini. The profile was untouched: 30 GB, 64 account prefs, 19 GB ImapMail, last used 2026-06-26; TB found no profile list and made an empty one. Fixed live in ~8 lines (backup kept). MIGRATION.md already warns about this exact class for Chromium extensions but never names Mozilla's profiles.ini — which deserves its own bullet because it is the inverse: no data lost, looks catastrophic, and the tempting fix (restore a snapshot over a good 30 GB profile) is the actual risk. Firefox here has the same fingerprint (hm-bak from Jun 2025 names a different profile than today's ini) — left alone; repointing it is Bernardo's call. Co-Authored-By: Claude Opus 4.8 --- agent/BACKLOG.md | 94 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) diff --git a/agent/BACKLOG.md b/agent/BACKLOG.md index fa38b95..8ddf37f 100644 --- a/agent/BACKLOG.md +++ b/agent/BACKLOG.md @@ -198,6 +198,100 @@ scaled splash — the LUKS prompt especially, since a passphrase box half off the panel is the failure that matters. Pass = docked boot + shutdown centred on both heads; undocked unchanged. +### 144. MIGRATION.md must warn about Mozilla `profiles.ini` — it reads as total data loss + +Bernardo 2026-07-16: "it seems that I have lost all my thunderbird accounts and +emails!" — nothing was lost. `~/.thunderbird/bernardo` was intact the whole +time: **30 GB**, 64 account/identity prefs, 19 GB `ImapMail` + 9.7 GB `Mail`, +last used 2026-06-26. Only `profiles.ini` was gone, so on first launch after the +migration Thunderbird did what it always does with no profile list — created an +empty one (`wc966grk.default`, 16 MB) and pointed itself at it. Fixed by +rewriting `profiles.ini` to `Path=bernardo` + `Default=1` (old file kept as +`profiles.ini.bak-*`); Thunderbird reopened the real profile and went straight +into its Duo login. **Total fix: one 8-line file.** + +This is the **same class** MIGRATION.md's "Browser profiles" bullet already +covers — a file Home Manager used to manage disappears, and the app reads its +own absence as "first run" — but that bullet only names Chromium extensions. +The Mozilla case deserves its own warning precisely because it is *louder and +less dangerous*: Chromium silently deletes extension data (real loss, looks +minor); Thunderbird touches nothing and merely looks away from 30 GB (no loss, +looks catastrophic). A user who believes the second one will go restore a +snapshot over a perfectly good profile — the recovery is the risk here. + +Firefox on this box shows the same fingerprint, unreported because he browses in +Chromium: `~/.mozilla/firefox/profiles.ini` (Jul 12) points at +`u9p8fdhh.default` (101 MB, created at migration), while +`profiles.ini.hm-bak` — Home Manager's own backup, dated **Jun 2025** — points +at `lfr4aapb.default` (129 MB, last used 2025-09-07), and a third profile +`default` (290 MB) was last used 2026-03-02. So the pattern is Mozilla-family, +not Thunderbird-specific. **Do not repoint Firefox without asking Bernardo** — +u9p8fdhh has been in use since Jul 14 and merging profiles is his call. + +**What to write** (docs only, no code): in MIGRATION.md's Phase-0/browser +section — before first launch of any Mozilla app, check that +`~/.thunderbird/profiles.ini` and `~/.mozilla/firefox/profiles.ini` exist and +name your real profile directory; if an app opens empty, **do not restore a +snapshot** — `ls ~/.thunderbird` first, and if a fat profile dir is sitting +there, it is a one-file fix. Include the working `profiles.ini` shape and the +`Name=`/`Path=`/`Default=1` semantics. + +**Root cause is unproven and probably not worth chasing:** zero HM generations +survive on disk to show whether HM ever managed that file (the Firefox +`.hm-bak` proves it did there, in 2025), and the snapshot check needs sudo. The +warning is worth writing either way — it costs nothing and it is the difference +between a one-line fix and a restore that overwrites good data. + +### 143. Rofi keeps the selected *row number* when the search changes, so the highlight lands on an unrelated entry + +Bernardo 2026-07-16, and his repro is exact: open the app menu, type `ca`, move +the selection two items right (onto ChatGPT), press backspace once (query is +now `c`). The list re-expands — first entry is now Slack — but the highlight +stays on the **third row**, which is now GHex, an app that has nothing to do +with what he typed. Enter at that moment launches the wrong thing. + +**Cause — upstream rofi (2.0.0, `source/widgets/listview.c`), not our config.** +A filter change ends in `listview_set_num_elements()`, which does not reset the +selection; it re-asserts the old one: + +```c +lv->req_elements = rows; +listview_set_selected(lv, lv->selected); /* the *previous* index */ +``` + +and `listview_set_selected()` only clamps it to the new bounds: + +```c +lv->selected = MIN(selected, lv->req_elements - 1); +``` + +So what is preserved is the **row number**, not the entry — nothing checks that +row 2 still holds the thing that was selected, or that it matches the query at +all. Typing *more* hides this (the list shrinks, the clamp usually drags the +highlight along); **backspacing exposes it**, because the list grows back +underneath a stationary index. There is no option for it: `-dump-config` has +nothing about selection-on-refilter, and `auto-select` is a different feature +(it fires only when exactly one row survives). + +**One correction to the report:** it is not the app menu. `listview` is the +widget behind **every** rofi surface we ship, so our text menus (Recovery, +System, Preferences…) do the same. It is merely far more visible in drun, where +the list is long and — because we set `sort = true` — reorders on every +keystroke, so a stationary index points somewhere new each time. In a short +text menu you would probably see it and correct without noticing why. + +**Options.** (a) Report upstream and wait — this is a widget-level bug, and the +fix belongs there: reset to row 0 in `rofi_view_refilter_real` when the filter +text actually changed (the "keep the index" behaviour is presumably wanted for +non-filter reloads, so it cannot simply be deleted). (b) Carry the patch +ourselves in an overlay — a few lines, but it means **building rofi from source +on every user's machine**: our derivations are in no binary cache (#120's +gotcha), so this trades a real install/rebuild cost for it. (c) Live with it +and say nothing — the status quo, and the reason Bernardo hit it cold. +Recommend (a) + (b) together if the patch stays small: file it upstream, carry +it until it lands, delete on the release that fixes it. `[human]` for whether +a source-built rofi is a price worth paying. + ### 142. A rebuild while docked undoes dock mode (the panel comes back, a workspace jumps to it) Bernardo 2026-07-16: every rebuild while docked lands in the undocked state —