Closed feature request

3D viewer needs a fullscreen control

Ray · 2mo ago ·closed by Colby Knox

Ask

Let the 3D model viewer on a page go full screen.

Right now the 3D slot is a fixed panel a few hundred pixels tall. For a dense board it is too small to actually inspect anything — on adom/probing-workcell-load-cell-board the RP2350, the WAGO terminal and the USB-C are all competing for a viewport smaller than the metadata sidebar next to it. Inspecting the model is the whole point of having it on the page.

Open in new tab exists, but that is a different thing: it navigates away, loses the page context, and still opens a windowed viewer.

There is already a pattern to copy

The datasheet viewer in this same repo already does exactly this — lib/viewers/viewer-datasheet.js renders a ⛶ button in its toolbar and calls document.documentElement.requestFullscreen(), delegated through the embed iframe's allow="fullscreen" (added for adom/wiki #52).

lib/viewers/viewer-3d.js has zero fullscreen references. So this is mostly lifting the datasheet viewer's control into the 3D viewer: a ⛶ button in the existing toolbar (beside Ground / Bottom light), the same requestFullscreen call, and allow="fullscreen" on the 3D embed iframe.

Worth doing at the same time: the hero image pane has its own expand affordance in the bottom-left corner, so 3D and Hero should end up with consistent behaviour rather than two different ways to enlarge a panel.

Reported by Ray from the probing-workcell-load-cell-board page.

2 Replies

Colby Knox · 2mo ago

Shipped and live on wiki.adom.inc. Your read of it was exactly right: the mechanism was already sitting in the datasheet viewer, and the 3D embed iframes already carried allow="fullscreen", so this was lifting the control across.

What went in:

  • A fullscreen toggle in the 3D toolbar, beside Ground and Bottom light. Same approach the datasheet viewer uses (fullscreen the document, delegated through the iframe), so unlike Open in new tab it keeps the page and its context underneath.
  • The label tracks the state (Fullscreen / Exit fullscreen), and the canvas is explicitly resized on the transition. Without that nudge the model keeps its letterboxed size in the larger viewport on some browsers, which would have made the control look broken on exactly the dense boards that motivated it.
  • The button hides itself where the Fullscreen API is unavailable, rather than presenting a dead control.

On your consistency point: the hero pane and the 3D pane now render the same icon. The viewer imports the shared fullscreenIcon() from templates.js rather than carrying its own copy, so the two ways to enlarge a panel on a page cannot drift apart later.

One caveat worth stating plainly: I verified the markup, the behavior under test, and the rendered output on prod, but I was not able to complete an interactive in-browser check of the fullscreen transition itself. If it misbehaves on a real board page, reopen and I will chase it.

Ray · 2mo ago

Scoping note for whoever picks this up — the pieces already exist in the repo, so this is assembly rather than new work:

  • T.fullscreenIcon() (lib/templates.js) is already there: the corner expand icon, currently used by the hero image's .img-fs-btn. That is the affordance you can see in the bottom-left of the Hero pane today.
  • The datasheet viewer already does the behaviour (lib/viewers/viewer-datasheet.js): a ⛶ toolbar button calling document.documentElement.requestFullscreen(), delegated through the embed iframe's allow="fullscreen" (added for adom/wiki #52).
  • lib/viewers/viewer-3d.js has zero fullscreen references — it is the one viewer that never got it.

So: reuse fullscreenIcon() for consistency with the hero control, copy the datasheet viewer's handler, and add allow="fullscreen" to the 3D embed iframe. The main thing to get right is that the Babylon canvas resizes on the fullscreen transition (engine.resize() on fullscreenchange), otherwise it renders at the old viewport size in the enlarged element.

Log in to reply.