fix(desktop): ship a bundle that parses on WebKit without lookbehind (Intel/macOS 12)

[arielhauter]

Summary

Buzz Desktop renders a blank window on Macs whose system WebKit predates Safari 16.4: the shipped bundle contains RegExp lookbehind patterns, and older WebKit fails at parse time, so the frontend never renders. This matches the symptom in #3295, and matters because the project ships and promotes Intel DMGs (#748 added the x86_64 release target; #2090 steers Safari users to the right DMG) while the app declares minimum macOS 10.15.

Four changes make the bundle lookbehind-free:

1. desktop/vite.config.ts — build target ["es2020", "safari15"], so the toolchain lowers syntax for pre-16.4 WebKit.
2. mentionHighlightExtension.ts — rewrite the two mention/channel patterns using a boundary capture group instead of lookbehind, with a prefix-length offset fix in findHighlightMatches.
3. KeyboardShortcutsCard.tsx — replace the lookbehind/lookahead key-combo split with a small splitKeyCombo helper (same behavior).
4. patches/mdast-util-gfm-autolink-literal@2.0.1.patch — the dependency ships pre-bundled code with a lookbehind in the email-autolink pattern; patched via the existing patches/ convention, since a build target cannot rewrite it.

Because the failure is at parse time, one pattern anywhere blanks the whole app — that is why both the build target and the source/dependency rewrites are needed.

Trade-offs, stated honestly: (a) the safari15 target affects all platforms, not only macOS 12; (b) the dependency patch slightly changes email-autolink edge behavior everywhere, relying on the package's boundary guard instead of the lookbehind — the ideal fix is upstream in micromark, this is the interim.

Heads-up: #4701 (open) introduces a new negative lookbehind in the bare-URL pattern; the same portability concern applies there.

Related issue

Relates to #3295 — same blank-render symptom; note the original report is arm64/Safari 17.6, which may be a separate cause. This PR fixes the lookbehind parse failure affecting pre-16.4 WebKit. Before opening I searched existing PRs/issues for "macOS 12", "Intel", "lookbehind" — closest existing PR: none found.

Testing

• grep -rln -E '\(\?<[=!]' over the built Buzz.app Resources: clean.
• just desktop-test: 4,604 tests pass. just desktop-tauri-test: pass.
• Built with just desktop-release-build x86_64-apple-darwin on current main (post-0.5.9).
• Smoke-tested the resulting DMG on macOS 12 Intel hardware (MacBook Air): window renders, login persists, channels and history load, mentions highlight, URLs linkify. Same patches previously ran in daily self-hosted use on a 0.5.8 base (Air + iMac).
• Not tested: Apple Silicon regression, macOS 13+.

[aurelie-brebant]

Confirming this PR's diagnosis against the current release, on Intel hardware different from the ones already in the thread. I have not built the PR, so this confirms the analysis and its mapping onto the current tag, not the fix itself.

Environment

• MacBook, Intel x86_64
• macOS 12.7.6 (21H1320)
• Buzz Desktop 0.5.20, installed from the official Buzz 0.5.20.dmg, no local build
• Result: no window; initial render did not commit before reveal timeout, native process stays alive, com.apple.WebKit.WebContent spawns

The last confirmation against a release DMG in #3295 was v0.5.5 (7 Aug).

The four changes still map exactly onto desktop-v0.5.20

Checked against the tag, not main:

• A full scan of desktop/src for (?<[=!] returns exactly three hits, and they are precisely the two files this PR rewrites:
  • desktop/src/features/settings/ui/KeyboardShortcutsCard.tsx:17
  • desktop/src/features/messages/lib/mentionHighlightExtension.ts:488 and :503 (the patterns @claytonwinterbotham flagged at 110/125, since moved)
• No other lookbehind has crept into first-party source.
• pnpm-lock.yaml still pins mdast-util-gfm-autolink-literal@2.0.1 (via remark-gfm@4.0.1) and @radix-ui/react-collection@1.1.15.
• patches/ still contains only isomorphic-git.patch and virtua@0.49.3.patch, so the new patch file lands cleanly.
• desktop/vite.config.ts still declares no build.target, and there is still no minimumSystemVersion in desktop/src-tauri/tauri.conf.json.

The boot-graph edge that makes KeyboardShortcutsCard a startup failure rather than a settings-only one is also unchanged: AppShell.tsx:70-74 imports DEFAULT_SETTINGS_SECTION and isSettingsSection as values (used at line 175) from SettingsPanels.tsx, which statically imports KeyboardShortcutsCard at line 66.

One correction to the reasoning, which strengthens the case for the build target

Earlier in #3295 the missing target was described as leaving the dependency graph at esnext. That is not what Vite 8 does, and the real default is a better argument for this PR.

vite@8.0.16, the pinned version, defaults build.target to baseline-widely-available, documented in its own type declarations as:

transpile targeting browsers that are included in the Baseline Widely Available on 2026-01-01. (Chrome 111+, Edge 111+, Firefox 114+, Safari 16.4+).

Safari 16.4 is exactly the release that added both RegExp lookbehind and class static blocks. The default is therefore off by precisely one WebKit generation from macOS 12's system WebKit: both constructs are treated as supported and passed through untouched. A default named "baseline widely available" reads as conservative, which is likely why this went unnoticed.

Measured in a real WKWebView on this machine

A small Swift harness loading the constructs as separate <script> blocks, so each block's parse result is independent:

navigator.userAgent                 AppleWebKit/605.1.15
control script                      runs
/(?<!\+)\+(?!\s*$)/                 block never runs
/(?<=^|\s|\p{P}|\p{S}).../gu        block never runs
class C extends Map { static {} }   block never runs
new RegExp("(?<!x)y")               block never runs

The WebContent binary actually executed is 17613.3.9.1.16, while Safari.app on the same machine reports 17.6, matching the red herring already noted in #3295.

The last line is the one worth keeping in mind for review: new RegExp with a lookbehind fails too, so no build target can rescue mentionHighlightExtension.ts. The source rewrite in this PR is required, not cosmetic.

Happy to run any specific check on macOS 12 Intel if it helps move the review along.

[XIII-EOG]

Hi! I have a MacBook Pro 13" Early 2015, Intel i5, 8 GB RAM, running macOS 12.7.6. The official Buzz 0.5.23 x64 DMG opens to a blank window, and older releases have the same issue.

I saw that you successfully tested the WebKit fix on Intel Monterey. Would you be able to share the patched x64 DMG or a downloadable build artifact? I’m not a developer, and building from source on this old Mac requires a large toolchain that I’m struggling to install.

Thank you!

[aurelie-brebant]

@arielhauter a practical question, as one of the people waiting on this. GitHub now reports the branch as conflicting with main (mergeable: false). mentionHighlightExtension.ts has moved a fair bit since 11 Aug: the two lookbehind patterns were at :488 and :503 at desktop-v0.5.20 and are at :569 and :584 on main today.

Since maintainers generally skip conflicted PRs during triage, the rebase looks like the real blocker right now rather than reviewer attention. Are you still planning to pick this back up? If not, would you mind saying so, so someone else can carry the same four commits forward rather than leaving it stalled?

State of things as of today, for whoever looks next: main still has no build.target, all three lookbehinds are still present, patches/ is unchanged, and 0.5.22 and 0.5.23 both shipped without the fix.

[arielhauter]

@arielhauter a practical question, as one of the people waiting on this. GitHub now reports the branch as conflicting with main (mergeable: false). mentionHighlightExtension.ts has moved a fair bit since 11 Aug: the two lookbehind patterns were at :488 and :503 at desktop-v0.5.20 and are at :569 and :584 on main today.

Since maintainers generally skip conflicted PRs during triage, the rebase looks like the real blocker right now rather than reviewer attention. Are you still planning to pick this back up? If not, would you mind saying so, so someone else can carry the same four commits forward rather than leaving it stalled?

State of things as of today, for whoever looks next: main still has no build.target, all three lookbehinds are still present, patches/ is unchanged, and 0.5.22 and 0.5.23 both shipped without the fix.

Hi @aurelie-brebant yes I'll revisit this tomorrow and get it up-to-date! Appreciate your shared focus on it...

@XIII-EOG I'll see if I can get you a downloadable build tomorrow...

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is c507a4d488ca27796e78d876b9c24ee38442cc1b...189e5024549749f8734db9b44e5a9af34e5dd7ea.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 189e5024549749f8734db9b44e5a9af34e5dd7ea to authorize a new review.
Any previous review applies only to its recorded range.

[XIII-EOG]

"@XIII-EOG I'll see if I can get you a downloadable build tomorrow..." Hello, sir! Sounds perfect, waiting forward. Huge thank you!!!

[arielhauter]

@XIII-EOG CI on this PR needs maintainer approval before it runs, so no CI artifact yet. I've published my rebased build as a release on my fork (so you can download the DMG from there, if have any issues, just let me know and I'll send it another way):

https://github.com/arielhauter/buzz/releases/tag/v0.5.23-macos12-webkit-fix

SHA-256 and install steps are in the release notes. It's built from main @ c507a4d plus this PR's four commits, smoke-tested on two macOS 12 Intel machines. Unofficial and unsigned — please verify the checksum, and report back here whether it renders on your 2015 MBP. That's a third hardware confirmation for the maintainers.

[arielhauter]

@tlongwell-block — tagging you since #748 added the Intel x64 DMG release target and this PR fixes the blank window on the macOS 12 machines that target ships to. It's rebased and conflict-free, with three users waiting on this thread (#3295). Could someone on the team approve the workflow runs so CI can verify it? Happy to make any changes review turns up.