/* iOS app fixes — scoped to .is-ios-app (tc_app cookie AND iOS UA, core.class.php).
   Android, mobile web and desktop never receive the class, so nothing here can
   affect them.

   ---------- 1. Stop iOS zooming when a field is focused ----------

   iOS Safari/WKWebView AUTO-ZOOMS the page whenever a focused text control has a
   font-size below 16px. Several controls here are 13px (.tc-compose-input,
   textarea.tc-input), so tapping the comment box zooms the page in.

   That zoom is not just cosmetic: zooming shrinks and offsets the visual viewport,
   which is measured by the keyboard handling in tc-ios-keyboard-cb6.js and is a
   large part of why the comment area appeared to "overflow off the screen". Fixing
   the zoom removes a moving target from the keyboard layout, not only the visual
   jump.

   16px is the documented threshold — the fix is to meet it, not to disable zoom via
   the viewport meta tag (`maximum-scale=1, user-scalable=no`), which also blocks
   deliberate pinch-zoom and is an accessibility regression.

   Text stays 13px everywhere else; only the interactive controls change, and only
   inside the app. */
.is-ios-app input[type="text"],
.is-ios-app input[type="email"],
.is-ios-app input[type="password"],
.is-ios-app input[type="search"],
.is-ios-app input[type="tel"],
.is-ios-app input[type="url"],
.is-ios-app input[type="number"],
.is-ios-app input[type="date"],
.is-ios-app input:not([type]),
.is-ios-app textarea,
.is-ios-app select,
.is-ios-app .tc-input,
.is-ios-app .tc-textarea,
.is-ios-app .tc-select,
.is-ios-app .tc-compose-input,
.is-ios-app .form-control {
  font-size: 16px !important;
}

/* The comment box is sized around 13px text, so give the taller line-height room
   rather than letting the send button and tools crowd it. */
.is-ios-app .tc-compose-input {
  line-height: 1.4;
}

/* ---------- 2. Stop WKWebView's runaway scroll when the composer is focused ----------

   The comment composer is position:fixed on mobile. When a field is focused,
   WKWebView runs its "scroll the focused element into view" pass. At that instant
   the keyboard has not appeared yet, so the composer still sits where the keyboard
   is about to be, and WebKit judges it obscured -- but scrolling the document does
   not move a fixed element, so it never becomes visible and WebKit scrolls again.

   That runaway is the reported symptom: tapping the comment box throws the page a
   long way down, flickers, and often eats the tap so the keyboard never opens at
   all. It is iOS-only; Android's WebView does not do this, which is why the same
   markup has always worked there.

   The fix is to give WebKit nothing to scroll. tc-ios-keyboard-cb6.js applies this
   class on touchstart -- BEFORE focus lands, which is the whole point, since by the
   time focusin fires WebKit has already scrolled -- and removes it when the keyboard
   closes, restoring the exact scroll offset.

   position:fixed on body rather than overflow:hidden alone: WebKit clamps the scroll
   offset to 0 when the root stops being scrollable, which would itself be a jump.
   Pinning body at -scrollY holds the page exactly where the user left it. This is
   the same body-scroll-lock every modal library uses. */
html.tc-scroll-lock,
html.tc-scroll-lock body {
  overflow: hidden !important;
  overscroll-behavior: none;
}
html.tc-scroll-lock body {
  position: fixed;
  left: 0;
  right: 0;
  width: 100%;
}