bvandeusen
16e0268da7
Image viewer (#609): - The next (▶) arrow was offset from the viewport edge (right:16px) so it floated over the 320px metadata side panel. Offset it off a shared --fc-side-w var so it sits at the image's right edge instead; full-width again below 900px when the panel stacks under the image. - Arrow nav was fully disabled whenever a text field was focused. Now it yields to the caret ONLY when the field has text; an empty tag-entry field still navigates ←/→. Extracted to utils/textEntry.js (arrowNavAllowed). ESC behaviour unchanged (already closes the modal, overlay-aware). Test: arrowNavAllowed — empty/non-text → navigate, text present → don't. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
22 lines
753 B
JavaScript
22 lines
753 B
JavaScript
// Helpers for deciding whether a keyboard shortcut should fire or yield to a
|
|
// focused text field.
|
|
|
|
export function isTextEntry (el) {
|
|
if (!el) return false
|
|
const tag = el.tagName
|
|
return tag === 'INPUT' || tag === 'TEXTAREA' || el.isContentEditable
|
|
}
|
|
|
|
export function hasText (el) {
|
|
if (!el) return false
|
|
if (el.isContentEditable) return (el.textContent || '').length > 0
|
|
return (el.value || '').length > 0
|
|
}
|
|
|
|
// Prev/next arrow navigation should fire UNLESS focus is in a text entry that
|
|
// already has content — in that case the arrows belong to the caret so it can
|
|
// move through the text. An empty (or non-text) target still navigates.
|
|
export function arrowNavAllowed (target) {
|
|
return !(isTextEntry(target) && hasText(target))
|
|
}
|