Right after I posted that config improvement, I ran the BTT auto-update, and on restart- the menu-statusbar floating window stopped working! Here is AI’s review of that breakage & fix:
Bug Report: Status Item Bar Floating Menu Config Lost After BTT Update/Restart
Problem
After a BTT update that triggered a restart, the floating menu–based status item bar (based on the floating_status_item_bar example preset) stopped appearing entirely. Hovering at the top-right of the screen no longer showed the status bar.
Environment
- Preset: a customized version of the
floating_status_item_bar example preset, renamed to sequoia_status_item_bar
- The preset was synced (BTT sync feature was active)
What Was Broken (3 issues found)
1. StatusItemBar floating menu (356DDAB3) — config gutted
The BTTMenuConfig was stripped from 39 properties down to ~7. All of these were lost:
BTTMenuVisibility: 1 (hidden by default, shown on hover) — without this the menu doesn't know it should be hiddenBTTMenuPositioningType, BTTMenuPositionRelativeTo, BTTMenuAnchorMenu, BTTMenuAnchorRelation — positioningBTTMenuWindowLevel, BTTMenuWindowLevelManual — z-orderingBTTMenuFrameWidth, BTTMenuFrameHeight — dimensionsBTTMenuSizingBehavior, BTTMenuCloseOnOutsideClick, BTTMenuElementIdentifier — behavior- Plus ~25 more styling/layout properties
The menu name was also reset from "StatusItemBar" to "no-name-356DDAB", and the BTTMenuElementIdentifier (used by the hover actions to reference this menu) was lost.
2. HoverRecognitionOverlay (B7C825A4) — completely deleted
This entire floating menu trigger was missing from the current config. In the original preset it's the invisible overlay at the top-right of the screen that:
- On hover start (actionCategory 1): fires
Show Floating Menu (action 386) targeting "StatusItemBar"
- On hover end (actionCategory 4): fires
Hide Floating Menu (action 387) targeting "StatusItemBar"
- Contains a "Hover Recognition Dummy Item" (standard item 773) as the hover hit area
Without this trigger, there was no mechanism to show or hide the StatusItemBar at all.
3. BTT Status Item action — emptied
The BTT status item (16307F2B, the BetterTouchTool icon within the status bar widget) had a single action (4CBD98D2) that was a skeleton — it contained only:
{
"BTTTriggerBelongsToPreset": "Synced",
"BTTTriggerParentUUID": "16307F2B-...",
"BTTIsPureAction": true,
"BTTUUID": "4CBD98D2-..."
}
No BTTPredefinedActionType, no BTTAdditionalActionData, no BTTPredefinedActionName — a completely empty action that does nothing.
Evidence Regarding Root Cause (Sync Conflict?)
There is circumstantial evidence pointing to a sync conflict between the "Synced" preset and the local preset during the update-triggered restart:
Suggestive evidence:
- The empty action (
4CBD98D2) had BTTTriggerBelongsToPreset: "Synced", while its parent trigger (16307F2B) had BTTTriggerBelongsToPreset: "sequoia_status_item_bar". This cross-preset parent-child relationship suggests the sync process created or overwrote an action from one preset into a trigger belonging to a different preset, stripping its properties in the process.
- The StatusItemBar menu's config was reduced to a minimal subset (mostly just spacing/padding/blur defaults), consistent with what a "blank" or "reset" menu item might look like — as if the synced version had an empty template that overwrote the local config.
- An entire top-level trigger (HoverRecognitionOverlay) was deleted, which wouldn't happen from a simple config format migration.
What we can't prove:
- We don't have a before/after snapshot bracketing the exact update moment.
- It's possible the update itself (not sync) performed a migration that dropped unrecognized config keys.
- The preset was renamed from
floating_status_item_bar to sequoia_status_item_bar by the user, which could interact with sync identity matching.
Bottom line: The cross-preset BTTTriggerBelongsToPreset mismatch on the empty action is the strongest signal that sync was involved. A normal update migration wouldn't typically reassign an action's preset ownership. But it's correlation with a strong smell, not definitive proof.
Fix Applied
- Restored StatusItemBar config — updated
BTTMenuConfig with all 39 original properties, restored the name to "StatusItemBar" and BTTMenuElementIdentifier to "StatusItemBar"
- Recreated HoverRecognitionOverlay — imported the full trigger with all 3 child items (hover start action, dummy item, hover end action) from the original preset file
- Status item bar now appears correctly on hover again
