Enhancement: Add "Copy Move History" button for quick clipboard export

[aniketchauhan16]

Problem Statement

Currently, the move history is visible in the UI but cannot be easily copied for sharing or analysis. Users have to manually select and copy moves, which is inconvenient and inconsistent across devices (especially mobile).

Proposed Solution

Add a "Copy" button in the Move History section that allows users to copy the full move list to the clipboard in a clean, readable format.

• Extract move history from existing DOM/state
• Format moves as a standard string (e.g., "1. e4 e5 2. Nf3 Nc6 ...")
• Use navigator.clipboard.writeText() for copying
• Provide simple feedback (e.g., "Copied!" message or temporary button state)

Alternatives Considered

• Download move history as a file (similar to PGN export) ,but this adds more complexity and overlaps with existing/planned features.
• Manual selection and copy already possible but not user-friendly, especially on mobile devices.

The copy button provides a lightweight and immediate solution.

Additional Context

This is a small UX enhancement that improves usability of the existing move history without modifying game logic or backend behavior.

It aligns well with current UI/UX improvements and can be implemented as a minimal, frontend-only change.

[aniketchauhan16]

I’d like to work on this. Planning to implement a minimal frontend-only solution using the existing move history state and clipboard API.

Will share approach shortly.

[aniketchauhan16]

Approach

• Add a "Copy" button in the Move History section
• Extract moves from existing state/DOM (no logic changes)
• Format moves into readable string (e.g., "1. e4 e5 ...")
• Use navigator.clipboard.writeText()
• Add small UI feedback (e.g., "Copied!" state)

Scope: frontend only, no backend or game logic changes.

[aniketchauhan16]

I’ve verified this behavior on the deployed version as well.
Let me know if I can proceed with the implementation once assigned.

[EDWARD-012]

Nice enhancement idea overall, and the scope looks appropriately small for a frontend-only change.

One suggestion before implementation: please tighten the acceptance criteria a bit so the behavior is unambiguous. In particular:

• define the exact copied output format more explicitly instead of only giving an example
• specify that the copied text should come from the same move-history data/state used to render the UI, not from parsing DOM text
• include a fallback/error path for cases where navigator.clipboard.writeText() is unavailable or permission is denied, with clear user feedback

That would make the issue easier to implement consistently and avoid edge-case regressions later.

[aniketchauhan16]

Thanks for the suggestions, refining the acceptance criteria below:

1. Exact copied format:
   The copied text will follow standard move notation grouped by turn, exactly as:
   1. e4 e5 2. Nf3 Nc6 3. Bb5 a6

   • Each turn should be clearly separated
   • Turn number followed by White and Black moves
   • No extra UI labels or metadata included

2. Source of copied text:

• The copied string will be generated directly from the same move-history data/state used to render the UI, not by parsing DOM text, ensuring consistency with the game state.

3. Fallback / error handling:
   If navigator.clipboard.writeText() is unavailable or fails, the app will:

   • show a temporary user message: "Unable to copy moves"

   • keep the button text unchanged

   • avoid silent failure

     Let me know if this aligns with expectations, and I’ll proceed once assigned.

[priyanjalikumar6-source]

Hi @aniketchauhan16 👋

I’d like to work on this issue under GSSoC.

The proposed solution looks good and straightforward for a frontend-only enhancement. I will implement it using the existing move history state (as suggested in the discussion), and ensure:

Clean formatting of moves (standard turn-based notation)
Clipboard copy using navigator.clipboard.writeText()
Proper fallback handling if clipboard access fails
UI feedback (e.g., temporary “Copied!” state)

I’ll make sure the implementation is consistent with the current UI structure and avoids DOM parsing, as recommended.

Please assign this issue to me. I’ll start working on it right away.

Thank you!