/**
 * KosherShop chatbot widget — layout & message-grouping fixes.
 *
 * - Groups consecutive bot bubbles (e.g. the "Hi! Welcome to KosherShop" +
 *   "How can I help you today?" greeting) under a single avatar with no
 *   gap between them, instead of one avatar + gap per line.
 * - Hides the empty quick-action placeholder li that ships with no active
 *   buttons on a fresh conversation (renders as a blank pill otherwise).
 * - Fixes widget width/positioning across mobile, tablet, and desktop —
 *   the stock plugin CSS leaves it at a fixed ~400px panel that overflows
 *   or looks wrong below desktop widths.
 */

/* ---- Group consecutive bot messages into one visual bubble ----
 * Only groups a bubble with the one before it when that previous bubble
 * itself already shows an avatar (i.e. isn't the first-child "X has
 * joined the conversation" system line, which never has an avatar) —
 * otherwise the very first real message would lose its icon too.
 */
ul.wp-chatbot-messages-container > li.wp-chatbot-msg:not(:first-child) + li.wp-chatbot-msg {
	margin-top: -10px !important;
}

ul.wp-chatbot-messages-container > li.wp-chatbot-msg:not(:first-child) + li.wp-chatbot-msg .wp-chatbot-avatar,
ul.wp-chatbot-messages-container > li.wp-chatbot-msg:not(:first-child) + li.wp-chatbot-msg .wp-chatbot-agent {
	display: none !important;
}

ul.wp-chatbot-messages-container > li.wp-chatbot-msg:not(:first-child) + li.wp-chatbot-msg > .wp-chatbot-paragraph {
	border-top-left-radius: 4px;
	border-top-right-radius: 4px;
	margin-top: 0;
}

ul.wp-chatbot-messages-container > li.wp-chatbot-msg:not(:first-child):has(+ li.wp-chatbot-msg) > .wp-chatbot-paragraph {
	border-bottom-left-radius: 4px;
	border-bottom-right-radius: 4px;
}

/* ---- BUG-0030: persistent "Live Chat" window ----
 * A single container (heading + scrollable body) that the live-agent JS
 * updates in place (intro -> form -> conversation) instead of dropping a
 * new loose bubble into the AI chat feed for every state change.
 */
.kosher-live-chat-window {
	border: 1px solid #dfe3e0;
	border-radius: 10px;
	overflow: hidden;
	background: #fff;
	margin: 2px 0;
	width: 100%;
	box-sizing: border-box;
}

.kosher-live-chat-header {
	background: #0CC0DF;
	color: #fff;
	font-weight: 600;
	font-size: 13px;
	padding: 8px 12px;
}

/* BUG-0070: no box-sizing was ever set here, so this element's
 * content-box default meant the 10px/12px padding added ON TOP of
 * whatever height the BUG-0069 flex chain computed for it, instead of
 * being included within it -- confirmed live via Playwright at squeezed
 * mobile heights (390x420/390x500, simulating a keyboard-shrunk viewport):
 * the composer consistently overflowed the bottom edge by ~4-26px, closely
 * matching this element's own top+bottom padding total. border-box makes
 * padding count toward the height the flex chain already allots this
 * element, instead of stacking on top of it. */
.kosher-live-chat-body {
	max-height: min(280px, 40vh);
	overflow-y: auto;
	padding: 10px 12px;
	box-sizing: border-box;
}

/* BUG-0033/0052: once a conversation is connected (.kosher-live-chat-messages
 * is present), the body switches to a fixed-height flex column so only the
 * message history scrolls internally — the composer (.kosher-live-continue)
 * stays pinned and always visible, instead of scrolling out of view along
 * with the growing message list. Switched from a rigid 280px to
 * `min(280px, 40vh)` (BUG-0052) — the desktop "expand" button
 * (board-expand.js) resizes the vendor's own content area up to 560px tall,
 * and a fixed 280px box didn't adapt to that, leaving dead space and
 * apparently contributing to a layout break the client reported when using
 * it — bounding to a viewport-relative max keeps this in proportion to
 * whatever size the surrounding panel actually is (default, full-screen, or
 * expanded) instead of assuming one fixed context.
 */
.kosher-live-chat-body:has(.kosher-live-chat-messages) {
	height: min(280px, 40vh);
	max-height: min(280px, 40vh);
	overflow-y: hidden;
	display: flex;
	flex-direction: column;
}

/* BUG-0076: confirmed live via Playwright at 30+ messages on mobile (cart
 * page) that the flex-fill chain (BUG-0069) alone isn't a reliable enough
 * boundary in practice -- .wp-chatbot-content (the vendor's own outer
 * scrollport, unconditionally overflow-y:auto per BUG-0066) and this
 * element both have overflow:auto, and the ancestors between them
 * (ul/li/.wp-chatbot-paragraph/.kosher-live-chat-window/.kosher-live-chat-body)
 * were rendering TALLER than their supposed flex-bounded space rather than
 * being clamped, making .wp-chatbot-content the effective (but stale,
 * vendor-controlled) scrollport instead of this element -- at 30 messages
 * the whole window grew to ~900px and the composer scrolled out of the
 * OUTER container's view even though this inner list's own scroll was
 * technically fine. Giving this element its own explicit, self-contained
 * max-height (not dependent on every ancestor's flex math being perfect)
 * guarantees it -- not some ancestor's overflow -- is the one that
 * actually engages, regardless of any flex-chain subtlety above it.
 * Desktop's equivalent cap lives on the parent .kosher-live-chat-window
 * instead (BUG-0075, min(560px,70vh)); this is the mobile/tablet-specific
 * version, proportional to the real keyboard-aware viewport height
 * (BUG-0072's --kosher-chat-vvh) rather than a guessed fixed offset.
 */
.kosher-live-chat-messages {
	flex: 1 1 auto;
	min-height: 0;
	max-height: calc(var(--kosher-chat-vvh, 100dvh) * 0.42);
	overflow-y: auto;
	padding-right: 2px;
}

@media screen and (min-width: 769px) {
	.kosher-live-chat-messages {
		max-height: none;
	}
}

.kosher-live-chat-msg {
	margin: 0 0 8px;
	font-size: 13px;
	color: #333;
	flex: 0 0 auto;
}

.kosher-live-chat-body input[type="text"],
.kosher-live-chat-body input[type="email"],
.kosher-live-chat-body textarea {
	display: block;
	width: 100%;
	margin: 4px 0;
	padding: 6px;
	box-sizing: border-box;
	border: 1px solid #ccc;
	border-radius: 6px;
	font-size: 13px;
}

/* BUG-0037: inline validation errors on the live-chat start form. */
.kosher-live-form-errors {
	color: #b3261e;
	font-size: 12px;
	margin: 0 0 4px;
}

.kosher-live-form-errors p {
	margin: 0 0 2px;
}

.kosher-live-chat-body .kosher-live-start-submit,
.kosher-live-chat-body .kosher-agent-btn--chat,
.kosher-live-chat-body .kosher-live-reply-send,
.kosher-live-chat-body .kosher-live-start-retry,
.kosher-live-chat-body .kosher-retry-send {
	padding: 6px 14px;
	border-radius: 16px;
	background: #0CC0DF;
	color: #fff;
	border: none;
	cursor: pointer;
	font-size: 13px;
}

.kosher-live-chat-messages p {
	margin: 0 0 6px;
	font-size: 13px;
}

.kosher-live-continue {
	display: flex;
	gap: 6px;
	margin-top: 6px;
	flex: 0 0 auto;
}

.kosher-live-continue .kosher-live-reply {
	flex: 1;
	margin: 0;
}

.kosher-send-failed {
	color: #b3261e;
	font-size: 12px;
}

/* BUG-0066: guarantee native wheel/touch/scrollbar scrolling on the main
 * message list at all times, not only while the vendor's own
 * .active-chat-board-gated rule (common-style.css) happens to apply.
 * slimScroll (vendor, jQuery plugin) measures/sets its own inline height on
 * this element once; once this project's own taller content (the
 * persistent Live Chat window, long product-detail replies) is appended
 * afterward, that can leave the container unable to reach its own updated
 * scrollHeight via native input. Mirrors the vendor's own known-good rule,
 * just unconditionally instead of state-gated.
 */
#wp-chatbot-board-container .wp-chatbot-ball-inner.wp-chatbot-content,
#wp-chatbot-board-container .slimScrollDiv,
#wp-chatbot-board-container .slimScrollDiv .wp-chatbot-ball-inner {
	overflow-y: auto !important;
	overflow-x: hidden !important;
	-webkit-overflow-scrolling: touch !important;
	overscroll-behavior: contain;
	touch-action: pan-y;
}

/* Message bubbles must never be clipped when content (product cards, long
 * text, our own Live Chat window) is taller than the vendor's own assumed
 * line-height. */
ul.wp-chatbot-messages-container > li.wp-chatbot-msg {
	overflow: visible !important;
}

/* BUG-0066: "jump to latest" affordance shown by kosher-live-agent.js only
 * while auto-scroll is suppressed (customer has manually scrolled up).
 * #wp-chatbot-board-container is the floating widget's own positioned
 * panel, so this sits fixed at its bottom edge instead of scrolling away
 * with the message list.
 */
#kosher-scroll-to-latest {
	position: absolute;
	left: 50%;
	bottom: 70px;
	transform: translateX(-50%);
	background: #0CC0DF;
	color: #fff;
	border: none;
	border-radius: 14px;
	padding: 6px 14px;
	font-size: 12px;
	cursor: pointer;
	box-shadow: 0 2px 6px rgba(0, 0, 0, 0.25);
	z-index: 5;
}

/* ---- Hide the empty "quick action" placeholder on a fresh chat ---- */
ul.wp-chatbot-messages-container > li.wp-chatbot-msg-flat:has(> .qcld-chatbot-default.wpbd_subscription:empty):has(> .qcld-chatbot-custom-intent):has(> .qcld-chatbot-wildcard):has(> .qcld-chatbot-suggest-phone) {
	display: none !important;
}

/* ---- Responsive widget sizing ---- */

/* BUG-0051: laptop screens (client specifically flagged 1024px) get the
 * normal floating panel, same as desktop — full-screen is tablet-portrait
 * and phone only now. Widened from min-width:1025px down to 769px (the
 * vendor's own natural mobile breakpoint, confirmed elsewhere in this
 * project — MOBILE_BP=768 in the filter widget's own JS, and the vendor
 * chatbot's own `window.matchMedia('(max-width:768px)')` checks), matching
 * the full-screen cutoff below exactly so there's no gap between the two
 * rules. */
@media screen and (min-width: 769px) {
	#wp-chatbot-board-container.active-chat-board {
		width: 380px !important;
		/* BUG-0038: the vendor's own board has no height cap, so on a short
		 * viewport (small laptop screen, browser zoomed in) it could exceed
		 * the visible area with no way to reach the composer. Capped at
		 * 85% of the viewport height, dvh preferred where supported.
		 */
		max-height: 85vh !important;
		max-height: 85dvh !important;
	}
}

/* BUG-0039/0051: true full-screen — phone and tablet-portrait only
 * (max-width:768px, not 1024px — 1024px is a laptop width per the client,
 * see BUG-0051). The .wp-chatbot-mobile-full-screen class is applied
 * unconditionally by the plugin's own PHP (a static setting, not a JS
 * breakpoint check — confirmed in functions.php), so it's already present
 * in the DOM at every width; the "mobile-only" behavior is purely this
 * stylesheet's own media query range. Scoped with :has(.active-chat-board)
 * — the .wp-chatbot-mobile-full-screen class sits on the container at all
 * times (even showing just the closed ball icon), so without this the
 * closed ball icon itself would get stretched full-screen and end up
 * pinned to the top of the viewport instead of floating at the
 * bottom-right corner.
 */
@media screen and (max-width: 768px) {
	#wp-chatbot-chat-container.wp-chatbot-mobile-full-screen:has(.wp-chatbot-board-container.active-chat-board) {
		top: 0 !important;
		left: 0 !important;
		right: 0 !important;
		bottom: 0 !important;
		width: 100% !important;
		max-width: 100% !important;
		height: 100% !important;
		max-height: 100% !important;
		/* BUG-0038: 100% resolves against the viewport at the moment the
		 * fixed element is laid out, which on mobile Safari/Chrome doesn't
		 * track the address-bar/toolbar collapsing or expanding as the page
		 * scrolls — leaving the chat window cut off short or with a gap at
		 * the bottom, depending on toolbar state at open time. 100dvh (same
		 * technique this site's own mobile filter panel already uses)
		 * tracks the actual visible viewport continuously. The 100% rule
		 * above stays as a fallback for browsers without dvh support.
		 */
		height: 100dvh !important;
		max-height: 100dvh !important;
		/* BUG-0072: see kosher-mobile-layout-fixes.php's matching comment --
		 * 100dvh doesn't reliably track the on-screen keyboard on a real
		 * device, only browser-chrome collapse. These custom properties are
		 * kept live by kosher-live-agent.js's window.visualViewport
		 * listener and fall back to 100dvh until JS has run. */
		height: var(--kosher-chat-vvh, 100dvh) !important;
		max-height: var(--kosher-chat-vvh, 100dvh) !important;
		box-sizing: border-box !important;
		/* Keep the composer/input clear of the home-indicator/gesture bar
		 * on notched phones. env() resolves to 0 on devices without a safe
		 * area, so this is a no-op elsewhere. */
		padding-bottom: env(safe-area-inset-bottom, 0);
		overflow: hidden;
	}

	#wp-chatbot-chat-container.wp-chatbot-mobile-full-screen .wp-chatbot-board-container.active-chat-board {
		width: 100% !important;
		height: 100% !important;
		max-width: 100vw !important;
		box-sizing: border-box !important;
	}
}

/* BUG-0052: desktop "expand" button (board-expand.js) resizes the content
 * area via inline JS height (up to 560px) — client reported the widget
 * "breaking" (layout escaping the card bounds) and the new-chat composer
 * "not scrolling" when using it. Not width/viewport-scoped, since expand is
 * desktop-only by the vendor's own design (isExpandSupported() only exists
 * when #wp-chatbot-desktop-expand is present, which BUG-0041 already hides
 * on mobile/tablet). Ensures the message area can always scroll to reach
 * the composer regardless of how tall the vendor's own JS ends up making it.
 */
.qcchatbot-template-00.wp-chatbot-is-expanded .wp-chatbot-ball-inner.wp-chatbot-content,
.qcchatbot-template-00.wp-chatbot-is-expanded .slimScrollDiv {
	overflow-y: auto !important;
	-webkit-overflow-scrolling: touch;
}

/* BUG-0053: the actual root cause of the composer bar/"Need to talk to a
 * live agent?" link visibly rendering below/outside the widget's rounded
 * card in every screenshot this session, including ones from before any of
 * today's full-screen/expand CSS work — confirmed via source inspection
 * that #wp-chatbot-board-container (the visible card) has no `overflow`
 * rule of its own anywhere in the vendor's CSS, unconditionally, at any
 * width. The vendor's own message/content area height is computed by their
 * JS assuming ordinary one-or-two-line chat bubbles; this project's own
 * "Live Chat" persistent window (BUG-0030+) is taller than that assumption,
 * so once it pushes the total content past whatever height the vendor's JS
 * settled on, nothing clips it — it simply overflows past the card's own
 * visible boundary instead of being contained/scrolled. Not viewport-width
 * or state-scoped (applies to default floating, expanded, and full-screen
 * alike) since the underlying cause — no overflow containment on this
 * element — was never width-dependent to begin with. */
/* BUG-0071: overflow:hidden (BUG-0053) still permits PROGRAMMATIC/focus-
 * driven scrolling in every major browser -- it only blocks user-initiated
 * wheel/touch scroll and hides the scrollbar. Confirmed live via Playwright
 * at a squeezed viewport (390x420, simulating a keyboard-shrunk mobile
 * screen): focusing the Live Chat reply input (right at the edge of the
 * barely-enough available space) triggered the browser's native "scroll
 * focused element into view" behavior, which scrolled THIS element itself
 * (#wp-chatbot-board-container.scrollTop went from 0 to 23) instead of one
 * of the nested scrollable regions the flex chain (BUG-0069) actually
 * intends to scroll -- since the board's own children are positioned in
 * normal flow, that scroll silently shifted the header out of view
 * (measured at top:-23) while the rest of the layout looked otherwise
 * correct. overflow:clip has the same visual-clipping effect BUG-0053
 * needed but, unlike hidden, cannot be scrolled by any means (user or
 * programmatic) -- the two declarations are kept together so a browser
 * without clip support (very old, but this project already depends on
 * :has() elsewhere and requires a comparably modern browser) simply keeps
 * the hidden fallback instead of erroring. */
#wp-chatbot-board-container {
	overflow: hidden !important;
	overflow: clip !important;
}

/* BUG-0075: BUG-0056/0057 (2026-08-10) hid the vendor's own default
 * composer on mobile/tablet whenever Live Chat was connected, per client
 * request at the time. BUG-0067 (2026-08-14) reversed this same hide
 * approach on desktop per direct client correction -- both composers
 * should stay visible, sized to fit, rather than hiding either one. This
 * mobile/tablet rule was the one place that correction was never applied;
 * client has now explicitly asked for both the chat area and the form/
 * composer area to show simultaneously on tablet and mobile too, matching
 * desktop. Removed entirely -- sizing/scrolling is handled by the
 * universal flex-fill chain (BUG-0069) and box-sizing/overflow fixes
 * (BUG-0070/0071), the same mechanism already giving both composers room
 * to coexist on desktop. */

/* BUG-0058/0059/0060: mobile/tablet only, per client request (desktop
 * untouched — BUG-0052's original `min(280px, 40vh)` cap still applies
 * there, unaffected since this whole block is scoped inside the ≤768px
 * media query and loads after it, so it only wins at these widths).
 *
 * BUG-0058 (`min(70vh, 640px)`) and BUG-0059 (`calc(100dvh - 180px)`) were
 * both still guessed fixed/percentage numbers, not an actual fill — client
 * confirmed it was still not reaching full screen height either way. A
 * guessed offset can't be right on every device (the exact space taken by
 * the header + whatever greeting bubbles happen to be showing varies), so
 * rather than guess another number, this makes the FULL chain of ancestors
 * (message list -> the specific bubble holding our window -> the window
 * itself -> its body) proper flex containers, each stretching to fill
 * whatever space its parent actually has, the way CSS is meant to solve
 * "fill the rest of the available height" — instead of a fixed number that
 * has to be re-guessed for every possible header/greeting state. */
/* BUG-0069: this flex-fill chain was mobile/tablet-only (BUG-0058/59/60) --
 * desktop instead relied on a guessed fixed height (BUG-0052/0067's
 * min(280px,40vh) then min(420px,55vh) on .kosher-live-chat-body), which is
 * exactly the same "guessed number, wrong on some combination of viewport
 * height + greeting-bubble count + conversation length" problem BUG-0058/59
 * already failed at on mobile before BUG-0060 replaced it with an actual
 * fill chain. Client reported the Live Chat form getting cut off on
 * desktop/laptop -- removing the max-width:768px scope so the SAME proven
 * fill-the-available-space technique applies at every width. This nests
 * correctly inside desktop's own outer flex layout (BUG-0054/0055, which
 * makes #wp-chatbot-board-container itself a flex column with the header/
 * footer pinned and only the middle content area flexible) exactly the same
 * way it already nests inside mobile's full-screen board. The only
 * remaining per-width differences are the vendor's own board height/
 * position rules (85vh cap on desktop via BUG-0038, 100dvh full-screen on
 * mobile via BUG-0039/51) -- this chain just fills whatever height those
 * make available, on any device, instead of assuming one.
 */
#wp-chatbot-board-container.active-chat-board .wp-chatbot-ball-inner.wp-chatbot-content,
#wp-chatbot-board-container.active-chat-board .slimScrollDiv {
	display: flex !important;
	flex-direction: column !important;
	min-height: 0 !important;
}

ul.wp-chatbot-messages-container:has(.kosher-live-chat-window) {
	display: flex !important;
	flex-direction: column !important;
	flex: 1 1 auto !important;
	min-height: 0 !important;
}

ul.wp-chatbot-messages-container:has(.kosher-live-chat-window) > li.wp-chatbot-msg {
	flex: 0 0 auto;
}

ul.wp-chatbot-messages-container > li.wp-chatbot-msg:has(.kosher-live-chat-window) {
	flex: 1 1 auto !important;
	min-height: 0 !important;
	display: flex !important;
}

ul.wp-chatbot-messages-container > li.wp-chatbot-msg:has(.kosher-live-chat-window) > .wp-chatbot-paragraph {
	flex: 1 1 auto !important;
	display: flex !important;
	min-height: 0 !important;
}

.kosher-live-chat-window {
	flex: 1 1 auto !important;
	display: flex !important;
	flex-direction: column !important;
	min-height: 0 !important;
	height: auto !important;
}

.kosher-live-chat-body,
.kosher-live-chat-body:has(.kosher-live-chat-messages) {
	flex: 1 1 auto !important;
	height: auto !important;
	max-height: none !important;
	min-height: 0 !important;
}

/* BUG-0067: client feedback (2026-08-14) after first-pass fix: clicking
 * "Chat Here" should NOT hide the vendor's own default chatbot composer —
 * both it and this project's own Live Chat composer should stay visible on
 * desktop, sized/scrolled to fit instead of one being hidden. (An earlier
 * version of this fix hid .wp-chatbot-footer on desktop, mirroring
 * BUG-0056/0057's mobile-only rule — reverted per this direct instruction;
 * see git-equivalent backup kosher-chatbot-widget-fix.css.bak-desktopresize-*
 * for the prior hide-based approach if it's ever wanted again.)
 *
 * Desktop board width (380px, BUG-0038) and the Live Chat window's height
 * cap (min(280px, 40vh), BUG-0052) were both originally sized assuming the
 * Live Chat window was the ONLY composer on screen. With the vendor's own
 * composer also staying visible/pinned (BUG-0054/0055's desktop flex-fill
 * keeps .wp-chatbot-footer reserved space at all times), both together need
 * more room to avoid feeling cramped. Widened the board and raised the Live
 * Chat window's height ceiling, desktop only (min-width:769px, mobile/
 * tablet's own separate rules at max-width:768px are untouched). The
 * message list itself already scrolls internally
 * (.kosher-live-chat-messages, flex:1 1 auto + overflow-y:auto, BUG-0033) —
 * this only raises how much vertical space that scroller is allowed to use
 * before scrolling kicks in, it doesn't change the scrolling mechanism.
 */
@media screen and (min-width: 769px) {
	#wp-chatbot-board-container.active-chat-board {
		width: 420px !important;
	}

	/* BUG-0075: explicit maximum height for the Live Chat window itself on
	 * desktop, requested directly by the client alongside the Normal
	 * Chatbot's own existing 85vh board cap (BUG-0038/kosher-mobile-layout-
	 * fixes.php). min(560px, 70vh) mirrors the vendor's own desktop
	 * "Expand" button ceiling (BUG-0052 -- board-expand.js resizes up to
	 * 560px), so the Live Chat window's own guaranteed maximum matches the
	 * largest size the surrounding panel can ever actually be. The
	 * BUG-0069 flex-fill chain still governs sizing UP TO this cap and
	 * still scrolls the message list internally past it -- this only adds
	 * the outer ceiling that was previously implicit/indirect.
	 */
	/* BUG-0077: BUG-0075 only capped growth (max-height) -- the window still
	 * started small at 1 message and grew up to the cap, not matching the
	 * literal "fixed size regardless of message count" requirement. `height`
	 * (not just `max-height`) forces the window to always be this size from
	 * the very first message, consistent with how most dedicated chat UIs
	 * (Intercom, Crisp) behave -- empty space at the bottom of the message
	 * area with few messages is expected/correct, not a bug. */
	.kosher-live-chat-window {
		height: min(560px, 70vh) !important;
		max-height: min(560px, 70vh) !important;
	}
}

/* BUG-0078: further desktop-only sizing refinement, layered on top of the
 * existing min-width:769px rules (BUG-0038/0067/0075/0077) rather than
 * replacing them. Deliberately scoped to min-width:1025px per direct
 * client spec, NOT this project's usual 769px desktop breakpoint --
 * note this creates an intentional distinction between "laptop" (769-
 * 1024px, keeps the existing 85vh board / 560px Live Chat values, which
 * this project's own history -- BUG-0051 -- already established the
 * client considers a real desktop-like width) and "large desktop"
 * (>=1025px, gets these further-reduced values). If the client wants the
 * tighter sizing to also apply at 769-1024px, lower this breakpoint to
 * match the project's existing convention. Client requested but did not
 * ultimately attach a reference screenshot for the exact chatbot-window
 * target height -- used their own stated fallback range (~600-650px)
 * instead of guessing beyond it.
 */
@media screen and (min-width: 1025px) {
	/* CHANGE 1: main chatbot board -- was uncapped at 85vh (BUG-0038,
	 * e.g. 765px on a 900px-tall screen). Locked to a fixed ~620px
	 * (middle of the client's given 600-650px range), with 85vh kept as a
	 * secondary safety floor so a genuinely short/zoomed browser window
	 * still isn't forced taller than its own viewport. */
	#wp-chatbot-board-container.active-chat-board {
		max-height: min(620px, 85vh) !important;
	}

	/* CHANGE 2: Live Chat sub-panel -- was a fixed min(560px,70vh)
	 * (BUG-0077). ~16% reduction (560->470, 70vh->60vh, same proportion)
	 * per "modest, not drastic" instruction. Internal scroll
	 * (.kosher-live-chat-messages, BUG-0033/0076) is unaffected --
	 * conversations longer than this still scroll instead of clipping.
	 *
	 * BUG-0080: this fixed height was applying UNCONDITIONALLY -- including
	 * to the pre-chat name/email form state, which has no
	 * .kosher-live-chat-messages yet. Confirmed live via Playwright: 273px
	 * of dead space below the Send button, because a form that only needs
	 * ~160px of content was being forced into a 470px-tall box meant for a
	 * populated conversation. Scoped with :has(.kosher-live-chat-messages)
	 * so the fixed height only applies once actually connected; the form
	 * state now sizes to its own (tightened, CHANGE 3) content instead. */
	.kosher-live-chat-window:has(.kosher-live-chat-messages) {
		height: min(470px, 60vh) !important;
		max-height: min(470px, 60vh) !important;
	}

	/* BUG-0080 (part 2): scoping CHANGE 2 above with :has() made it stop
	 * matching during the form state as intended, but that alone wasn't
	 * enough -- BUG-0077's OLDER rule (unconditional, at the wider
	 * min-width:769px breakpoint that this min-width:1025px block nests
	 * inside) still matches at every width including 1025px+, and with
	 * this new selector no longer overriding it for the form state, IT WAS
	 * STILL WINNING (confirmed live: window measured 560px during the form
	 * state, matching that older rule's value exactly, dead space actually
	 * got WORSE). Explicitly resets back to auto for the form state at
	 * this breakpoint to counter it. */
	.kosher-live-chat-window:not(:has(.kosher-live-chat-messages)) {
		height: auto !important;
		max-height: none !important;
	}

	/* CHANGE 3: pre-chat form only (name+email -- the message field was
	 * removed per BUG-0063, so there are two fields, not three, despite
	 * the original spec assuming otherwise) -- tightened vertical
	 * spacing/padding so it feels more compact, matching the client's
	 * "reduce height/padding, don't remove fields" instruction. Scoped
	 * with :not(:has(.kosher-live-chat-messages)) so this never touches
	 * the connected conversation view's own composer spacing (that state
	 * uses the same .kosher-live-chat-body input styling but should keep
	 * its existing spacing). */
	.kosher-live-chat-body:not(:has(.kosher-live-chat-messages)) {
		padding: 6px 12px;
	}

	.kosher-live-chat-body:not(:has(.kosher-live-chat-messages)) input[type="text"],
	.kosher-live-chat-body:not(:has(.kosher-live-chat-messages)) input[type="email"] {
		margin: 3px 0;
		padding: 5px 6px;
	}

	.kosher-live-chat-body:not(:has(.kosher-live-chat-messages)) .kosher-live-start-submit {
		margin-top: 4px;
		padding: 5px 14px;
	}
}

/* ---- Chat ball loading swirl: recolor to the site's actual theme color ----
 * The vendor plugin's 3-ring spinner around the chat toggle/close button
 * (.wp-chatbot-ball-animation-switch + its :before/:after pseudo-elements,
 * wpbot-pro-master/css/common-style.css) ships hardcoded in unrelated
 * purple/magenta tones (#9370DB / #BA55D3 / #FF00FF) that don't match the
 * site at all. Per rule #10 (never edit vendor files directly), overridden
 * here instead.
 *
 * The site's real dominant color is #0CC0DF (confirmed live: header bar,
 * "Shop Now" link, section underlines, and used across every core
 * WooCommerce Elementor template + this same widget's own header/button
 * rules above) -- NOT Elementor's "Primary" system-color swatch (#6EC1E4),
 * which is just the unused Elementor default and appears nowhere else on
 * the live site. All three rings use tints/shades of that one real theme
 * color so the primary color stays dominant with no unrelated hue
 * introduced, while keeping the original design's 3-ring layered depth.
 * Design, size, position, timing, and animation are untouched -- only the
 * three border-top-color values changed.
 */
.wp-chatbot-animation-active .wp-chatbot-ball-animation-switch {
	border-top-color: #0CC0DF;
}

.wp-chatbot-animation-active .wp-chatbot-ball-animation-switch:before {
	border-top-color: #4DD9EE;
}

.wp-chatbot-animation-active .wp-chatbot-ball-animation-switch:after {
	border-top-color: #089DB8;
}

/* ---- BUG-0087: composer bar + send button recolored to the site theme ----
 * The vendor plugin ships the message composer with a hardcoded purple wash
 * and the send button as a plain white circle with a dark-grey paper plane
 * icon -- neither matches the site's real theme color, #0CC0DF (see the
 * swirl fix above for how that color was confirmed live). Recolored here
 * per rule #10 (never edit vendor files directly) using the same
 * tint/shade pair (#4DD9EE / #089DB8) as the swirl fix, so all chatbot
 * accents stay visually consistent with each other and with the header /
 * "Get in touch" panel elsewhere on the site. The composer bar keeps a
 * translucent wash (not solid) so the dark input text (#222) stays
 * readable; the send button goes solid since its icon is recolored to
 * white for contrast.
 *
 * !important and the exact selectors/specificity below are required to
 * beat three same-file vendor rules that would otherwise win:
 * wpbot-pro-master/templates/template-00/style.css has
 * `div#wp-chatbot-editor-container { background: #5755bd61; }` (the source
 * of the purple wash -- id+tag specificity beats a plain class selector)
 * and `button#wp-chatbot-send-message { background: rgb(255 255 255 / 25%); }`,
 * while common-style.css separately has
 * `.wp-chatbot-editor-container button { background: white !important; }`
 * which otherwise wins over any non-!important send-button rule regardless
 * of specificity or load order.
 */
div#wp-chatbot-editor-container {
	background: linear-gradient(135deg, rgba(12, 192, 223, 0.18), rgba(8, 157, 184, 0.18)) !important;
}

#wp-chatbot-send-message {
	background: linear-gradient(135deg, #0CC0DF, #089DB8) !important;
}

#wp-chatbot-send-message i {
	color: #fff !important;
}

/*
 * BUG-0095: on mobile, the floating chat widget's outer wrapper
 * (#wp-chatbot-chat-container, and #wp-chatbot-ball-container inside it)
 * renders as a `position:fixed` box spanning almost the FULL viewport
 * width at the bottom of the screen -- confirmed live via
 * getBoundingClientRect() at a 375px viewport: left:-12px, right:344px,
 * even though only the small 60x60 circular toggle button
 * (button.wp-chatbot-ball) is actually painted inside it. Since that
 * outer box keeps pointer-events:auto for its full (mostly invisible)
 * area, it physically intercepts clicks/taps meant for whatever page
 * content happens to sit underneath it once the page is scrolled to the
 * bottom -- confirmed directly via document.elementFromPoint() at the
 * footer's own "Terms & Conditions" link coordinates returning
 * #wp-chatbot-chat-container, not the link itself (Privacy Policy, one
 * row above and just outside this box, was unaffected -- same mechanism,
 * just missed by a few pixels). Fix: make the two oversized wrapper
 * boxes click-through (`pointer-events:none`) on mobile only, then
 * explicitly restore real interactivity on the two pieces that actually
 * need it -- the visible toggle button itself, and the chat board/panel
 * once it's open (`.active-chat-board`, confirmed elsewhere in this file
 * as the reliable "widget is open" class) -- so chatbot functionality is
 * completely unaffected; only the invisible dead space around the icon
 * stops swallowing clicks. Matches this file's own established mobile
 * breakpoint convention (768px, the vendor widget's own matchMedia point
 * -- see the full-screen board rules above) rather than Elementor's
 * separate 767px breakpoint used on homepage-section overrides.
 */
@media screen and (max-width: 768px) {
	#wp-chatbot-chat-container,
	#wp-chatbot-ball-container {
		pointer-events: none;
	}

	#wp-chatbot-chat-container button.wp-chatbot-ball,
	#wp-chatbot-chat-container #wp-chatbot-board-container.active-chat-board {
		pointer-events: auto;
	}
}