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

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 [email protected] (via [email protected]) and @radix-ui/[email protected].
• patches/ still contains only isomorphic-git.patch and [email protected], 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.

[email protected], 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.

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!

@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 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...

🔐 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 I'll see if I can get you a downloadable build tomorrow..." Hello, sir! Sounds perfect, waiting forward. Huge thank you!!!

@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.

@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.

@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.

Confirmed working. @arielhauter I installed your fork build and the window renders.

Environment

• MacBook, Intel x86_64, macOS 12.7.6 (21H1320)
• Buzz_0.5.23_x64.dmg from the fork release, SHA-256 4adb13ff1c54f9df48f5d36f50a06bcae8d38ddfba193942b10f2b5495eb429e
• Previously: official 0.5.20 DMG, blank window, no UI at all

Before and after, same machine

Official 0.5.20:

keyring unreachable but migration marker present; booting keyring-locked recovery...
repos dir resolved at boot...
media proxy listening on 127.0.0.1:61870
initial render did not commit before reveal timeout

Your build:

buzz-mesh: installed tokio runtime with 8 MiB worker stacks
persisted identity pubkey <redacted>
repos dir resolved at boot...
media proxy listening on 127.0.0.1:56893
buzz-mesh: status report after startup failed: relay unreachable

The reveal-timeout line is gone and the window paints. relay unreachable is unrelated, I have no relay running yet. So this is a third hardware confirmation, independent of your two machines.

Two notes for anyone else on macOS 12

The release notes still read SHA-256: <paste hash>. The placeholder was never filled in, so the verification step the notes prescribe cannot be done. The hash above is what I measured; worth pasting into the release so the next person can check. Four people have downloaded it meanwhile. For what it's worth, a self-published hash next to a self-published binary is weak assurance anyway, but an empty field is worse than an honest one.

Expect a keychain prompt on first launch, "Buzz wants to use your confidential information stored in buzz-desktop". That is expected rather than alarming: keychain ACLs are bound to code-signing identity, and this build is unsigned, so macOS sees a different application asking for the item the signed app created. Choosing Allow (not Always Allow) is enough, and the app then writes persisted identity pubkey instead of falling back to an ephemeral key. So on macOS 12 this build also clears the keyring warning that the official build shows.

For the maintainers

Structural diff of the fork bundle against the official 0.5.20 bundle is two files, Contents/CodeResources and Contents/_CodeSignature/CodeResources, both signing artifacts. Same seven executables, no added binaries, no launch agents. The branch is rebased and mergeable: true; what it still needs is workflow authorization so CI can run, and a review.

@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.

Hi! First of all, thank you so much for your help. You solved a problem that seemed impossible for me to get past.

This was my first time using GitHub, and somehow I found the right place to ask for help straight away—and then someone actually made a patch specifically to help me. That feels like such an unlikely and amazing chain of events. Honestly, it’s incredible. Thank you!

The patched build installed successfully, and the app now opens. However, when joining eo-team, I got this error on the “Joining eo-team” screen:

AbortSignal.timeout is not a function

I’m using an Intel Mac running macOS Monterey 12.7.6.