/* The stock viewer sets `color-scheme: light dark` on :root, so every
   light-dark() value in viewer.css (toolbar background, icon color, etc.)
   follows the OS/browser dark-mode preference. The rest of the site has no
   dark theme at all -- it's always the same light blue/white palette
   regardless of system preference -- so a user with a dark OS theme saw a
   visibly different, disconnected-looking editor. Force light everywhere
   in the editor too, for a consistent brand palette. */
:root {
  color-scheme: only light;
}

/* Decluttering: hide stock Mozilla chrome that's irrelevant to our
   "add text/signature or edit existing text, then save" flow. Printing is
   also a minor payment-bypass concern -- it lets a user export the edited
   PDF via the system print dialog without going through the paid
   /api/jobs/edit flow that Save/Download already gates. Scoped to specific
   IDs (plus a :has() for the find button's shared-class wrapper) so zoom,
   page nav, and our own editor-mode buttons are untouched. #editorSignatureButton
   is the stock icon button pdf.js reveals once a doc loads -- our custom
   "Add signature" label (pdfDocFlipSignatureLabel) already proxies clicks
   to it, so leaving both visible was a duplicate entry point for the same
   action and needless width on narrow toolbars. Only the button is hidden
   here, not its #editorSignature wrapper -- that wrapper also contains
   #editorSignatureParamsToolbar (the doorhanger with the real "add
   signature" action), which must stay in the layout to be reachable when
   the proxied click opens it. #editorEditText is the same duplicate-entry-
   point situation, but our own button (not stock pdf.js) with no nested
   doorhanger to preserve, so the whole wrapper can go: this was still
   taking up a full icon-button's width in the toolbar row after the
   pdfDocFlipEditTextLabel pill was added, on top of the Signature/Save
   width already trimmed above -- confirmed via real-width CDP measurement
   (not just headless-emulated) as the main contributor to the toolbar
   overflowing the viewport and forcing page-level horizontal scroll on
   360-414px-wide phones. */
#viewsManagerToggleButton,
#viewsManager,
.toolbarButtonSpacer,
#viewFindButton,
#findbar,
#printButton,
#secondaryToolbarToggle,
.verticalToolbarSeparator.hiddenMediumView,
#editorSignatureButton,
#editorEditText {
  display: none !important;
}

/* Also collapse the find button's shared-class wrapper (fixed aspect-ratio
   box, reused by other buttons we DO want, so it can't be hidden by class)
   so it doesn't leave an empty gap in the toolbar. Find has no dropdown
   that needs to stay reachable, so `display:none` on the wrapper itself is
   fine here. */
.toolbarButtonWithContainer:has(> #viewFindButton) {
  display: none !important;
}

/* #editorSignature is the same fixed-aspect-ratio .toolbarButtonWithContainer
   box as above (height:100%, aspect-ratio:1 -> ~28px square), but unlike
   Find it can't be `display:none`: it's also the positioning ancestor of
   #editorSignatureParamsToolbar, the "Add signature" doorhanger dropdown
   that our proxied pdfDocFlipSignatureLabel click opens (see the comment on
   #editorSignatureButton above). `display:none` on an ancestor forces all
   descendants non-rendering too, which would break the dropdown -- that's
   exactly the round-1 bug. So collapse the wrapper's own box to zero width
   instead of hiding it. Setting an explicit `width:0` overrides
   `aspect-ratio:1` (aspect-ratio only sizes a dimension left as `auto`; with
   both width and height given definite values it's ignored), so height:100%
   is unaffected and doesn't matter anyway -- it only affects the toolbar's
   vertical axis, never causes horizontal overflow. The dropdown itself
   (.editorParamsToolbar) is `position:absolute` off this wrapper
   (`position:relative` from .toolbarButtonWithContainer, kept as-is here),
   so it still renders at its usual size on top of the now-zero-width
   wrapper -- overflow is left at its default `visible` (never set to
   `hidden` anywhere on this wrapper) so it isn't clipped. */
#editorSignature {
  width: 0 !important;
  min-width: 0 !important;
  aspect-ratio: auto !important;
  overflow: visible;
}

/* pdf.js's own responsive CSS collapses the print+download button group
   into the "tools" hamburger menu (secondaryToolbarToggle ->
   #secondaryDownload) below 750px viewport width -- a width most tablets
   and many desktop windows are under, not just phones. Since we hide
   secondaryToolbarToggle above (it exposes a pile of stock menu items we
   don't want), that collapse would make Download completely unreachable
   at any narrow width. Force the group to stay visible; #printButton
   still hides via its own always-on rule below. */
#outerContainer .toolbarHorizontalGroup.hiddenMediumView {
  display: inline-flex !important;
}

/* Narrow phones: zoom controls and the page-number box aren't essential
   to the "add text/signature or edit existing text, then save" flow and
   were pushing Download and the icon tools off-screen, forcing horizontal
   scrolling. Prev/next page arrows and the zoom-percent dropdown already
   hide at their own breakpoints via pdf.js's stock CSS. */
@media (max-width: 480px) {
  #zoomOutButton,
  #zoomInButton,
  #toolbarViewerMiddle .splitToolbarButtonSeparator,
  #pageNumber,
  #numPages {
    display: none !important;
  }

  #toolbarViewerLeft .loadingInput.start:has(> #pageNumber) {
    display: none !important;
  }
}

/* Small extra safety margin on top of the margin-inline-end fix further
   below: real phones can render this extra-bold (font-weight:800) label a
   few px wider than headless Chrome's fallback fonts did in testing, which
   is exactly how this row passed emulated verification earlier but still
   overflowed on an actual device. Trims the label's own horizontal padding
   (id selector, so this naturally wins over viewer.css's shared
   .pdfDocFlipSignatureLabel padding without needing !important) --
   narrower than the 480px zoom-controls breakpoint above since Save only
   needs the extra room on true phone widths, not tablets/narrow desktop
   windows. */
@media (max-width: 420px) {
  #pdfDocFlipSaveLabel {
    padding-inline: 4px;
  }
}

#editorEditTextButton::before {
  -webkit-mask-image: var(--toolbarButton-editorFreeText-icon);
  mask-image: var(--toolbarButton-editorFreeText-icon);
}
.pdfDocFlipEditRegion {
  position: absolute;
  border: 1px dashed rgba(47, 111, 235, 0.6);
  cursor: pointer;
  pointer-events: auto;
}
.pdfDocFlipEditRegion:hover {
  background: rgba(47, 111, 235, 0.08);
}
.pdfDocFlipEditPopover {
  position: fixed;
  z-index: 10000;
  background: #fff;
  color: #111;
  border-radius: 8px;
  box-shadow: 0 4px 16px rgba(0, 0, 0, 0.35);
  padding: 10px;
  display: flex;
  flex-direction: column;
  gap: 8px;
  width: 260px;
  font: 13px sans-serif;
}
.pdfDocFlipEditPopover textarea {
  width: 100%;
  min-height: 60px;
  box-sizing: border-box;
  font: inherit;
  padding: 6px;
  border: 1px solid #ccc;
  border-radius: 4px;
  resize: vertical;
}
.pdfDocFlipEditPopoverHint {
  font-size: 11px;
  color: #666;
  margin: 0;
}
.pdfDocFlipEditPopoverActions {
  display: flex;
  justify-content: flex-end;
  gap: 8px;
}
.pdfDocFlipEditPopoverActions button {
  font: 600 12px sans-serif;
  padding: 6px 12px;
  border-radius: 6px;
  border: none;
  cursor: pointer;
}
.pdfDocFlipEditCancelBtn {
  background: #eee;
  color: #333;
}
.pdfDocFlipEditSaveBtn {
  background: #2f6feb;
  color: #fff;
}
.pdfDocFlipEditRevertBtn {
  background: #fff;
  color: #b3261e;
  border: 1px solid #ddd;
  margin-right: auto;
}
.pdfDocFlipEditPreview {
  position: absolute;
  z-index: 5;
  background: rgba(255, 255, 255, 0.92);
  overflow: hidden;
  display: flex;
  align-items: center;
  color: #000;
  white-space: pre;
  pointer-events: none;
  outline: 1px dashed rgba(47, 111, 235, 0.6);
}

/* Save is the button that actually finishes the job (and is what triggers
   the paid /api/jobs/edit flow) -- it was previously the plain icon-only
   stock pdf.js button, the least visually obvious control in a toolbar
   where Add Signature/Edit Text already got the labeled-pill treatment.
   Give it the same pill (via the shared .pdfDocFlipSignatureLabel class in
   viewer.css) but with more visual weight than those two, so it reads as
   the primary CTA rather than just a third tool of equal importance: the
   site's actual brand blue (--tool-accent in style.css) instead of the
   editor's own slightly different blue, plus a shadow to lift it off the
   toolbar. */
#pdfDocFlipSaveLabel {
  background: #2563eb;
  font-weight: 800;
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.25), 0 0 0 1px rgba(255, 255, 255, 0.15) inset;
  /* .pdfDocFlipSignatureLabel's shared margin-inline-end exists to space a
     label from whatever follows it in the toolbar -- for Save that's only
     the always-hidden #downloadButton (see the rule below), so the margin
     was pure dead space. On a 390px-wide phone that dead space was exactly
     what pushed the toolbar row's content past the viewport edge, causing a
     real (confirmed via getBoundingClientRect on the live site, not just
     headless emulation) page-level horizontal scroll -- zeroing it here. */
  margin-inline-end: 0;
}

#pdfDocFlipSaveLabel.pdfDocFlipDisabled {
  box-shadow: none;
}

/* Unlike the Add Signature label (which just opens a popup), Edit Text is a
   toggled mode -- give its label a visibly different "on" state so it's
   obvious the highlighted-regions overlay is currently active. */
#pdfDocFlipEditTextLabel.pdfDocFlipActive {
  background: #1a4fc4;
  box-shadow: 0 0 0 2px rgba(47, 111, 235, 0.45);
}

/* #downloadButton is the stock icon-only pdf.js Save/Download button --
   same story as #editorSignatureButton above: our labeled "Save" pill
   (pdfDocFlipSaveLabel) already proxies clicks to it, so leaving the icon
   visible too was just duplicate width in the toolbar. Hiding it here
   doesn't affect reachability -- it sits inside .toolbarHorizontalGroup
   .hiddenMediumView alongside #printButton and pdfDocFlipSaveLabel, which
   is forced visible by the rule above regardless of viewport width, and a
   `display:none` element can still be targeted with a synthetic `.click()`
   from JS. */
#downloadButton {
  display: none !important;
}

/* One-time spotlight on Edit Text, shown after the first document loads. */
@keyframes pdfDocFlipSpotlightPulse {
  0%,
  100% {
    box-shadow: 0 0 0 0 rgba(47, 111, 235, 0.55);
  }
  50% {
    box-shadow: 0 0 0 6px rgba(47, 111, 235, 0);
  }
}

#pdfDocFlipEditTextLabel.pdfDocFlipSpotlightTarget {
  animation: pdfDocFlipSpotlightPulse 1.6s ease-in-out infinite;
}

@keyframes pdfDocFlipBubbleIn {
  from {
    opacity: 0;
    transform: translateY(-4px) scale(0.96);
  }
  to {
    opacity: 1;
    transform: translateY(0) scale(1);
  }
}

.pdfDocFlipSpotlightBubble {
  position: fixed;
  z-index: 10000;
  max-width: min(230px, calc(100vw - 16px));
  background: #1a1a1a;
  color: #fff;
  font: 500 12.5px/1.4 sans-serif;
  padding: 8px 12px;
  border-radius: 8px;
  box-shadow: 0 4px 16px rgba(0, 0, 0, 0.35);
  animation: pdfDocFlipBubbleIn 0.2s ease-out;
}

/* Save overlay: spinner while the file is being prepared, brief checkmark
   confirmation for the already-paid/direct-download path. */
#pdfDocFlipOverlay {
  position: fixed;
  inset: 0;
  display: none;
  align-items: center;
  justify-content: center;
  background: rgba(0, 0, 0, 0.5);
  color: #fff;
  z-index: 99999;
  font: 600 16px sans-serif;
  text-align: center;
  padding: 20px;
}

.pdfDocFlipOverlayContent {
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 14px;
}

.pdfDocFlipSpinner {
  width: 34px;
  height: 34px;
  border-radius: 50%;
  border: 3px solid rgba(255, 255, 255, 0.25);
  border-top-color: #fff;
  animation: pdfDocFlipSpin 0.8s linear infinite;
}

@keyframes pdfDocFlipSpin {
  to {
    transform: rotate(360deg);
  }
}

.pdfDocFlipOverlayCheck {
  width: 34px;
  height: 34px;
  border-radius: 50%;
  background: #2fbf71;
  display: flex;
  align-items: center;
  justify-content: center;
  animation: pdfDocFlipBubbleIn 0.2s ease-out;
}

.pdfDocFlipOverlayCheck svg {
  width: 18px;
  height: 18px;
}

/* Ctrl+P / File > Print is wired at the document level by vendored pdf.js
   code (viewer.mjs), independent of #printButton -- hiding that button
   only reduces discoverability, it doesn't stop the browser's native print
   pipeline from running and handing the user a fully rendered copy of the
   edited PDF for free. We can't intercept window.print() or the native
   Ctrl+P/File>Print menu from JS (true of any site), so instead make sure
   printing produces nothing: hide everything, including pdf.js's own
   #printContainer (which it populates with rendered pages and switches to
   `display:block` via its own @media print rule in viewer.css -- ours
   loads after and uses !important so it wins regardless of trigger path). */
@media print {
  html,
  body {
    visibility: hidden !important;
  }

  #printContainer,
  #printContainer * {
    display: none !important;
    visibility: hidden !important;
  }
}