n.siegfried
40bd19b6cf
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>