Share a presentation link that opens directly in presentation mode #97

New issue

Open

opened 2026-04-29 06:59:20 +00:00 by AhmedHanafy725 · 6 comments

AhmedHanafy725 commented 2026-04-29 06:59:20 +00:00

Member

Copy link

Improvement

The board page (issues #82 share modal) lets users share two roles: viewer (read-only) and editor. There's no way to share a link that opens the recipient's tab directly into presentation mode -- presenter clicks the share link, sends it to attendees, attendees see slides immediately, no edit chrome, no need to find the Present button.

Miro / FigJam / Figma all support "Share for presentation" links.

Expected behavior

• The share-board modal (home.html) gains a third row labeled Presentation link with a read-only URL and a Copy button. The board.html in-board Share button (around templates/web/board.html:17) gets the same row in its share dialog if there is one (current implementation calls shareReadonly() -- check whether there's a modal there).
• The presentation-link role is presentation (or viewer-present -- pick one and document it). The server's share.create already accepts a role param.
• The /s/<token> route (crates/hero_whiteboard_ui/src/routes.rs::web_shared_board) recognizes the new role and serves the board page with a query parameter ?present=1 (or a body flag rendered into the template) so the client knows to auto-start presentation mode.
• The board page, on load, if ?present=1 is in the URL, calls WhiteboardFrames.startPresentation() after the board has loaded. The toolbar / minimap / property panel are still hidden via the existing body.wb-presenting machinery.
• Presentation-link viewers cannot edit. The simplest implementation is to reuse the existing viewer (read-only) permission semantics; the ?present=1 flag is purely a UX hint that auto-enters present mode. If the underlying share role is viewer, the user already can't write.
• The control bar's Exit button still works -- exiting drops the user into a read-only board view.

Affected files (expected)

• crates/hero_whiteboard_ui/src/routes.rs::web_shared_board -- when the share role is presentation (or when an extra ?present=1 query param is present), pass present_mode: true into the template; serve the read-only board template (the same one used for viewer role today).
• crates/hero_whiteboard_ui/templates/web/board.html and/or board_view.html -- on DOMContentLoaded, if the host injected a present_mode flag, call WhiteboardFrames.startPresentation() once the board's objects have loaded.
• crates/hero_whiteboard_ui/templates/web/home.html::openShareModal -- add a third row to the share-board modal: Presentation link with a Copy button. On first open, lazily create a share.create with role: 'presentation' (or reuse viewer + the ?present=1 query). Cache the URL like the existing view/edit URLs.

No SDK / openrpc edits if we choose the viewer role + ?present=1 query approach (zero server-side change). If we add a new presentation role, the openrpc spec gets one more enum value but no behavior change.

Recommended: viewer role + ?present=1 query param. Smaller surface, no DB / openrpc changes.

Acceptance criteria

• Share-board modal shows a third row Presentation link with a Copy button.
• The presentation link is a /s/<viewer_token>?present=1 URL.
• Opening the URL navigates to the read-only board, then auto-starts presentation mode after objects load.
• The presenter's prev/next/exit buttons and keyboard shortcuts work.
• Clicking Exit drops into the same read-only board view that a normal viewer link would show.
• If the board has zero frames, the no-frames toast (#87) appears once and the user lands in the regular read-only view.
• Copy button writes the URL to the clipboard and shows the existing green Copied! toast.
• Diff is contained to routes.rs, board.html (and/or board_view.html), and home.html.
• cargo check / clippy / fmt --check / test clean.

Notes

• The ?present=1 query param is read in JS via new URLSearchParams(location.search).get('present') === '1'. Defer the start until after loadBoards / loadObjects finishes, otherwise the canvas tries to fit the frame before the frame even exists. The simplest pattern is a single setTimeout(start, 0) after WhiteboardApp.init resolves.
• Don't expose a separate per-presentation token. A presentation link is just a viewer link with the auto-start hint; revoking the viewer share also revokes the presentation link. If we need separate revocation we can add a new role later.
• Don't auto-restart presentation if the user exits and stays on the page -- they may want to read the boards as a viewer afterwards. The auto-start is one-shot per page load.

## Improvement The board page (issues #82 share modal) lets users share two roles: viewer (read-only) and editor. There's no way to share a link that opens the recipient's tab directly into presentation mode -- presenter clicks the share link, sends it to attendees, attendees see slides immediately, no edit chrome, no need to find the Present button. Miro / FigJam / Figma all support "Share for presentation" links. ## Expected behavior - The share-board modal (`home.html`) gains a third row labeled `Presentation link` with a read-only URL and a Copy button. The board.html in-board Share button (around `templates/web/board.html:17`) gets the same row in its share dialog if there is one (current implementation calls `shareReadonly()` -- check whether there's a modal there). - The presentation-link role is `presentation` (or `viewer-present` -- pick one and document it). The server's `share.create` already accepts a `role` param. - The `/s/<token>` route (`crates/hero_whiteboard_ui/src/routes.rs::web_shared_board`) recognizes the new role and serves the board page with a query parameter `?present=1` (or a body flag rendered into the template) so the client knows to auto-start presentation mode. - The board page, on load, if `?present=1` is in the URL, calls `WhiteboardFrames.startPresentation()` after the board has loaded. The toolbar / minimap / property panel are still hidden via the existing `body.wb-presenting` machinery. - Presentation-link viewers cannot edit. The simplest implementation is to reuse the existing viewer (read-only) permission semantics; the `?present=1` flag is purely a UX hint that auto-enters present mode. If the underlying share role is `viewer`, the user already can't write. - The control bar's Exit button still works -- exiting drops the user into a read-only board view. ## Affected files (expected) - `crates/hero_whiteboard_ui/src/routes.rs::web_shared_board` -- when the share role is `presentation` (or when an extra `?present=1` query param is present), pass `present_mode: true` into the template; serve the read-only board template (the same one used for `viewer` role today). - `crates/hero_whiteboard_ui/templates/web/board.html` and/or `board_view.html` -- on DOMContentLoaded, if the host injected a `present_mode` flag, call `WhiteboardFrames.startPresentation()` once the board's objects have loaded. - `crates/hero_whiteboard_ui/templates/web/home.html::openShareModal` -- add a third row to the share-board modal: `Presentation link` with a Copy button. On first open, lazily create a `share.create` with `role: 'presentation'` (or reuse `viewer` + the `?present=1` query). Cache the URL like the existing view/edit URLs. No SDK / openrpc edits if we choose the `viewer` role + `?present=1` query approach (zero server-side change). If we add a new `presentation` role, the openrpc spec gets one more enum value but no behavior change. Recommended: **`viewer` role + `?present=1` query param.** Smaller surface, no DB / openrpc changes. ## Acceptance criteria - [ ] Share-board modal shows a third row `Presentation link` with a Copy button. - [ ] The presentation link is a `/s/<viewer_token>?present=1` URL. - [ ] Opening the URL navigates to the read-only board, then auto-starts presentation mode after objects load. - [ ] The presenter's prev/next/exit buttons and keyboard shortcuts work. - [ ] Clicking Exit drops into the same read-only board view that a normal viewer link would show. - [ ] If the board has zero frames, the no-frames toast (#87) appears once and the user lands in the regular read-only view. - [ ] Copy button writes the URL to the clipboard and shows the existing green `Copied!` toast. - [ ] Diff is contained to `routes.rs`, `board.html` (and/or `board_view.html`), and `home.html`. - [ ] `cargo check / clippy / fmt --check / test` clean. ## Notes - The `?present=1` query param is read in JS via `new URLSearchParams(location.search).get('present') === '1'`. Defer the start until after `loadBoards` / `loadObjects` finishes, otherwise the canvas tries to fit the frame before the frame even exists. The simplest pattern is a single `setTimeout(start, 0)` after `WhiteboardApp.init` resolves. - Don't expose a separate per-presentation token. A presentation link is just a viewer link with the auto-start hint; revoking the viewer share also revokes the presentation link. If we need separate revocation we can add a new role later. - Don't auto-restart presentation if the user exits and stays on the page -- they may want to read the boards as a viewer afterwards. The auto-start is one-shot per page load.

AhmedHanafy725 commented 2026-04-29 11:54:08 +00:00

Author

Member

Copy link

Spec — Issue #97: Share a presentation link that opens directly in presentation mode

Objective

Add a third "Presentation link" row to both share dialogs. The link is the existing viewer share URL with ?present=1 appended. On page load, if ?present=1 is present in the URL, auto-start WhiteboardFrames.startPresentation() after the board's objects have loaded.

Approach

Per the issue body's recommendation: reuse the existing viewer share role + a ?present=1 query param. No server / SDK / openrpc / DB changes.

Confirmed in code

• home.html::openShareModal::renderRows (lines 730-748) renders the existing two-row markup; the view URL is computed as window.location.origin + WB_BASE + '/s/' + viewerShare.token (line 767). The local copyLink(url) helper (line 782, fully wired post-#99 with execCommand fallback + red error toast) is reusable.
• ui-helpers.js::shareReadonly (line 17) builds the in-board share dialog with the same view-URL math; it uses WhiteboardApp.copyToClipboard (post-#99) for Copy buttons.
• app.js::loadBoard (line 192) is the post-load hook: at its end, all objects/connectors/comments have rendered. A setTimeout(..., 0) after handleUrlGroupNavigation() (line 268) is the safe spot to call WhiteboardFrames.startPresentation().
• routes.rs::web_shared_board (line 356) does not need changes — it already serves the read-only template for viewer role and the editor template for editor role; the JS reads location.search directly and Axum/Askama don't strip query strings.
• WhiteboardFrames.startPresentation already exists on the public API (used by togglePresentation). For zero-frame boards it calls window.showNoFramesNotice() and returns — no special-casing needed here.

Files to Modify

• crates/hero_whiteboard_ui/static/web/js/whiteboard/app.js — auto-start hook at the end of loadBoard().
• crates/hero_whiteboard_ui/templates/web/home.html — add a third row in renderRows.
• crates/hero_whiteboard_ui/static/web/js/whiteboard/ui-helpers.js — add a third row in shareReadonly.

Files to Leave Alone

• routes.rs, share.rs handlers, openrpc.json, all server crates, SDK — no changes.
• frames.js — startPresentation already does the right thing.
• board.html chrome / CSS — body.wb-presenting already hides the toolbar/properties/etc.

Step-by-Step Plan

Step 1 — Auto-start hook in app.js

File: crates/hero_whiteboard_ui/static/web/js/whiteboard/app.js

At the end of loadBoard(), after handleUrlGroupNavigation():

// Auto-start presentation mode when ?present=1 is in the URL
try {
    if (new URLSearchParams(location.search).get('present') === '1' &&
        typeof WhiteboardFrames !== 'undefined' && WhiteboardFrames.startPresentation) {
        setTimeout(function() { WhiteboardFrames.startPresentation(); }, 0);
    }
} catch (e) {}

The setTimeout(fn, 0) defers until the current microtask queue drains so Konva's batchDraw and any outstanding redraws settle before focusFrame reads stage dimensions. The try/catch keeps the readonly polling path safe in browsers without URLSearchParams (none in our target set, but defensive).

Dependencies: none.

Step 2 — Add presentation-link row to the home-page share modal

File: crates/hero_whiteboard_ui/templates/web/home.html

In renderRows(viewUrl, editUrl) (lines 730-748), after the existing Edit link block, append a third block. The presentation URL is viewUrl + '?present=1':

'<div style="margin-top:12px;">' +
    '<label style="display:block;margin-bottom:4px;font-size:12px;color:var(--wb-text-muted);">Presentation link</label>' +
    '<div style="display:flex;gap:8px;">' +
        '<input type="text" readonly value="' + escapeAttr(viewUrl + '?present=1') + '" ' +
            'style="flex:1;display:block;box-sizing:border-box;width:100%;padding:8px 12px;border:1px solid var(--wb-border);border-radius:6px;background:var(--wb-bg);color:var(--wb-text);font-size:13px;" />' +
        '<button class="btn btn-sm btn-primary" onclick="copyLink(\'' + escapeAttr(viewUrl + '?present=1') + '\')">Copy</button>' +
    '</div>' +
'</div>';

The cache (shareUrlsCache[boardId] = { viewUrl, editUrl }) doesn't need a third field — the present URL is derived from viewUrl on render.

Dependencies: none.

Step 3 — Add presentation-link row to the in-board share dialog

File: crates/hero_whiteboard_ui/static/web/js/whiteboard/ui-helpers.js

In shareReadonly() (line 17), insert a third labeled block after the Edit link block (line 45). Compute presentUrl = viewUrl + '?present=1' once near the existing URL declarations (lines 29-30):

var presentUrl = viewUrl + '?present=1';

And in the dialog HTML, append:

+ '<label style="font-size:12px;color:#888;display:block;margin-bottom:4px;">Presentation link:</label>'
+ '<div style="display:flex;gap:8px;margin-bottom:16px;">'
+ '<input id="share-present-url" type="text" value="' + presentUrl + '" readonly style="flex:1;background:#1a1d21;border:1px solid #495057;border-radius:4px;padding:6px 10px;color:#dee2e6;font-size:13px;"/>'
+ '<button onclick="WhiteboardApp.copyToClipboard(document.getElementById(\'share-present-url\').value)" style="background:#007AFF;border:none;border-radius:4px;padding:6px 12px;color:#fff;font-size:12px;cursor:pointer;">Copy</button>'
+ '</div>'

Place this between the Edit link block and the Close button.

Dependencies: none.

Parallelism

Steps 1, 2, 3 touch different files and are independent.

Acceptance Criteria

• Share-board modal shows a third row Presentation link with a Copy button.
• The presentation link is a /s/<viewer_token>?present=1 URL.
• Opening the URL navigates to the read-only board, then auto-starts presentation mode after objects load.
• The presenter's prev/next/exit buttons and keyboard shortcuts work.
• Clicking Exit drops into the same read-only board view that a normal viewer link would show.
• If the board has zero frames, the no-frames toast (#87) appears once and the user lands in the regular read-only view.
• Copy button writes the URL to the clipboard and shows the existing green Copied! toast.
• Diff is contained to app.js, home.html, and ui-helpers.js.
• cargo check / clippy / fmt --check / test clean.

Notes

• Auto-start is one-shot per page load: once the user exits, they get the regular read-only view. Reload restarts presentation only if ?present=1 is still in the URL. This matches the issue's "Don't auto-restart presentation if the user exits" requirement — WhiteboardFrames.startPresentation is fired exactly once from loadBoard and stopPresentation doesn't trigger any auto-restart.
• The presentation link is just a viewer link with the auto-start hint. Revoking the viewer share also revokes the presentation link. No new per-presentation token; if separate revocation is needed later, a new role can be added.
• The ?present=1 query string survives the Forgejo / Axum / browser routing path because web_shared_board is /s/{token} (path param only); query strings are passed through to the rendered template. The JS reads location.search client-side.
• Editor links can also have ?present=1 appended — there's no role gating in the auto-start hook. Audience-mode protection still relies on the viewer role for write-blocking; the ?present=1 flag is purely UX.
• The viewUrl used in home.html/ui-helpers.js is constructed without an existing query string, so ?present=1 is always the first parameter — no need to handle existing ? cases.

# Spec — Issue #97: Share a presentation link that opens directly in presentation mode ## Objective Add a third "Presentation link" row to both share dialogs. The link is the existing viewer share URL with `?present=1` appended. On page load, if `?present=1` is present in the URL, auto-start `WhiteboardFrames.startPresentation()` after the board's objects have loaded. ## Approach Per the issue body's recommendation: reuse the existing **viewer** share role + a `?present=1` query param. No server / SDK / openrpc / DB changes. ## Confirmed in code - `home.html::openShareModal::renderRows` (lines 730-748) renders the existing two-row markup; the view URL is computed as `window.location.origin + WB_BASE + '/s/' + viewerShare.token` (line 767). The local `copyLink(url)` helper (line 782, fully wired post-#99 with execCommand fallback + red error toast) is reusable. - `ui-helpers.js::shareReadonly` (line 17) builds the in-board share dialog with the same view-URL math; it uses `WhiteboardApp.copyToClipboard` (post-#99) for Copy buttons. - `app.js::loadBoard` (line 192) is the post-load hook: at its end, all objects/connectors/comments have rendered. A `setTimeout(..., 0)` after `handleUrlGroupNavigation()` (line 268) is the safe spot to call `WhiteboardFrames.startPresentation()`. - `routes.rs::web_shared_board` (line 356) does not need changes — it already serves the read-only template for `viewer` role and the editor template for `editor` role; the JS reads `location.search` directly and Axum/Askama don't strip query strings. - `WhiteboardFrames.startPresentation` already exists on the public API (used by `togglePresentation`). For zero-frame boards it calls `window.showNoFramesNotice()` and returns — no special-casing needed here. ## Files to Modify - `crates/hero_whiteboard_ui/static/web/js/whiteboard/app.js` — auto-start hook at the end of `loadBoard()`. - `crates/hero_whiteboard_ui/templates/web/home.html` — add a third row in `renderRows`. - `crates/hero_whiteboard_ui/static/web/js/whiteboard/ui-helpers.js` — add a third row in `shareReadonly`. ## Files to Leave Alone - `routes.rs`, `share.rs` handlers, `openrpc.json`, all server crates, SDK — no changes. - `frames.js` — `startPresentation` already does the right thing. - `board.html` chrome / CSS — `body.wb-presenting` already hides the toolbar/properties/etc. ## Step-by-Step Plan ### Step 1 — Auto-start hook in `app.js` File: `crates/hero_whiteboard_ui/static/web/js/whiteboard/app.js` At the end of `loadBoard()`, after `handleUrlGroupNavigation()`: ```js // Auto-start presentation mode when ?present=1 is in the URL try { if (new URLSearchParams(location.search).get('present') === '1' && typeof WhiteboardFrames !== 'undefined' && WhiteboardFrames.startPresentation) { setTimeout(function() { WhiteboardFrames.startPresentation(); }, 0); } } catch (e) {} ``` The `setTimeout(fn, 0)` defers until the current microtask queue drains so Konva's batchDraw and any outstanding redraws settle before `focusFrame` reads stage dimensions. The `try/catch` keeps the readonly polling path safe in browsers without `URLSearchParams` (none in our target set, but defensive). Dependencies: none. ### Step 2 — Add presentation-link row to the home-page share modal File: `crates/hero_whiteboard_ui/templates/web/home.html` In `renderRows(viewUrl, editUrl)` (lines 730-748), after the existing Edit link block, append a third block. The presentation URL is `viewUrl + '?present=1'`: ```js '<div style="margin-top:12px;">' + '<label style="display:block;margin-bottom:4px;font-size:12px;color:var(--wb-text-muted);">Presentation link</label>' + '<div style="display:flex;gap:8px;">' + '<input type="text" readonly value="' + escapeAttr(viewUrl + '?present=1') + '" ' + 'style="flex:1;display:block;box-sizing:border-box;width:100%;padding:8px 12px;border:1px solid var(--wb-border);border-radius:6px;background:var(--wb-bg);color:var(--wb-text);font-size:13px;" />' + '<button class="btn btn-sm btn-primary" onclick="copyLink(\'' + escapeAttr(viewUrl + '?present=1') + '\')">Copy</button>' + '</div>' + '</div>'; ``` The cache (`shareUrlsCache[boardId] = { viewUrl, editUrl }`) doesn't need a third field — the present URL is derived from `viewUrl` on render. Dependencies: none. ### Step 3 — Add presentation-link row to the in-board share dialog File: `crates/hero_whiteboard_ui/static/web/js/whiteboard/ui-helpers.js` In `shareReadonly()` (line 17), insert a third labeled block after the Edit link block (line 45). Compute `presentUrl = viewUrl + '?present=1'` once near the existing URL declarations (lines 29-30): ```js var presentUrl = viewUrl + '?present=1'; ``` And in the dialog HTML, append: ```js + '<label style="font-size:12px;color:#888;display:block;margin-bottom:4px;">Presentation link:</label>' + '<div style="display:flex;gap:8px;margin-bottom:16px;">' + '<input id="share-present-url" type="text" value="' + presentUrl + '" readonly style="flex:1;background:#1a1d21;border:1px solid #495057;border-radius:4px;padding:6px 10px;color:#dee2e6;font-size:13px;"/>' + '<button onclick="WhiteboardApp.copyToClipboard(document.getElementById(\'share-present-url\').value)" style="background:#007AFF;border:none;border-radius:4px;padding:6px 12px;color:#fff;font-size:12px;cursor:pointer;">Copy</button>' + '</div>' ``` Place this between the Edit link block and the Close button. Dependencies: none. ### Parallelism Steps 1, 2, 3 touch different files and are independent. ## Acceptance Criteria - [ ] Share-board modal shows a third row `Presentation link` with a Copy button. - [ ] The presentation link is a `/s/<viewer_token>?present=1` URL. - [ ] Opening the URL navigates to the read-only board, then auto-starts presentation mode after objects load. - [ ] The presenter's prev/next/exit buttons and keyboard shortcuts work. - [ ] Clicking Exit drops into the same read-only board view that a normal viewer link would show. - [ ] If the board has zero frames, the no-frames toast (#87) appears once and the user lands in the regular read-only view. - [ ] Copy button writes the URL to the clipboard and shows the existing green `Copied!` toast. - [ ] Diff is contained to `app.js`, `home.html`, and `ui-helpers.js`. - [ ] `cargo check / clippy / fmt --check / test` clean. ## Notes - Auto-start is one-shot per page load: once the user exits, they get the regular read-only view. Reload restarts presentation only if `?present=1` is still in the URL. This matches the issue's "Don't auto-restart presentation if the user exits" requirement — `WhiteboardFrames.startPresentation` is fired exactly once from `loadBoard` and `stopPresentation` doesn't trigger any auto-restart. - The presentation link is just a viewer link with the auto-start hint. Revoking the viewer share also revokes the presentation link. No new per-presentation token; if separate revocation is needed later, a new role can be added. - The `?present=1` query string survives the Forgejo / Axum / browser routing path because `web_shared_board` is `/s/{token}` (path param only); query strings are passed through to the rendered template. The JS reads `location.search` client-side. - Editor links can also have `?present=1` appended — there's no role gating in the auto-start hook. Audience-mode protection still relies on the `viewer` role for write-blocking; the `?present=1` flag is purely UX. - The `viewUrl` used in `home.html`/`ui-helpers.js` is constructed without an existing query string, so `?present=1` is always the first parameter — no need to handle existing `?` cases.

AhmedHanafy725 commented 2026-04-29 11:56:44 +00:00

Author

Member

Copy link

Test Results

• cargo fmt --all -- --check: pass
• cargo check --workspace: pass
• node --check app.js: pass
• node --check ui-helpers.js: pass

The Askama home.html template re-compiled cleanly via cargo check.

## Test Results - cargo fmt --all -- --check: pass - cargo check --workspace: pass - node --check app.js: pass - node --check ui-helpers.js: pass The Askama home.html template re-compiled cleanly via cargo check.

AhmedHanafy725 commented 2026-04-29 11:56:44 +00:00

Author

Member

Copy link

Implementation Summary

Three files changed, +21/-0. No server / SDK / openrpc / DB changes.

crates/hero_whiteboard_ui/static/web/js/whiteboard/app.js

At the end of loadBoard(), after handleUrlGroupNavigation():

try {
    if (new URLSearchParams(location.search).get('present') === '1' &&
        typeof WhiteboardFrames !== 'undefined' && WhiteboardFrames.startPresentation) {
        setTimeout(function() { WhiteboardFrames.startPresentation(); }, 0);
    }
} catch (e) {}

The setTimeout(fn, 0) defers until the current task settles so Konva's batchDraw and any outstanding redraws finish before focusFrame reads stage dimensions. The try/catch is a defensive guard.

crates/hero_whiteboard_ui/templates/web/home.html

In openShareModal::renderRows, appended a third row labeled "Presentation link" after the existing Edit link row. The URL is viewUrl + '?present=1'. The Copy button reuses the local copyLink(url) helper (post-#99 has the execCommand fallback + red error toast for non-secure contexts).

crates/hero_whiteboard_ui/static/web/js/whiteboard/ui-helpers.js

In shareReadonly(), computed var presentUrl = viewUrl + '?present=1'; and added a third labeled block in the dialog markup between the Edit link and Close button. The Copy button uses WhiteboardApp.copyToClipboard.

Verification

• cargo fmt --all -- --check: clean
• cargo check --workspace: clean (Askama re-compiled home.html successfully)
• node --check app.js: clean
• node --check ui-helpers.js: clean

Manual smoke test

1. From the home page, open the share dialog for any board with at least one frame. Confirm three rows: View, Edit, Presentation.
2. Copy the Presentation link, open it in a new tab. The board loads in read-only mode and immediately enters presentation mode (chrome hidden, spotlight on the first frame).
3. Use prev/next/exit controls; pressing Exit returns to the read-only board view.
4. Reload the presentation tab — presentation auto-starts again because ?present=1 is still in the URL.
5. From within the board, click the in-board Share button. Same three rows.
6. Open the Presentation link on a board with zero frames. The existing no-frames toast appears once and the user lands in the regular read-only view.

Notes / scope

• Auto-start is one-shot per page load: loadBoard runs once, the setTimeout(start, 0) fires once, and stopPresentation doesn't trigger any auto-restart.
• Presentation links revoke alongside the underlying viewer share; no separate per-presentation token.
• Editor links can also have ?present=1 appended; there's no role gating in the auto-start hook (audience-mode write-blocking still relies on the underlying viewer role).
• The viewUrl built in both share dialogs is constructed without an existing query string, so ?present=1 is always the first parameter.

## Implementation Summary Three files changed, +21/-0. No server / SDK / openrpc / DB changes. ### `crates/hero_whiteboard_ui/static/web/js/whiteboard/app.js` At the end of `loadBoard()`, after `handleUrlGroupNavigation()`: ```js try { if (new URLSearchParams(location.search).get('present') === '1' && typeof WhiteboardFrames !== 'undefined' && WhiteboardFrames.startPresentation) { setTimeout(function() { WhiteboardFrames.startPresentation(); }, 0); } } catch (e) {} ``` The `setTimeout(fn, 0)` defers until the current task settles so Konva's batchDraw and any outstanding redraws finish before `focusFrame` reads stage dimensions. The `try/catch` is a defensive guard. ### `crates/hero_whiteboard_ui/templates/web/home.html` In `openShareModal::renderRows`, appended a third row labeled "Presentation link" after the existing Edit link row. The URL is `viewUrl + '?present=1'`. The Copy button reuses the local `copyLink(url)` helper (post-#99 has the execCommand fallback + red error toast for non-secure contexts). ### `crates/hero_whiteboard_ui/static/web/js/whiteboard/ui-helpers.js` In `shareReadonly()`, computed `var presentUrl = viewUrl + '?present=1';` and added a third labeled block in the dialog markup between the Edit link and Close button. The Copy button uses `WhiteboardApp.copyToClipboard`. ### Verification - `cargo fmt --all -- --check`: clean - `cargo check --workspace`: clean (Askama re-compiled `home.html` successfully) - `node --check app.js`: clean - `node --check ui-helpers.js`: clean ### Manual smoke test 1. From the home page, open the share dialog for any board with at least one frame. Confirm three rows: View, Edit, Presentation. 2. Copy the Presentation link, open it in a new tab. The board loads in read-only mode and immediately enters presentation mode (chrome hidden, spotlight on the first frame). 3. Use prev/next/exit controls; pressing Exit returns to the read-only board view. 4. Reload the presentation tab — presentation auto-starts again because `?present=1` is still in the URL. 5. From within the board, click the in-board Share button. Same three rows. 6. Open the Presentation link on a board with zero frames. The existing no-frames toast appears once and the user lands in the regular read-only view. ### Notes / scope - Auto-start is one-shot per page load: `loadBoard` runs once, the `setTimeout(start, 0)` fires once, and `stopPresentation` doesn't trigger any auto-restart. - Presentation links revoke alongside the underlying viewer share; no separate per-presentation token. - Editor links can also have `?present=1` appended; there's no role gating in the auto-start hook (audience-mode write-blocking still relies on the underlying `viewer` role). - The `viewUrl` built in both share dialogs is constructed without an existing query string, so `?present=1` is always the first parameter.

AhmedHanafy725 commented 2026-04-29 12:07:26 +00:00

Author

Member

Copy link

Follow-up

Two gaps fixed in templates/web/board.html (+32/-0):

1. Inline shareReadonly was missed in the previous commit

The toolbar Share button on the board page calls an inline shareReadonly defined in board.html itself (not the duplicate in ui-helpers.js that the previous commit patched). The inline dialog now also includes the Presentation link row, matching the home-page modal and the ui-helpers.js version.

2. Share button while presenting

Added a Share button to the #presentation-controls bar between the divider and the Exit button:

<button type="button" class="pres-btn" id="pres-share" title="Copy presentation link" aria-label="Copy presentation link"><i class="bi bi-share"></i></button>

Click handler in the existing bindPresentation IIFE:

• Looks up an existing viewer share via share.list; falls back to share.create if none exists.
• Builds location.origin + WB_BASE + '/s/' + token + '?present=1'.
• Copies via WhiteboardApp.copyToClipboard (the existing helper with the execCommand fallback + green/red toast).
• Caches the resolved URL on first click to avoid re-running RPCs on rapid clicks.

The presenter now never has to leave presentation mode to grab the link. Audience opens the URL → board loads in viewer mode → presentation auto-starts.

Verification

• cargo fmt --all -- --check: clean
• cargo check --workspace: clean (Askama re-compiled board.html)

Manual smoke test

1. Open a board with at least one frame, click Present.
2. The presentation control bar shows: Prev | counter | Next | Share | Exit.
3. Click Share — green "Copied!" toast; URL is on the clipboard.
4. Open the copied URL in a new tab — board loads in viewer mode and auto-enters presentation.
5. Click Share again rapidly — no duplicate share.create RPCs (the URL is cached for the session).

## Follow-up Two gaps fixed in `templates/web/board.html` (+32/-0): ### 1. Inline `shareReadonly` was missed in the previous commit The toolbar Share button on the board page calls an inline `shareReadonly` defined in `board.html` itself (not the duplicate in `ui-helpers.js` that the previous commit patched). The inline dialog now also includes the **Presentation link** row, matching the home-page modal and the `ui-helpers.js` version. ### 2. Share button while presenting Added a Share button to the `#presentation-controls` bar between the divider and the Exit button: ```html <button type="button" class="pres-btn" id="pres-share" title="Copy presentation link" aria-label="Copy presentation link"><i class="bi bi-share"></i></button> ``` Click handler in the existing `bindPresentation` IIFE: - Looks up an existing viewer share via `share.list`; falls back to `share.create` if none exists. - Builds `location.origin + WB_BASE + '/s/' + token + '?present=1'`. - Copies via `WhiteboardApp.copyToClipboard` (the existing helper with the execCommand fallback + green/red toast). - Caches the resolved URL on first click to avoid re-running RPCs on rapid clicks. The presenter now never has to leave presentation mode to grab the link. Audience opens the URL → board loads in viewer mode → presentation auto-starts. ### Verification - `cargo fmt --all -- --check`: clean - `cargo check --workspace`: clean (Askama re-compiled `board.html`) ### Manual smoke test 1. Open a board with at least one frame, click Present. 2. The presentation control bar shows: Prev | counter | Next | Share | Exit. 3. Click Share — green "Copied!" toast; URL is on the clipboard. 4. Open the copied URL in a new tab — board loads in viewer mode and auto-enters presentation. 5. Click Share again rapidly — no duplicate `share.create` RPCs (the URL is cached for the session).

AhmedHanafy725 commented 2026-04-29 12:19:07 +00:00

Author

Member

Copy link

Follow-up — fix viewer-mode chrome and live slide sync

Two new bugs found while testing the presentation share link, both fixed in this commit (+140/-0):

Bug 1 — Viewer template lacked all presentation chrome

The shared viewer link served board_view.html, which had zero presentation chrome: no wb-presenting CSS, no #pres-spotlight, no #presentation-controls, no bindPresentation script. So when ?present=1 triggered WhiteboardFrames.startPresentation(), the canvas zoomed to the first frame but:

• No black backdrop appeared (no spotlight element).
• The viewer could still pan the board (no pointer-events: none rule).

Fix: added the same presentation <style> block (navbar/zoom/minimap hide + pointer-events:none + spotlight + control bar) and the <div id="pres-spotlight"> / <div id="presentation-controls"> markup to board_view.html. The viewer's control bar shows only Counter and Exit — Prev/Next belong to the presenter (audience follows). Added a small bindPresentation script that wires the Exit button, the spotlight position listener via WhiteboardFrames.setOnChange, and an Esc-to-exit keydown handler.

Bug 2 — Slide changes didn't propagate to other windows

When the presenter clicked Next/Prev, the audience's window stayed on the original slide. There was no broadcast hook — frames.js updated the local index without telling other clients.

Fix: added _broadcastSlide() to frames.js, called from nextFrame and prevFrame after the index change. It sends {type: 'presentation.slide', data: {index}} via the existing WhiteboardSync._wsSend. New applyRemoteSlide(index) handles incoming messages: it gates on presentationMode === true, refreshes the frame list, clamps the index, and re-runs focusFrame under an _applyingSync flag so the receiver's own broadcast is suppressed (no echo loop).

sync.js routes the new message type:

} else if (msg.type === 'presentation.slide') {
    if (msg.data && typeof msg.data.index === 'number' && typeof WhiteboardFrames !== 'undefined' && WhiteboardFrames.applyRemoteSlide) {
        WhiteboardFrames.applyRemoteSlide(msg.data.index);
    }
}

The existing per-board WebSocket fan-out + the msg.sender === localUserId echo-skip in handleWsMessage mean the presenter's own broadcast doesn't loop back to themselves.

Files changed

• crates/hero_whiteboard_ui/templates/web/board_view.html (+108): presentation CSS, spotlight, control bar (Counter + Exit only), bindPresentation script, Esc handler.
• crates/hero_whiteboard_ui/static/web/js/whiteboard/frames.js (+28): _applyingSync, _broadcastSlide, applyRemoteSlide. Wired into nextFrame/prevFrame. Exported applyRemoteSlide.
• crates/hero_whiteboard_ui/static/web/js/whiteboard/sync.js (+4): presentation.slide branch in handleWsMessage.

Verification

• cargo fmt --all -- --check: clean
• cargo check --workspace: clean (Askama re-compiled board_view.html)
• node --check on frames.js and sync.js: clean

Manual smoke test

1. Open a board with several frames as the editor, click Present, then click the Share button to copy the presentation link.
2. Paste the link into another browser/tab — it loads in viewer mode and auto-enters presentation. The black backdrop is now present, the canvas can't be panned, and the counter shows "1 / N".
3. In the editor window, click Next or press Right Arrow — the viewer window advances to the same slide within the WS-throttle window (~200ms).
4. Click Prev — viewer follows.
5. Press Esc in the viewer — the viewer exits to the regular read-only board view.
6. Editor's own Next/Prev never causes an echo on the editor itself (sender === localUserId skip).

Notes / scope

• Audience can't navigate slides — only the presenter drives. This matches Miro/FigJam's "follow the presenter" model.
• Start/Stop are not synced — viewers auto-start because of ?present=1, and Esc lets them exit independently. If we ever want force-follow on start/stop (presenter starts → everyone starts), that's a small extension on top of _broadcastSlide.
• The _applyingSync guard prevents echo even if a receiver's local code path were to invoke nextFrame/prevFrame programmatically while applying a remote slide — current code doesn't, but defense in depth.
• getFrames() is called inside applyRemoteSlide so the receiver's local frames array is up-to-date even if frames were added/removed since the last startPresentation.
• The duplication of presentation CSS/markup between board.html and board_view.html is acceptable for now; if the chrome gets more complex, refactor into an Askama partial.

## Follow-up — fix viewer-mode chrome and live slide sync Two new bugs found while testing the presentation share link, both fixed in this commit (+140/-0): ### Bug 1 — Viewer template lacked all presentation chrome The shared viewer link served `board_view.html`, which had zero presentation chrome: no `wb-presenting` CSS, no `#pres-spotlight`, no `#presentation-controls`, no `bindPresentation` script. So when `?present=1` triggered `WhiteboardFrames.startPresentation()`, the canvas zoomed to the first frame but: - No black backdrop appeared (no spotlight element). - The viewer could still pan the board (no `pointer-events: none` rule). **Fix:** added the same presentation `<style>` block (navbar/zoom/minimap hide + `pointer-events:none` + spotlight + control bar) and the `<div id="pres-spotlight">` / `<div id="presentation-controls">` markup to `board_view.html`. The viewer's control bar shows only Counter and Exit — Prev/Next belong to the presenter (audience follows). Added a small `bindPresentation` script that wires the Exit button, the spotlight position listener via `WhiteboardFrames.setOnChange`, and an Esc-to-exit keydown handler. ### Bug 2 — Slide changes didn't propagate to other windows When the presenter clicked Next/Prev, the audience's window stayed on the original slide. There was no broadcast hook — `frames.js` updated the local index without telling other clients. **Fix:** added `_broadcastSlide()` to `frames.js`, called from `nextFrame` and `prevFrame` after the index change. It sends `{type: 'presentation.slide', data: {index}}` via the existing `WhiteboardSync._wsSend`. New `applyRemoteSlide(index)` handles incoming messages: it gates on `presentationMode === true`, refreshes the frame list, clamps the index, and re-runs `focusFrame` under an `_applyingSync` flag so the receiver's own broadcast is suppressed (no echo loop). `sync.js` routes the new message type: ```js } else if (msg.type === 'presentation.slide') { if (msg.data && typeof msg.data.index === 'number' && typeof WhiteboardFrames !== 'undefined' && WhiteboardFrames.applyRemoteSlide) { WhiteboardFrames.applyRemoteSlide(msg.data.index); } } ``` The existing per-board WebSocket fan-out + the `msg.sender === localUserId` echo-skip in `handleWsMessage` mean the presenter's own broadcast doesn't loop back to themselves. ### Files changed - `crates/hero_whiteboard_ui/templates/web/board_view.html` (+108): presentation CSS, spotlight, control bar (Counter + Exit only), `bindPresentation` script, Esc handler. - `crates/hero_whiteboard_ui/static/web/js/whiteboard/frames.js` (+28): `_applyingSync`, `_broadcastSlide`, `applyRemoteSlide`. Wired into `nextFrame`/`prevFrame`. Exported `applyRemoteSlide`. - `crates/hero_whiteboard_ui/static/web/js/whiteboard/sync.js` (+4): `presentation.slide` branch in `handleWsMessage`. ### Verification - `cargo fmt --all -- --check`: clean - `cargo check --workspace`: clean (Askama re-compiled `board_view.html`) - `node --check` on `frames.js` and `sync.js`: clean ### Manual smoke test 1. Open a board with several frames as the editor, click Present, then click the Share button to copy the presentation link. 2. Paste the link into another browser/tab — it loads in viewer mode and auto-enters presentation. The black backdrop is now present, the canvas can't be panned, and the counter shows "1 / N". 3. In the editor window, click Next or press Right Arrow — the viewer window advances to the same slide within the WS-throttle window (~200ms). 4. Click Prev — viewer follows. 5. Press Esc in the viewer — the viewer exits to the regular read-only board view. 6. Editor's own Next/Prev never causes an echo on the editor itself (`sender === localUserId` skip). ### Notes / scope - Audience can't navigate slides — only the presenter drives. This matches Miro/FigJam's "follow the presenter" model. - Start/Stop are not synced — viewers auto-start because of `?present=1`, and Esc lets them exit independently. If we ever want force-follow on start/stop (presenter starts → everyone starts), that's a small extension on top of `_broadcastSlide`. - The `_applyingSync` guard prevents echo even if a receiver's local code path were to invoke `nextFrame`/`prevFrame` programmatically while applying a remote slide — current code doesn't, but defense in depth. - `getFrames()` is called inside `applyRemoteSlide` so the receiver's local `frames` array is up-to-date even if frames were added/removed since the last `startPresentation`. - The duplication of presentation CSS/markup between `board.html` and `board_view.html` is acceptable for now; if the chrome gets more complex, refactor into an Askama partial.

AhmedHanafy725 commented 2026-04-29 12:27:06 +00:00

Author

Member

Copy link

Follow-up — audience joins on the presenter's current slide

When a new audience opens the presentation link mid-presentation, they used to land on slide 1 regardless of where the presenter was. Now they snap to the presenter's current slide on join.

Mechanism

• frames.js exports a new announceCurrentSlide() that broadcasts the local currentFrameIndex over the existing presentation.slide WebSocket message — but only if the local client is in presentation mode. Internally it just calls the existing _broadcastSlide().
• sync.js's join handler now calls WhiteboardFrames.announceCurrentSlide() after the existing presence update. So whenever any client receives a join, anyone currently presenting tells the new joiner where they are. Idempotent: receivers whose index already matches no-op.
• Race fix: if a presenter's broadcast arrives at the new audience BEFORE they finish loadBoard and auto-start presentation, applyRemoteSlide caches the index in _pendingRemoteSlide. At the end of startPresentation, the pending index is applied (no flicker since this happens inside the same task as the initial focusFrame). If no pending slide is cached, startPresentation itself broadcasts our own arrival so an existing presenter can rebroadcast back if needed.
• Audience can't accidentally drive presentation: _broadcastSlide is only called by nextFrame / prevFrame (both gated by presentationMode) and by announceCurrentSlide/startPresentation (also gated). Audience's board_view.html doesn't have Prev/Next buttons.

Files changed

• crates/hero_whiteboard_ui/static/web/js/whiteboard/frames.js (+24/-1)
  • Added _pendingRemoteSlide cache and announceCurrentSlide public export.
  • applyRemoteSlide caches index when not in presentation mode instead of dropping it.
  • startPresentation applies any pending slide after the initial focus, otherwise broadcasts to advertise our presence.
• crates/hero_whiteboard_ui/static/web/js/whiteboard/sync.js (+5)
  • join handler calls WhiteboardFrames.announceCurrentSlide() after presence update.

Verification

• cargo fmt --all -- --check: clean
• cargo check --workspace: clean
• node --check frames.js, sync.js: clean

Manual smoke test

1. Editor enters presentation mode and clicks Next a few times to reach slide 3 of 5.
2. Open the presentation link in a new tab. The audience tab loads, auto-starts presentation, briefly shows slide 1, then immediately snaps to slide 3 once the presenter's broadcast arrives.
3. If the audience opens the link before the presenter has even started, the audience starts at slide 1 and broadcasts; once the presenter starts, their initial broadcast (or any subsequent prev/next) snaps everyone to alignment.
4. Mid-presentation Next/Prev still propagates to all attendees as before.
5. New attendee joining at slide 5/5 lands on slide 5, not 1.

Notes

• The brief slide-1-then-snap is acceptable; eliminating it would require deferring startPresentation until we hear from a presenter, which adds startup latency and an unclear timeout policy. The current snap is one frame in practice.
• If two presenters somehow broadcast different indices (shouldn't happen with one editor + viewers), the last presentation.slide to arrive wins. No conflict resolution beyond that.
• _pendingRemoteSlide is cleared after startPresentation consumes it; subsequent applyRemoteSlide calls go through the normal path.

## Follow-up — audience joins on the presenter's current slide When a new audience opens the presentation link mid-presentation, they used to land on slide 1 regardless of where the presenter was. Now they snap to the presenter's current slide on join. ### Mechanism - `frames.js` exports a new `announceCurrentSlide()` that broadcasts the local `currentFrameIndex` over the existing `presentation.slide` WebSocket message — but only if the local client is in presentation mode. Internally it just calls the existing `_broadcastSlide()`. - `sync.js`'s `join` handler now calls `WhiteboardFrames.announceCurrentSlide()` after the existing presence update. So whenever any client receives a join, anyone currently presenting tells the new joiner where they are. Idempotent: receivers whose index already matches no-op. - Race fix: if a presenter's broadcast arrives at the new audience BEFORE they finish `loadBoard` and auto-start presentation, `applyRemoteSlide` caches the index in `_pendingRemoteSlide`. At the end of `startPresentation`, the pending index is applied (no flicker since this happens inside the same task as the initial `focusFrame`). If no pending slide is cached, `startPresentation` itself broadcasts our own arrival so an existing presenter can rebroadcast back if needed. - Audience can't accidentally drive presentation: `_broadcastSlide` is only called by `nextFrame` / `prevFrame` (both gated by `presentationMode`) and by `announceCurrentSlide`/`startPresentation` (also gated). Audience's `board_view.html` doesn't have Prev/Next buttons. ### Files changed - `crates/hero_whiteboard_ui/static/web/js/whiteboard/frames.js` (+24/-1) - Added `_pendingRemoteSlide` cache and `announceCurrentSlide` public export. - `applyRemoteSlide` caches index when not in presentation mode instead of dropping it. - `startPresentation` applies any pending slide after the initial focus, otherwise broadcasts to advertise our presence. - `crates/hero_whiteboard_ui/static/web/js/whiteboard/sync.js` (+5) - `join` handler calls `WhiteboardFrames.announceCurrentSlide()` after presence update. ### Verification - `cargo fmt --all -- --check`: clean - `cargo check --workspace`: clean - `node --check frames.js`, `sync.js`: clean ### Manual smoke test 1. Editor enters presentation mode and clicks Next a few times to reach slide 3 of 5. 2. Open the presentation link in a new tab. The audience tab loads, auto-starts presentation, briefly shows slide 1, then immediately snaps to slide 3 once the presenter's broadcast arrives. 3. If the audience opens the link before the presenter has even started, the audience starts at slide 1 and broadcasts; once the presenter starts, their initial broadcast (or any subsequent prev/next) snaps everyone to alignment. 4. Mid-presentation Next/Prev still propagates to all attendees as before. 5. New attendee joining at slide 5/5 lands on slide 5, not 1. ### Notes - The brief slide-1-then-snap is acceptable; eliminating it would require deferring `startPresentation` until we hear from a presenter, which adds startup latency and an unclear timeout policy. The current snap is one frame in practice. - If two presenters somehow broadcast different indices (shouldn't happen with one editor + viewers), the last `presentation.slide` to arrive wins. No conflict resolution beyond that. - `_pendingRemoteSlide` is cleared after `startPresentation` consumes it; subsequent `applyRemoteSlide` calls go through the normal path.

AhmedHanafy725 referenced this issue from a commit 2026-04-29 12:31:46 +00:00

feat(share): presentation link that opens directly in presentation mode

AhmedHanafy725 referenced this issue from a commit 2026-04-29 12:31:46 +00:00

feat(present): copy presentation link from the control bar

AhmedHanafy725 referenced this issue from a commit 2026-04-29 12:31:46 +00:00

feat(present): viewer-mode chrome and live slide sync

AhmedHanafy725 referenced this issue from a commit 2026-04-29 12:31:46 +00:00

feat(present): late-joining audience snaps to the presenter's current slide

AhmedHanafy725 referenced this issue from a commit 2026-04-29 12:31:46 +00:00

fix(present): float toast at top while presenting so it isn't hidden by the control bar

AhmedHanafy725 self-assigned this 2026-04-29 12:32:13 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

development

development_16

development_5

development_mik2

main

No results found.

Labels

Clear labels   

prio_critical

  

prio_low

  

type_bug

  

type_contact

  

type_issue

  

type_lead

  

type_question

  

type_story

  

type_task

No labels

prio_critical

prio_low

type_bug

type_contact

type_issue

type_lead

type_question

type_story

type_task

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

AhmedHanafy725

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lhumina_code/hero_whiteboard#97

No description provided.