The Creator rendered as a tiny double-scrolling square in the WP tab. My fault, and
the mechanism matters more than the symptom:
I had moved the iframe's sizing (width:100%, border:0, min-height) out of its inline
style attribute and into work-package-suite-styles.css. The service worker cached the
HTML and the stylesheet as INDEPENDENT entries, cache-first — so a browser could hold
the new HTML together with the old CSS. With the inline sizing gone and the new rule
absent, the iframe fell back to the HTML default 300x150 box and the whole tool
collapsed. Moving self-contained markup into a separately-cached file created that
window; nothing about the layout itself was wrong.
Three layers so it cannot recur:
- The iframe's width/border/min-height are inline again, on purpose, with a comment
saying why. An iframe with no intrinsic size has a catastrophic failure mode, so its
sizing must not depend on another file being in step.
- applyEmbedLayout() now sets the fill height and width as INLINE styles via
sizeWPFrame(). Inline beats any stylesheet, including a stale cached one, so the
class is a refinement rather than a requirement.
- sw.js: HTML/CSS/JS are now fetched NETWORK-FIRST with the cache as offline fallback;
images/icons/manifest stay stale-while-revalidate. These files reference each other,
so a page must never run against a stale sibling — this same staleness had already
masked two other fixes during development. Cache bumped to v4.
Verified: at 2560x1440 the tool spans the window with a single scrollbar; with
work-package-suite-styles.css removed entirely (strictly worse than stale) the frame
still measures 1469x662 instead of 300x150, and re-running the layout pass keeps it
there; 12 checks across sop -> wp -> dashboard -> sop confirm body.embed-full, the
content-area class, the fill class and the inline height are all cleared on the way
out, so the wizard never ends up unscrollable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
n.siegfried
40bd19b6cf
