Code/Manual tab buttons unresponsive in Safari

[mp-c0de]

Description

The toggle buttons on component documentation pages do not respond to clicks when using Safari. They work correctly in Chrome.

Affected buttons:

• Preview / Code toggle at the top of the component preview card
• CLI / Manual toggle in the Installation section

Steps to reproduce

1. Open Safari
2. Navigate to any component docs page, e.g. /docs/components/button
3. Click the Code button at the top of the preview card → nothing happens
4. Click the Manual tab in the Installation section → nothing happens
5. Same actions work correctly in Chrome

Expected behaviour

Clicking the buttons should toggle the displayed content (preview ↔ source code, CLI install ↔ manual install).

Environment

• Browser: Safari (macOS)
• OS: macOS

Possible cause

The tabs use Leptos reactive signals (current_tab.get()) with conditional display: block/none styling. There is even a TODO comment in app/src/domain/markdown_ui/components/static_demo_wrapper.rs:141:

// TODO 🚑 Show does not work at the moment. Using display as shortfix solution.

This suggests there is a known issue with <Show> which prompted the workaround. The current workaround may have additional issues in Safari around hydration or event handler binding that don't appear in Chrome.

[mp-c0de]

Update: root cause identified

I dug into this and found the actual cause. It's not specific to the tab buttons — the entire WASM hydration fails to complete on Safari cold start, which silently breaks all reactive interactivity (tab buttons, dropdowns, dialogs, etc.). It then appears to be a tab-button bug because that's the most obvious symptom on docs pages.

Reproduction

The bug only triggers on a Safari cold start (fully quitting Safari and reopening, not just closing tabs). After one successful page load, subsequent loads work because the WASM is in HTTP cache (Cache-Control: max-age=31536000, immutable).

Findings

	Cold-start (broken)	After refresh (working)
window.ScrollLock in console	undefined	object
deploy_rust_ui.wasm in Network tab	never appears	200 OK from cache
Console warning	The resource http://localhost:3000/pkg/deploy_rust_ui.wasm was preloaded using link preload but not used within a few seconds from the window's load event	none

Root cause

The dev-mode WASM file is 87 MB (Content-Length: 87725597).

Safari's preload heuristic drops preloads that aren't "used quickly enough" — for an 87 MB file on a fresh load, the preload either times out or gets garbage-collected before Leptos's hydration script gets to import() it. Chrome's preload behaviour is more lenient, which is why the bug doesn't appear there.

The chain of events on Safari cold start:

1. Page loads, Leptos's <HydrationScripts> injects <link rel="preload"> for /pkg/deploy_rust_ui.wasm
2. Safari starts the preload
3. Safari's preload heuristic drops the in-progress download (warning is logged)
4. Hydration script later tries to import("/pkg/deploy_rust_ui.js") which loads the WASM
5. In Safari this fetch never completes (or never starts) — possibly blocked by something related to the dropped preload
6. WASM never hydrates → no event handlers → buttons appear non-functional

After a refresh: the WASM is in HTTP cache, so no preload race, and hydration completes successfully.

Why dev WASM is 87 MB

The current [profile.dev] in the workspace Cargo.toml:

• [profile.dev.package."*"] has opt-level = 3 for dependencies (good)
• But the app crate itself is built with default opt-level = 0
• No wasm-opt post-processing in dev mode
• Debug info is off (debug = false) but no size opt

87 MB is large enough that browsers start hitting various heuristic limits (preload timeouts, memory caching, etc.)

Possible directions for a fix

1. Reduce dev WASM size — apply some opt-level to the app crate in dev mode, or run wasm-opt -Os on dev builds. Trades dev compile time for browser-friendliness.
2. Remove the WASM preload — let the hydration script fetch the WASM on its own without <link rel="preload">, eliminating the preload race entirely. May require an upstream Leptos change or a custom hydration script.
3. Document as known dev-only issue — production builds will be much smaller (1–5 MB after release optimisation + wasm-opt) and won't trigger this. If the maintainer believes this only affects dev, a note in CONTRIBUTING.md / README pointing Safari users to use Chrome for local development would suffice.

Workaround

While developing locally on Safari: always refresh the page once after a fresh page load to get a working WASM hydration.

I'm happy to help with any of the fix directions if you'd like — let me know which approach you'd prefer.

[mp-c0de]

Updated analysis

After more debugging in Safari Web Inspector, my earlier preload theory was wrong. The actual cause is different:

• WASM is loaded by JavaScript (deploy_rust_ui.js), not by browser preload
• When the bug triggers, the WASM fetch is never even initiated — deploy_rust_ui.wasm is completely absent from the Network tab
• After a refresh, the same JS runs successfully and fetches the WASM

So the bug is: the hydration loader silently fails on Safari cold start before initiating the network request.

Reproducibility

It's intermittent — even with a full Safari quit + reopen, it only fails ~50% of the time. There's an additional race/timing condition we couldn't isolate.

Workaround

Refresh the page once after a fresh Safari launch. Subsequent loads (with WASM in HTTP cache) always work.

[mp-c0de]

Root cause confirmed — fixed by #21

I reproduced the bug deterministically by reverting to clean upstream main and the actual error became visible:

A hydration error occurred while trying to hydrate an element defined at
app/src/components/command_search_docs.rs:19:18.

The framework expected a marker node, but found this instead:
<script src="/hooks/lock_scroll.js"></script>

So the cause is the inline <script src="/hooks/lock_scroll.js"></script> tags inside the component view trees (Sheet, Dialog, Select, DropdownMenu, MultiSelect, Command, Menubar, ContextMenu). Safari's HTML parser handles these differently from Chrome — during client-side hydration, tachys finds the <script> element where it expects a Leptos marker comment and panics. The crash kills hydration globally, which is why all reactive features stop working (tab buttons, dropdowns, dialogs, etc.).

My earlier WASM-loading-race theory was wrong — the WASM does load, but hydration crashes shortly after, leaving the page non-interactive.

Verified fix

Tested both branches against the same Safari cold-quit cycle (Cmd+Q + reopen + first load):

Branch	Result
Clean main	❌ Hydration error every cold quit, button only works after 3rd refresh
#21 applied	✅ Works on first load every cold quit

PR #21 removes the <script src="/hooks/lock_scroll.js"> tags from all 8 components as part of replacing the JS scroll-lock with the Rust implementation. So merging #21 fixes both #1 and this issue.