studio-engine 0.65.1 → 0.65.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 3aa4604073fec8349d92e58a72bfb14d5c87fbaf03081f4bcb3e430a0ec35bf6
-  data.tar.gz: 3653491831ad04c4cb7aad8f1950297655b42a0582864173c998cbf8ea005a06
+  metadata.gz: 8ed062df7a9840a9633eb1c4995bc878bee401f98d85086e7943c5ec9f6b55d4
+  data.tar.gz: df0c1c7dc4e13185b3c8e3fbe7cb9243f4b310398843c43913ef0a1aa7b03762
 SHA512:
-  metadata.gz: 38cd8f8eedcf34cb0cac87d4c7737bb3fd29af673651e4593a1a93f0e91e822e582500e62ffdb7172c6de1d6f8673fe6502da4717376b789ee91f0e9b9ed2fc4
-  data.tar.gz: 2ac51eaf964ad5ef2d9e026298dd0565466540de68ae68677c77eb2b802f17bc392691d63594794bd537282b2a9d315fc64c01e52800a72a82cc87cf5a1ed329
+  metadata.gz: ca97a89b5c1452bad931ec0a332e9fff228ea43b7ebe2249516b3f60b9bf79f03fcb3171a66c5b8c7692e25389ac15d24a8c70b0176a82921fee80b2dd80a06e
+  data.tar.gz: 97061141650afc6472e15bcaf40dc96c5175897a25f6d4aea5cfb318dd1d92100db6cb1aa52c3feb4a018fe93bb924485fdee7fe97d5989a7779dfb0959b03c0

data/CHANGELOG.md

@@ -6,6 +6,44 @@ The format is [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). This pro
 
 ### Added
 
+- **A green comment-leak scan used to mean "not looked at".**
+  `test/views/erb_comment_leak_test.rb` guards the ERB comment form in
+  `app/views/**/*.erb`. It never looked inside `<script>`, and that is where this
+  gem keeps its browser programs — `studio/modals/_host`,
+  `studio/solana/_phantom_deeplink`, `layouts/studio/_head` and the modal blocks
+  between them hold **1_239 JavaScript comments, 73_913 bytes of comment body**,
+  none of it read by any guard. A review of a diff made almost entirely of those
+  comments came back green, and the reviewer's note was the honest reading of it:
+  *"don't read that green as clearance."*
+
+  `test/views/script_comment_leak_test.rb` reads them. The rule is the one the ERB
+  guard applies — no ERB open or close sequence inside a comment body — and the
+  mechanism it defends against is worse than the ERB one. A tag quoted inside an
+  ERB comment is inert, because the comment swallows it. A tag quoted inside a
+  **JavaScript** comment is not inside anything ERB knows about, so ERB opens a tag
+  right there and **runs** it: a complete tag evaluates at render, and an
+  incomplete one swallows every byte up to the next close sequence in the file,
+  deleting working JavaScript with no syntax error to show for it. Wrapping the
+  line in an HTML comment does not help — ERB runs inside those too. Describing the
+  tag in words stays legal, exactly as it is for ERB comments.
+
+  **Finding a comment is the hard half, and the first cut of this got it wrong.**
+  Anchoring `<script>` blocks on raw source let an ERB comment's *prose mention* of
+  a script tag open the block: `studio/_board_assets.html.erb` reported 19_512
+  bytes of markup as JavaScript and never saw its real program on its own terms.
+  Blocks are now anchored on a copy with ERB tags and HTML comments blanked out,
+  length preserved so offsets and line numbers still land. Inside a block the
+  walker tracks the states that can hide a comment opener — a string
+  (`"https://…"` is not a comment), a template literal, a regex (`/\/\//`) — and a
+  literal or comment that never closes is REPORTED rather than absorbed, because a
+  walker that quietly lost its place is the same green as a clean file. The
+  assertions check the input as well as the verdict: how many blocks, comments and
+  bytes the scan actually reached, and that every block it opened matches a real
+  closing tag.
+
+  Zero findings across the engine at `origin/accepted`, so this lands green with no
+  allowlist.
+
 - **`data-pin` — the pinned stack publishes itself.** `--nav-h` / `--nav-bottom`
   answer for one element. Everything else that pins has been re-deriving the
   same geometry by hand: on `mcritchie-studio`'s `/deployments` the app strip
@@ -119,6 +157,60 @@ The format is [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). This pro
   guard on the read-before-write order.
 
 
+### Fixed
+
+- **A toast with buttons could not be dismissed while a modal was open.** The
+  layer scale put `--z-banner` (500) above `--z-toast` (400), and `body.modal-open`
+  lifts the environment bar stack to that tier at `position: sticky; top: 0`.
+  `#toast-container` is fixed at top 0 with `1rem` of padding, so the two land on
+  the same pixels: measured in a browser, the bars own y0-47 while the toast's
+  Dismiss button runs y28-40 — an 8-14px overlap at every viewport tested.
+  `elementFromPoint` at that button returned the **banner**, and a real click left
+  the toast on the page. Because the toast manager gives any toast carrying
+  buttons `duration: 0`, that X was the toast's **only** exit: it was stuck for
+  the rest of the session.
+
+  **The tiers are reordered** — `--z-banner` 400, `--z-toast-blur` 499, `--z-toast`
+  500 — and that is a semantic decision rather than a nudge around the geometry: a
+  toast is transient and demands interaction, a banner is persistent chrome that
+  will still be there afterwards. `--z-banner` still clears `--z-modal` (200), so
+  the property the lift exists for — DEV MODE and the email chip stay lit and
+  clickable over a modal — is unchanged and now has its own spec.
+
+  **One measured cost.** A banner button's tooltip is a descendant of the bar
+  stack, and the modal-open lift makes that stack a stacking context, so the
+  tooltip composites at `--z-banner` rather than at its own `--z-tooltip` (600).
+  At 1440x900 the tooltip and the toast card never meet; at 390x844 they overlap
+  by 260x45px, so a banner tooltip opened with both a modal and a toast up is
+  drawn under the toast. Hover/focus-only, purely visual, and recorded beside the
+  scale.
+
+  **Consumers that redefine these tokens in their own `:root` after the engine
+  import still win**, as they always have, so an app carrying a local copy of the
+  scale keeps the old order (and the bug) until it drops the copy.
+
+  Two literals moved with the tiers: `#toast-container` and `.toast-page-blur` in
+  `layouts/studio/_flash` carry `var(--studio-toast-z, var(--z-toast, …))`
+  fallbacks, and a fallback that disagreed with the scale would hand the bug to
+  any app rendering the partial without the engine sheet.
+
+  **The existing test could not have caught this and still cannot on its own.**
+  `layer_scale_contract_test` asserted `--z-toast > --z-modal`, which was true the
+  entire time the toast was unusable — both tiers cleared the modal, which says
+  nothing about which of *them* wins. It now names the banner, and pins the halo
+  directly beneath its own toast so no tier can settle between them. The property
+  is also asserted where the defect lives, in `e2e/toast_over_banner.spec.js`: a
+  hit test and a real mouse click at the Dismiss button, at desktop and phone
+  widths, at scroll-top and at an offset. And once more on the artifact a
+  consumer is actually served — `test/integration/layer_scale_build_test.rb`
+  runs the real Tailwind binary over the engine's entry point and reads the
+  tiers out of the COMPILED bundle, where `@import` resolution, layer ordering
+  and a shadowing `:root` are all in play and a source read sees none of them. One trap is recorded there — at 390px
+  the point under that button is the banner's Email link, so on the broken build a
+  click *navigated* and the toast count on the new page was zero; asserting the
+  count alone passes over the bug.
+
+
 ### Breaking
 
 - **The age-gate DOB modal is renamed, and the refusal moved to its own card.**

data/app/assets/tailwind/studio_engine/engine.css

@@ -63,12 +63,51 @@
   --z-modal:       200;  /* modal backdrop + card — THE app blocker */
   --z-lightbox:    210;  /* a lightbox opened from inside a modal */
   --z-alert:       300;  /* transient overlays that must not be missed */
-  --z-toast-blur:  399;  /* the frosted halo behind the toasts */
-  --z-toast:       400;  /* toasts */
-  --z-banner:      500;  /* environment / DEV MODE — reachable mid-modal */
+  --z-banner:      400;  /* environment / DEV MODE — reachable mid-modal */
+  --z-toast-blur:  499;  /* the frosted halo behind the toasts */
+  --z-toast:       500;  /* toasts — ABOVE the banner; see below */
   --z-tooltip:     600;  /* tooltips on the banner, so they clear it */
 }
 
+/* WHY THE TOAST OUTRANKS THE BANNER, and why it did not used to.
+
+   The first cut of this scale put --z-banner (500) over --z-toast (400) on the
+   reasoning that the environment bars must stay reachable mid-modal. They must
+   — but so must a toast, and the two claims collided the moment BOTH were true
+   at once, because they occupy the same corner of the viewport.
+
+   THE DEFECT, MEASURED on mcritchie-studio at 1440x900 and 390x844, dark and
+   light, scrollY 0 and 900. #toast-container is fixed at top 0 with 1rem of
+   padding, so a toast card sits at roughly y16-92. With a modal open, the rule
+   below lifts the bar stack to sticky top 0 at --z-banner, so it owns y0-47 —
+   overlapping the toast's top edge, which is where the Dismiss button lives.
+   `document.elementFromPoint` at that button returned the BANNER div, and a
+   real click left the toast count at 1. With no modal open it returned the
+   button's own SVG and the count dropped to 0.
+
+   That is not a cosmetic overlap. A toast carrying action buttons is given
+   `duration: 0` by the toast manager (layouts/studio/_flash), so it never
+   auto-dismisses — the Dismiss button is its ONLY exit, and under a lifted
+   banner the toast is stuck on the page for the rest of the session.
+
+   SO THE ORDER IS A SEMANTIC DECISION, not a workaround for the geometry: a
+   TOAST IS TRANSIENT AND DEMANDS INTERACTION; a BANNER IS PERSISTENT CHROME
+   that will still be there afterwards. The thing asking to be dealt with wins.
+   Two alternatives were considered and rejected — lowering the modal-open lift
+   below the toast (narrower blast radius, but leaves the scale saying something
+   nobody believes) and offsetting #toast-container while modal-open (treats the
+   symptom; the toast goes back under the banner the day either one grows).
+
+   WHAT THIS COSTS, MEASURED RATHER THAN ASSUMED. --z-tooltip (600) still clears
+   both tiers, but a banner button's tooltip is a DESCENDANT of the bar stack —
+   and while a modal is open the rule below gives that stack a z-index, which
+   makes it a stacking context and clamps every descendant inside it. So the
+   tooltip now composites at --z-banner rather than at 600. At 1440x900 the two
+   never meet (tooltip x1083-1343, toast card x496-944); at 390x844 they overlap
+   by 260x45px, so a banner tooltip opened with a modal AND a toast up is drawn
+   under the toast card. It is hover/focus-only, purely visual (the tooltip is
+   pointer-events:none), and it is the accepted cost of this ordering. */
+
 /* The environment / impersonation bars stay in NORMAL FLOW at rest
    (banners/_stack records why: pinning them in the RESTING state needs one
    pinned sibling to measure the other, and the measured version visibly
@@ -110,7 +149,7 @@ body.modal-open .studio-bar-stack,
 body.modal-open .studio-app-banner {
   position: sticky;
   top: 0;
-  z-index: var(--z-banner, 500);
+  z-index: var(--z-banner, 400);
 }
 
 /* -- Surfaces -------------------------------------------------------------- */

data/app/views/layouts/studio/_flash.html.erb

@@ -17,8 +17,18 @@
      bare 60/55 that sat below every app navbar. A toast is the one thing that
      must surface over an open modal, so --z-toast is above --z-modal and an app
      that never overrides gets that for free. Apps that DO override should set
-     the tier (--z-toast) instead, and drop the per-component name. */
-  #toast-container { z-index: var(--studio-toast-z, var(--z-toast, 400)); }
+     the tier (--z-toast) instead, and drop the per-component name.
+
+     ABOVE THE BANNER TOO, and the fallbacks below have to say so. A toast and
+     the environment bars share the top of the viewport, and with a modal open
+     engine.css lifts those bars to --z-banner at top 0 — which used to sit at
+     500, over the toast's 400, so the toast's Dismiss button was covered and a
+     click landed on the banner. A toast carrying buttons is given duration 0 by
+     the manager below, so that button is its only exit: covered, the toast was
+     stuck forever. The tiers were reordered (engine.css carries the argument);
+     these literals are what an app gets when the engine sheet is absent, so
+     they must carry the SAME order or that app keeps the bug. */
+  #toast-container { z-index: var(--studio-toast-z, var(--z-toast, 500)); }
   .toast-shadow-all {
     box-shadow: 0 0 30px rgba(0,0,0,0.4), 0 0 10px rgba(0,0,0,0.2);
   }
@@ -65,7 +75,7 @@
     mask-image: radial-gradient(ellipse 70% 80% at 50% 0%, rgba(0,0,0,0.7) 0%, rgba(0,0,0,0.3) 40%, rgba(0,0,0,0) 100%);
     -webkit-mask-image: radial-gradient(ellipse 70% 80% at 50% 0%, rgba(0,0,0,0.7) 0%, rgba(0,0,0,0.3) 40%, rgba(0,0,0,0) 100%);
     pointer-events: none;
-    z-index: var(--studio-toast-blur-z, var(--z-toast-blur, 399));
+    z-index: var(--studio-toast-blur-z, var(--z-toast-blur, 499));
     transition: opacity 0.5s ease;
     background: rgba(255, 255, 255, 0.15);
   }

data/lib/studio/version.rb

@@ -1,3 +1,3 @@
 module Studio
-  VERSION = "0.65.1"
+  VERSION = "0.65.3"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: studio-engine
 version: !ruby/object:Gem::Version
-  version: 0.65.1
+  version: 0.65.3
 platform: ruby
 authors:
 - Alex McRitchie
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-08-28 00:00:00.000000000 Z
+date: 2026-08-31 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rails