Critical issue; Rainbow-buffering-mouse-icon

Note:
Before bug reporting, please make sure you have tried the latest (alpha) version of BetterTouchTool and that you have already tried to restart your system :-). If you encounter a crash, please attach a crash log from the macOS Console.app's "Crash Reports" section.

->OK


Describe the bug

# BTT 6.773 — synchronous Core Data fetch on the main thread causes system-wide input stalls

## Pre-report checklist

- **Restart tried — does not help.** This Mac was rebooted on 2026-09-06 at 12:10:46.

BTT diagnostic reports exist both before that reboot (07:12) and after it

(12:16, 12:49, 16:00), so the problem survives a restart.

- **No crash log is available, because BTT does not crash — it hangs.** The system

produced 4 `cpu_resource.diag` and 3 `hang` reports for BTT and zero crash reports.

The `hang` reports attached here are the corresponding artifact.

- **This IS the latest alpha.** The alpha feed declared in the app bundle

(`SUFeedURLHighSierraAlpha` = `https://updates.folivora.ai/highsierraalpha.xml\`) currently

publishes 6.773 / build 2026090402, dated Fri 04 Sep 2026 — the exact build installed here.

The release channel (`appcast.xml`) is still on 6.748, so this machine is running ahead of

the stable channel, on the newest available alpha.

## Environment

- BetterTouchTool **6.773 (2026090402)**

- macOS 26.6.2 (build 25G83), MacBookPro18,4 (M1 Max, 10 cores), 32 GB

- Settings store was migrated from 6.443 during the update

## Symptoms

All of these are **system-wide**, not limited to BTT's own windows:

- Keystrokes stall for roughly 3 seconds immediately after switching applications

- Korean/English input-source switching is delayed by several hundred milliseconds

- Periodic beachballs; typing freezes completely for seconds at a time.

**A three-finger tap on the trackpad triggers this within seconds, reliably.**

- Quitting BTT makes all three disappear at once. Launching BTT alone, with every other

input-related app closed (Karabiner, Hammerspoon, Logitech Options+, CheatSheet, RunCat,

Only Switch), reproduces all three.

## Steps to reproduce

The most reliable trigger on this machine is a **three-finger tap on the built-in trackpad**:

1. Launch BTT with the settings store described below (346 entities / 209 enabled triggers).

2. Let it settle for 30-60 seconds.

3. Three-finger tap the trackpad.

4. Within a few seconds the beachball appears and **all keyboard input stops system-wide**

for several seconds. The BTT window itself becomes unresponsive.

Switching applications, and switching the macOS input source (Korean <-> English), cause the

same stall in a milder form.

Important: **disabling all 71 gesture triggers does not prevent it.** A three-finger tap still

produces the stall with every gesture trigger turned off, which suggests the cost sits in the

gesture-recognition / notification-driven fetch path rather than in executing a gesture's

assigned action.

BTT's own log around these events (attached logs contain 85 `tiptap` lines and 24

`three finger click block` lines):

```

LMDrag|dragged after three finger click block

tiptap|candidate contact (resting finger down 1.94s)

tiptap|rejected: fingers 0.57 apart (max 0.55)

tiptap|rejected: resting finger moved / palm heuristics (f1 0.00/0.48 f2 0.52/0.24 ...)

```

Relevant trackpad settings on this machine:

```

BTTThreeFingerTipTapMinSpread = 0.03

BTTTpThreeFingerSwipeSensitivity = 0.3

tpThreeFingerDoubleTapDelay = 0.5

BTTAllowThumbIfAllFingersArePlacedSimultaneously = 1

```

Trackpad: built-in on MacBookPro18,4.

## Onset

The machine updated BTT 6.443 → 6.773 on 2026-09-06 at 06:54. The first BTT diagnostic

report on this machine is from 07:12 the same morning. `/Library/Logs/DiagnosticReports`

retains entries for other processes back to 09-01, and contains **no BTT reports at all

before the update**.

## Kernel evidence

Four `cpu_resource.diag` reports, each hitting the 90-second CPU limit:

| Time | CPU time / window | Average |

|-------|-------------------|---------|

| 07:12 | 90 s over 176 s | 51 % |

| 12:16 | 90 s over 90 s | 100 % |

| 12:49 | 90 s over 103 s | 87 % |

| 16:00 | 90 s over 140 s | 64 % |

All four heaviest stacks bottom out in the same place — a synchronous Core Data fetch

running on the **main thread**:

```

-[NSApplication run] → main dispatch queue

→ _CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER_ (in 3 of the 4 reports)

→  BetterTouchTool

  →  -\[NSManagedObjectContext executeFetchRequest:error:\]

    →  -\[NSSQLCore executeRequest:withContext:error:\]

      →  -\[NSSQLiteConnection performAndWait:\]

        →  sqlite3_step  →  sqlite3VdbeExec

```

In the 16:00 report, **22 of 23 samples** are inside that fetch.

The `On Behalf Of` field names the processes whose notifications drove the work:

**iTerm2, KIM_Extension (the macOS Korean input method), and Only Switch**. This lines up

with the input-source symptom — every input-method event appears to trigger a fetch.

BTT's own log shows the corresponding cache work, e.g.:

```

BTTItemTrigger: cache updated - 0 trigger row(s) fetched (fetch error: (null))

```

## Why this stalls the entire system

BTT holds a CGEventTap. While its main thread is blocked inside the fetch, key events

cannot be forwarded, so every application on the machine is affected — which is why the

symptom presents as an OS-level input problem rather than a BTT problem.

## The store is small

The settings store holds **346 entities total (209 enabled triggers)**. A single fetch over

this should take microseconds, and the indexes are intact — 26 indexes on `ZBTTBASEENTITY`,

identical to a store BTT creates from scratch. `PRAGMA integrity_check` returns `ok`.

The cost therefore does not appear to come from any individual query being slow, but from

the fetch being executed **once per incoming notification, synchronously, on the main

thread**, at a rate driven by unrelated processes.

## Ruled out locally

- iCloud sync disabled → still reproduces

- All 71 gesture triggers disabled → still reproduces (so it is not action execution)

- No key-sequence triggers configured (0)

- Clipboard manager holds only 33 clips

- Store integrity `ok`; index set identical to a freshly created store

- Other input-tapping apps quit → symptoms gone; BTT alone → symptoms return

## Attached

- `diagnostic_reports/` — 4 × `cpu_resource.diag`, 3 × `hang`

- `btt_logs/` — BTT's own logs covering the period


Affected input device (e.g. MacBook Trackpad, Magic Mouse/Trackpad, Touch Bar, etc.):

Macbook Trackpad: 3fingers-tap function


Screenshots
If applicable, add screenshots to help explain your problem. (You can just paste or drag them here)


Device information:

  • Type of Mac: Apple M1 Max 32GB-Memory

  • macOS version: Tahoe Version 26.6.2 (25G83)

  • BetterTouchTool version: 6.773


Additional information (e.g. crash logs, related issues, etc.):


this sounds a lot like an issue with the legacy experimental icloud/dropbox sync. You mentioned you disabled that, but it still shows up in the logs, did you restart BTT after disabling it?

//edit: ah your later logs show it disabled, but the hang diagnostics are all before that. Are you sure the issue still occurs with the sync disabled?