/* ════════════════════════════════════════════════════════════════════════
   The console inside the iPhone app.

   Every rule here is under html.in-app, a class set by one line in the head of
   views/console.html when the user agent carries FGConsoleiOS (Config.swift).
   In a browser the class never appears and this file changes nothing — which
   is the point: the phone layout is added, the desktop one is not touched.

   What the app takes over, and therefore what this file removes:

     · the rail — the drawer, its burger, its scrim and the top bar that holds
       them. On a phone the app draws a real tab bar underneath the web view,
       so a second, drawn-on menu would be two menus for one job.
     · the wordmark that links to "/" — inside an app there is no website to
       go back to, and a link that leaves for Safari mid-session reads as the
       app falling over.

   What it does not do: change a single number inside a tab. The cards, the
   tables and the type are the console's own phone layout at ≤820px, which
   already existed and already worked. This file is about the frame.
   ════════════════════════════════════════════════════════════════════════ */

/* ── The frame the app supplies ─────────────────────────────────────────── */

html.in-app .mtopbar,
html.in-app .mscrim,
html.in-app .mburger,
html.in-app .side,
html.in-app .appbar { display: none !important; }

/* The rail is gone, so nothing has to be cleared at the top any more: the
   console's phone rule reserves 56px for the bar that no longer exists.
   The bottom needs no safe-area inset either — the web view stops above the
   tab bar, and the tab bar handles the home indicator itself. */
html.in-app .main {
  max-width: none;
  margin: 0;
  padding: 18px 18px 28px;
}

html.in-app .shell { display: block; }
html.in-app body { display: block; }

/* ── The browser tells, so it is silenced ───────────────────────────────── */

/* The rubber band at the end of a page is the single loudest "this is a web
   page" signal there is. The web view has bounces off as well; this stops the
   scroll from chaining out of an inner list into the document. */
html.in-app,
html.in-app body {
  overscroll-behavior: none;
  -webkit-tap-highlight-color: transparent;
}

/* Long-pressing a button in a browser offers to copy its link. In an app the
   same press should do nothing at all — but text a person may actually want,
   a key or a transcript, stays selectable. */
html.in-app button,
html.in-app .btn,
html.in-app .nav-item,
html.in-app .stat,
html.in-app .agcard,
html.in-app .cvcard { -webkit-touch-callout: none; }

/* ── The first screen ───────────────────────────────────────────────────── */

/* The console opens on API keys because that is what the markup marks active.
   In the app the tab bar decides which page is showing, and it asks for one
   before the first paint — but for the fraction of a second before that, the
   keys page would flash. Nothing is shown until the app has chosen. */
html.in-app.booting .page.active { visibility: hidden; }

/* Each tab arrives without the slide the console plays when a person clicks
   through the rail: the tab bar already moved, and a second animation on top
   of it reads as lag rather than polish. */
html.in-app .page.active { animation: none; }

/* ── Titles ─────────────────────────────────────────────────────────────── */

/* The section's name is in the navigation bar the app draws, so the page's own
   h1 is now the same word twice, one under the other. The description under it
   stays — that is the one line explaining what the section is for, and the bar
   has no room for it. */
html.in-app .page .head h1 { display: none; }
html.in-app .page.active > .head { margin-bottom: 18px; }
html.in-app .head .desc { margin-top: 0; }

/* ── /login, when the app opens it ──────────────────────────────────────────
   The app puts its own first screen in front of this page, so by the time it
   appears a person has already chosen "Log in" or "Create account" and is
   inside a screen with a Cancel button. What the page must not do is offer a
   second, contradictory way out. */

/* "Back to website": from inside an app there is no website to go back to, and
   following it would drop the person on the marketing landing mid sign-in. */
html.in-app .backlink { display: none !important; }

/* The marketing chat widget. It floats over the sign-in form on a phone — it
   was sitting on top of the "Google and Apple sign-in arrive after beta" line —
   and an app that shows you a sales agent while you are signing in to it has
   misread the room. The script still loads; this is the cheaper half of the
   fix and it also takes the widget out of the accessibility tree. */
html.in-app #fgw { display: none !important; }

/* The page centres its card in the viewport, and the app has already spent the
   top of that viewport on a navigation bar with the Cancel button. Aligning to
   the top instead keeps the form where a thumb expects it rather than pushed
   below the fold on a short phone. */
html.in-app main.wrap { padding-top: 18px; }