Skip to content

[Cleanup] Improve Layout #531

New issue
New issue
Closed
Closed
[Cleanup] Improve Layout#531
#779 (+4)
Milestone
v3.0.0.rc1
@JSv4

Description

@JSv4
JSv4
opened on Oct 20, 2025

Mobile & Desktop Layout Issues

Multiple persistent layout and UX issues, primarily affecting mobile views. Issues span across DocumentKnowledgeBase, Corpuses view, and their child components.

Issue #1: Bottom tray menu covers chat input for doc chat (Mobile)

Location: frontend/src/components/knowledge_base/document/DocumentKnowledgeBase.tsx

Analysis:

  • FloatingInputWrapper (line 248) has z-index: 850 on mobile
  • Mobile tab bar/tray menu likely has higher z-index causing overlap
  • Mobile positioning uses top: 80px instead of bottom positioning (lines 258-270)
  • Root Cause: Z-index stacking context issue - need proper z-index hierarchy for mobile UI elements

Components Involved:

  • FloatingInputWrapper (DocumentKnowledgeBase.tsx:248)
  • MobileTabBar (DocumentKnowledgeBase.tsx:106)
  • ChatTray (needs verification)

Issue #2: Chat bar not locked to bottom, disappears as conversation grows (Mobile)

Location: frontend/src/components/knowledge_base/document/right_tray/ChatTray.tsx (referenced but file not fully analyzed)

Expected Structure (from CorpusChat.tsx as reference):

  • MessagesArea: flex: 1, overflow-y: auto (scrollable)
  • ChatInputWrapper: flex-shrink: 0 (sticky to bottom)

Root Cause: ChatTray component likely missing flex-shrink: 0 on input container, or parent container not using flexbox properly.

Reference Implementation:

See CorpusChat.tsx:1501-1675 for correct pattern.

Issue #3: Cursor not auto-focused in input on corpus page load (Mobile)

Location: frontend/src/views/Corpuses.tsx:446-451 (CorpusQueryView component)

Current Code:

useEffect(() => {
  if (isSearchMode && inputRef.current) {
    setTimeout(() => inputRef.current?.focus(), 100);
  }
}, [isSearchMode]);

Root Causes:

  1. Timing issue: FloatingSearchContainer may not be visible when focus is called
  2. Mobile browser restriction: iOS Safari blocks programmatic focus unless triggered by user gesture
  3. Component lifecycle: Effect may fire before input element is rendered
  4. Missing initial mount focus: Only focuses when isSearchMode changes, not on initial load

Fix Strategy:

  • Add autoFocus attribute to input element
  • Focus on initial mount AND mode changes
  • May need user gesture workaround for iOS

Issue #4: Corpus chat back and home buttons don't work (Mobile)

Locations:

  • frontend/src/views/Corpuses.tsx:483-527 (ChatNavigationHeader)
  • frontend/src/components/corpuses/CorpusChat.tsx:1448-1477 (ChatNavigationHeader)

Analysis:

CRITICAL: Two separate navigation headers competing for control, violating routing mantra.

Header 1: Corpuses.tsx (lines 483-527)

<BackButton onClick={show_query_view_state === "VIEW" 
  ? () => showQueryViewState("ASK") 
  : resetToSearch
}>
  • Back: calls showQueryViewState("VIEW") or resetToSearch
  • Home: calls showQueryViewState("ASK")

Header 2: CorpusChat.tsx (lines 1448-1477)

{use_mobile_layout && isConversation && (
  <ChatNavigationHeader>
    <BackButton onClick={() => {
      if (selectedConversationId || !isNewChat) {
        setSelectedConversationId(undefined);
        setIsNewChat(false);
        setChat([]);
        setServerMessages([]);
      } else {
        showQueryViewState("ASK");
      }
    }}>

Root Cause: On mobile, both headers may be rendered, causing state conflicts. CorpusChat's internal navigation doesn't properly communicate with parent CorpusQueryView state.

Routing System Violations:

Per docs/frontend/routing_system.md:

  • ❌ Components manually managing state instead of using navigation utilities
  • ❌ Multiple components trying to control same state (showQueryViewState)
  • ✅ Should: Use callback props for parent-child communication
  • ✅ Should: Centralize navigation logic via URL navigation
  • ✅ Should: Call navigate() and let routing system handle state

Fix Strategy:

  • Remove duplicate headers
  • Use callback props (onBack, onHome) to communicate between CorpusChat and parent
  • Centralize navigation logic in one place
  • Consider moving showQueryViewState to URL-driven state if it needs to be bookmarkable

Reference: See routing docs sections on "Navigation Components" and "Best Practices - Navigation"

Issue #5: Edit LabelSet modal is atrocity on mobile

Location: frontend/src/components/widgets/CRUD/LabelSetSelector.tsx (component not analyzed)

Analysis:

Used in three CRUD modals in Corpuses.tsx:

  • Lines 2340, 2374, 2398

Root Cause: LabelSetSelector component lacks mobile-responsive styling.

Components to Check:

  • LabelSetSelector component
  • CRUDModal parent component
  • Form layout/grid system

Issue #6: Ensure we can see and edit corpus and doc agent prompts

Type: Feature Request (not a bug)

Locations to Add:

  • Corpus prompts: Add to frontend/src/components/corpuses/CorpusSettings.tsx
  • Document prompts: Need to check if DocumentSettings panel exists

Implementation Needed:

  • Add prompt editor fields to settings panels
  • Wire up GraphQL mutations for saving prompts
  • Add validation and preview functionality

Issue #7: Corpus settings mobile layout is bad, especially metadata controls

Location: frontend/src/components/corpuses/CorpusSettings.tsx (imported at Corpuses.tsx:116, used at line 2005)

Analysis:

Specific problem area: "metadata controls" - form inputs for corpus metadata

Root Cause: CorpusSettings component lacks mobile-responsive styling for form controls.

Areas to Fix:

  • Form field layout/stacking
  • Input field sizing
  • Button positioning/sizing
  • Modal/panel width constraints
  • Metadata control grid/flex layout

Summary by File

DocumentKnowledgeBase.tsx

Corpuses.tsx

CorpusChat.tsx

Components Not Yet Analyzed

Routing System References

Relevant Documentation: docs/frontend/routing_system.md

Issue #4 Specific Guidance:

From Best Practices - Navigation section:

// ✅ CORRECT - Let routing system handle state
const handleNavigate = () => {
  navigate("/corpuses");
  // DON'T manually manage state - routing system handles this
};

From Component Ecosystem - Navigation Components section:

  • NavMenu/MobileNavMenu pattern: Just call navigate(), no manual state clearing
  • Use callback props for parent-child communication
  • Avoid multiple components competing for same state control

Key Rules for Issue #4 Fix:

  1. Remove duplicate navigation headers - only one source of truth
  2. Use callback props - CorpusChat should accept onBack and onHome callbacks from parent
  3. Parent controls navigation - CorpusQueryView (in Corpuses.tsx) should own the navigation decisions
  4. Child reports intent - CorpusChat just calls onBack() or onHome() and parent decides what that means
  5. URL-driven state - Consider if showQueryViewState should be in URL for bookmarking/sharing

Next Steps

  1. Fix z-index hierarchy for mobile UI elements (Bump postgres from 14.5 to 15.0 in /compose/production/postgres #1)
  2. Verify and fix ChatTray flexbox layout (Bump traefik from v2.8.7 to v2.9.1 in /compose/production/traefik #2)
  3. Add autoFocus and improve focus handling (Bump actions/setup-node from 3.4.1 to 3.5.1 #3)
  4. Consolidate navigation headers following routing mantra (Bump responses from 0.21.0 to 0.22.0 #4)
  5. Add mobile responsive styles to LabelSetSelector (Bump actions/checkout from 3.0.2 to 3.1.0 #5)
  6. Implement agent prompt editing UI (Bump flake8-isort from 4.1.1 to 5.0.0 #6)
  7. Add mobile responsive styles to CorpusSettings (Bump mypy from 0.971 to 0.982 #7)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions