/* KB4 Custom Pages (Forethought workflow tags Product_Admin, Product_User and
   Migration -- that last one was Product_Migration until Joy supplied the real
   tags on 2026-10-30; the bare name is deliberate, see product_migration.hbs) */

/* SCOPING. Every rule below is keyed to `html.product-page`, set by a one-line
   script at the top of each of the three templates in templates/custom_pages/.

   It used to be keyed to `body:has(#forethought-widget-embed-script)`, which
   worked by a side effect of where the Forethought embed script ends up: these
   pages declare it inline in the template, so it lands in <body>, while
   document_head.hbs and home_page.hbs both build theirs and append to <head>
   specifically so this file cannot match them.

   That coupled seven layout rules to a script id, invisibly from the id's side.
   A temporary diagnostic renamed the id to `...-test` to disable this file for
   one test, the rename outlived the test, and the result was that these pages
   silently lost all of it -- the footer reappeared, <body> stopped being a flex
   column, and #forethought-chat fell back to its `6rem` / `0px` safety values.
   Keyed to a class instead, nothing about the embed can switch this file off,
   and the lever for disabling it deliberately is the marker script itself. */

/* These pages' content is entirely position:fixed, so <main> collapses to
   0 height and the footer rides up under the header. Scope a sticky-footer
   flex layout to just these pages instead of touching body/main globally. */
html.product-page body {
  display: flex;
  flex-direction: column;
  /* Carried over from the sitewide `place-items: center` on <body>, which was
     deleted on 2026-10-21 (see style.css for why). <body> is a flex column
     here, so unlike everywhere else that declaration was not inert on these
     pages -- the `align-items` half was doing real cross-axis centring. Both of
     the in-flow children left here declare `width: 100%`, so centred and
     stretched resolve identically today and this changes nothing on its own;
     it is kept so that the flex-column case still says what it intends rather
     than inheriting it from a sitewide rule that no longer exists. */
  align-items: center;
  min-height: 100vh;
  /* Containing block for #forethought-chat, which Forethought injects as a
     direct child of <body> (verified in the console on 2026-10-30 -- there is
     no vendor wrapper, and nothing in the chain carries a transform, filter or
     containment that would anchor it elsewhere). The widget is `absolute`
     rather than `fixed` so it scrolls with the page; see that rule for why. */
  position: relative;
}

html.product-page main {
  flex: 1 0 auto;
  /* MAIN CLAIMS THE WHOLE VIEWPORT BELOW THE HEADER, so the footer begins
     below the fold. Without this, `min-height: 100vh` on <body> above is
     satisfied by header + main + footer together and `flex: 1 0 auto` only
     lets main absorb the *remainder*, so a ~400px footer sits inside the first
     screen and takes nearly half of it on a laptop. The widget then subtracted
     that same footer height a second time in its own sizing below, which left
     it about 320px tall and landscape -- the proportion problem reported on
     2026-10-30. Restoring the footer on these pages is what exposed this; it
     was invisible while the footer was `display: none` and measured 0.

     The page now scrolls by roughly the footer's height, which is ordinary:
     the footer is a destination, not chrome, and these pages' only content is
     a fixed widget that scrolling cannot move. */
  min-height: calc(100vh - var(--ft-header-h, 6rem));
}

html.product-page header .navbar-btn {
  display: none !important;
}

/* THE FOOTER IS BACK ON THESE PAGES, requested 2026-10-30. It used to be
   removed outright: `display: none` on `.footer-wrapper`, chosen over
   `visibility: hidden` so it left the accessibility tree and the tab order as
   well as the page, since Zendesk renders footer.hbs on every page with no
   template-side opt-out and CSS is the only lever. That rule is gone; the ask
   keeps one exception, the Contact Support button, handled below.

   NOTHING NEW WAS NEEDED TO MAKE IT SIT CORRECTLY. The sticky-footer flex
   column on `html.product-page body` above exists precisely because these
   pages' content is `position: fixed`, so <main> collapses to 0 height and a
   footer would otherwise ride up under the header. It was written for a
   visible footer and has been holding the case open all along.

   WHAT DOES CHANGE IS THE WIDGET'S HEIGHT, by design rather than by accident,
   and it is the one thing to look at in preview. product-page-widget.js
   measures `footer.offsetHeight` into --ft-footer-h, which read 0 while the
   footer was `display: none` -- the same value as the fallbacks on the
   #forethought-chat rule below, which is why the comment here used to say the
   two agreed rather than fought. Now that the footer renders, that variable
   carried the real footer height, and the widget's `bottom`, `height` and
   `max-height` all began subtracting it. That made the widget roughly 320px
   tall and landscape on a laptop, which is the proportion problem reported the
   same day. **The fix was the `min-height` on `html.product-page main` above,
   not a number on the widget** -- the footer is now below the fold and the
   widget does not subtract it at all. --ft-footer-h is gone entirely as a
   result: nothing read it, so product-page-widget.js no longer measures it.

   Pushing the footer below the fold is also what exposed the second half of
   the problem, since it made the page scroll for the first time: the widget
   was `position: fixed` and hung motionless while the footer slid past behind
   it. It is `absolute` now. Both are documented on that rule. */

/* THE CONTACT SUPPORT BUTTON IS THE EXCEPTION. `display: none` again rather
   than `visibility: hidden`: a focusable "Contact Support" that cannot be seen
   is worse than no button at all.

   It is safe to lift out of the footer's grid. `.kb-footer-cta` is the only
   item in row 1 of the right-hand column -- the wordmark holds row 1 of the
   left -- so removing it leaves that one cell empty rather than collapsing a
   row or stranding a sibling, and row 1 becomes the wordmark's height instead
   of the button's. The right column's other four items sit in rows 2..5 and
   the nav spans rows 2..-1 in the left column, so neither is disturbed. In the
   footer's narrow block every item drops to `grid-area: auto` and flows in DOM
   order, where hiding one simply removes it.

   This also makes these pages consistent rather than adding a new idea: the
   header's support pill is already hidden on them by
   `html.product-page header .navbar-btn` above. */
html.product-page .kb-footer-cta {
  display: none;
}

html.product-page #forethought-chat {
  /* The panel's own height, named because the centring offset below has to
     subtract it. Capped at 700px so it stops growing on very tall windows;
     otherwise it takes 85% of the region, leaving ~15% as breathing room. */
  --ft-panel-h: min(700px, calc((100vh - var(--ft-header-h, 6rem)) * 0.85));

  /* ABSOLUTE, NOT FIXED. The vendor ships this `fixed` because it is normally
     a floating launcher, and these pages went along with it -- which was
     invisible for as long as the page did not scroll, since pinned-to-viewport
     and sitting-in-the-page look identical when there is nothing to scroll.
     The `min-height` on `html.product-page main` above made the page scroll to
     reach the footer, and a fixed widget then hung motionless over the footer
     sliding past behind it (reported 2026-10-30). Absolute positioning against
     <body> makes it part of the page and scroll with it. */
  position: absolute !important;

  /* CENTRED FROM THE TOP ONLY, because the containing block is now <body> --
     whose box spans the whole document, footer included -- so the old
     `top` + `bottom: 0` + `margin: auto` would centre the panel against the
     document rather than against the screenful below the header. This instead
     places it at the header's bottom plus half the leftover room, which is the
     same result expressed in one offset.

     --ft-header-h is set by product-page-widget.js (see the custom page
     templates) from `main.offsetTop`, i.e. a DOCUMENT-relative offset. That
     matters here and did not before: the header is `position: relative`, not
     sticky, so a viewport-relative measurement of it is only correct at
     scroll-top, and a re-measure while scrolled would have thrown an
     absolutely positioned widget off. If the script never runs (e.g. blocked
     in a sandboxed preview frame), falling back to 0px would put the widget's
     top edge at the very top of the page, covering the header entirely. 6rem
     is a safe floor taller than the real header at any breakpoint, so the
     worst case is "slightly too much gap," not "covers the header." */
  top: calc(
    var(--ft-header-h, 6rem) +
      (100vh - var(--ft-header-h, 6rem) - var(--ft-panel-h)) / 2
  ) !important;
  /* The vendor sets a `bottom` inline for its floating position. Three of
     top/height/bottom cannot all apply, so it would be ignored anyway --
     cleared explicitly so the rule reads as what it means. */
  bottom: auto !important;
  left: 0 !important;
  right: 0 !important;
  margin-inline: auto !important;
  /* Without a width of our own the panel renders at Forethought's intrinsic
     iframe width (688px measured on the migration page), which against the
     700px height below is a near-perfect square. Narrow it to get a portrait
     panel. 560px is deliberately well clear of the 480px breakpoint
     Forethought uses for its *own* inner layout (see the note on
     `--ft-panel-width` in css-page-forethought.css) -- cross that and the
     conversation UI inside the iframe switches to its narrow arrangement,
     which is not what we want on a desktop page. `!important` is required
     because the vendor sets the width inline. */
  width: 560px !important;
  height: var(--ft-panel-h) !important;
  /* Redundant against the `min()` in --ft-panel-h, which already cannot exceed
     the region. Kept because the vendor sets a `max-height` inline and this is
     what overrides it. */
  max-height: calc(100vh - var(--ft-header-h, 6rem)) !important;
}

/* THE MOBILE TREATMENT: the panel fills the screen below the header, the same
   full-bleed look the sitewide widget gets at this breakpoint (see the
   fullscreen block in css-page-forethought.css). Requested 2026-10-30.

   It stops at the header rather than covering the viewport, which is where it
   deliberately differs from the sitewide one. That panel is a true takeover --
   fixed, inset 0, with page scroll locked -- and can afford to be, because it
   is a state the visitor opened and can close. Here the widget is the page: it
   is force-opened by product-page-widget.js with `config-ft-disable-close` and
   `config-ft-disable-x-button` set, so there is no close control. A takeover
   would strand the footer (restored to these pages the same day, by request)
   and the nav behind a panel with no way out, and would mean going back to
   `position: fixed` -- the detached-from-the-page problem the absolute
   positioning above exists to fix.

   Centring is dropped here rather than tuned. Whether the panel ended up flush
   with the header or had a gap above it was a coin flip on how much vertical
   slack happened to be left over; filling the region removes the question.

   54.89em is the same breakpoint the header switches to its mobile layout at
   (css-page-header.css) and the same one the sitewide widget uses, so this
   subsystem keeps one threshold rather than three. It must also stay equal to
   FT_FULLSCREEN_QUERY in product-page-widget.js, which tells the chat UI
   *inside* the iframe to use its mobile layout at the same point -- this half
   makes the box full-bleed, that half makes its contents suit the box, and
   neither is derivable from the other, so they drift silently if only one is
   edited. */
@media screen and (max-width: 54.89em) {
  html.product-page #forethought-chat {
    /* Flush to the header, no centring offset and no 0.75rem gap: the panel is
       the whole region now, so there is no slack to distribute. */
    top: var(--ft-header-h, 6rem) !important;
    /* `right: auto`, not the base rule's `right: 0`: left, width and right
       cannot all apply at once -- left wins and right is ignored (CSS2.1
       10.3.7) -- so releasing it is what makes the rule say what it does.
       The width is an explicit `100%` because #forethought-chat *is* the
       iframe and an iframe is a replaced element, where `width: auto` means
       "use your intrinsic width" rather than "fill left to right"; the same
       mistake collapsed the sitewide panel to nothing once, which is written
       up at the fullscreen rule in css-page-forethought.css. `100%` rather
       than `100vw` since vw counts the scrollbar gutter, and it resolves
       against <body>'s padding box, which carries no inline padding and whose
       margin is reset (css-reset.css) -- so this really is edge to edge. */
    left: 0 !important;
    right: auto !important;
    width: 100% !important;
    /* Declared twice on purpose. dvh tracks mobile browser chrome as it
       collapses; with vh alone the panel is sized to the *largest* viewport,
       which pushes its input row underneath the URL bar -- the one part of a
       chat panel that has to stay reachable. The vh line is the fallback for
       anything without dvh. Both stay at or below the `min-height` on
       `html.product-page main`, which is the vh figure, so the panel cannot
       overflow its region in either direction. */
    height: calc(100vh - var(--ft-header-h, 6rem)) !important;
    height: calc(100dvh - var(--ft-header-h, 6rem)) !important;
    max-height: none !important;
  }

  /* The mobile hamburger nav (.header-nav, an overlay dropdown) should cover
     the widget the same way it already covers the rest of the page, but the
     widget's own z-index otherwise sits above everything. Force it below
     the header's stacking context (z-index: 10, see css-page-header.css)
     while the nav is open. */
  html.product-page body:has(.header-nav.is-open) #forethought-chat {
    z-index: 1 !important;
  }
}