@mushi-mushi/web 1.7.1 → 1.7.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -202,13 +202,67 @@ Mushi.init({
202
202
  const health = await Mushi.diagnose();
203
203
  // → { apiEndpointReachable, cspAllowsEndpoint, widgetMounted, shadowDomAvailable,
204
204
  // dialogSupported, runtimeConfigLoaded, captureScreenshotAvailable,
205
- // captureNetworkIntercepting, sdkVersion }
205
+ // captureNetworkIntercepting, sdkVersion,
206
+ // widgetHostPointerSafe, widgetHostBounds, widgetSuppressed, bannerRendered }
207
+ //
208
+ // widgetHostPointerSafe — true when the host element is zero-sized and
209
+ // pointer-events:none (i.e. the SDK cannot block any host-app touch targets).
210
+ // widgetSuppressed — true when hidden by hideOnSelector / hideOnRoutes / hide().
211
+ // bannerRendered — true when trigger:'banner' and banner is visible.
206
212
  ```
207
213
 
208
214
  `Mushi.diagnose()` works **before** `Mushi.init()` too — call it from a debug
209
215
  console or installer wizard to surface CSP / endpoint problems with zero risk
210
216
  of accidentally booting the widget.
211
217
 
218
+ ### Host-element pass-through contract
219
+
220
+ The Mushi SDK guarantees it will **never block host-app UI** by default. The
221
+ host element (`#mushi-mushi-widget`) is always:
222
+
223
+ - `position: fixed; top: 0; left: 0`
224
+ - `width: 0; height: 0; overflow: visible` — zero-sized, shadow internals extend outward
225
+ - `pointer-events: none` — clicks and touches pass straight through to the page
226
+
227
+ Only the visible widget controls (`.mushi-trigger`, `.mushi-banner`, `.mushi-panel`)
228
+ opt back into `pointer-events: auto` inside the Shadow DOM.
229
+
230
+ If you want to verify this at runtime:
231
+
232
+ ```typescript
233
+ const health = await Mushi.diagnose();
234
+ console.assert(health.widgetHostPointerSafe, 'Mushi host is blocking UI!');
235
+ ```
236
+
237
+ ### Suppressing Mushi during fullscreen flows
238
+
239
+ For fullscreen modals, onboarding, games, video players, or checkout screens where
240
+ you need complete interaction isolation, use `hideOnSelector`. **This suppresses
241
+ both the trigger button and the banner** (they are unified — no surface leaks through):
242
+
243
+ ```typescript
244
+ Mushi.init({
245
+ projectId: 'proj_xxx',
246
+ apiKey: 'mushi_xxx',
247
+ widget: {
248
+ trigger: 'banner',
249
+ // Hide ALL SDK launcher surfaces while any of these elements are in the DOM.
250
+ hideOnSelector: '[data-onboarding-flow], [data-fullscreen-modal], [data-game-active]',
251
+ hideOnRoutes: ['/checkout/payment', '/quiz/'],
252
+ },
253
+ });
254
+ ```
255
+
256
+ For dynamic route-based suppression you can also call `Mushi.hide()` / `Mushi.show()`
257
+ programmatically; the body-offset nudge from `trigger:'banner'` is removed automatically
258
+ on every hide path.
259
+
260
+ > **Capacitor / WebView note:** In native WebView shells (iOS WKWebView, Android
261
+ > WebViewClient), `pointer-events:none` alone is not always sufficient — some versions
262
+ > of Chromium-based WebViews still route touch events to `fixed` overlay elements that
263
+ > sit at a certain z-index. Use `hideOnSelector` or `Mushi.hide()` for the safest
264
+ > experience in native shells.
265
+
212
266
  ### Presets and widget anchor
213
267
 
214
268
  ```typescript
@@ -403,3 +457,9 @@ the browser context.
403
457
  ## License
404
458
 
405
459
  MIT
460
+
461
+
462
+ <!-- mushi-readme-stats-footer -->
463
+ ---
464
+
465
+ <sub>Monorepo scale (June 2026): 43 edge functions · 233 SQL migrations · 13 outbound plugins · 11 inbound adapters. Canonical counts: <a href="https://github.com/kensaurus/mushi-mushi/blob/master/docs/stats.md">docs/stats.md</a> · <code>pnpm docs-stats</code></sub>