Bohdan Triapitsyn
96c011a8ef
The tablet ran the phone layout with a half-finished iPad draft on top: two custom sidebars, a leftover overflow menu, split Files/Changes header buttons, and phone-width sheets stretched across a 13" screen. This brings it onto the phone's navigation model and keeps only the differences a large screen earns. - Sessions are a persistent resizable left sidebar; the overflow menu is gone and its destinations moved into that sidebar's footer (connected instance, settings, pending web update) and into the workspace drawer. - The workspace (Changes / Files / Terminal / Notes / MCP) is the phone's drawer everywhere: a resizable right sidebar where the screen can host one (up to 900px) and the full-cover drawer otherwise, with its mounted panes — an open diff, an edited file, an attached terminal — surviving rotation. - Header dropdowns are anchored popovers: the recents switcher mirrors the usage overlay on the left, and its trigger is sized to the title rather than to the free width. - App-level pages (settings, instances, update, an opened plan) render as centered dialogs instead of covering the screen. - Overlays center on the chat column through published insets, so the model and directory pickers no longer sit off-centre; the directory picker also stops overriding the shared width clamp. - Wide chat layout applies to mobile surfaces, where a tablet chat column is finally wide enough for the setting to mean anything. The layout gate is a live size class rather than a device check, so Android tablets and foldables are covered by the same code: - `enabled` when the shortest viewport side is at le sw600dp). The short side is what makes this a size question instead of a device question — a phone reports ~360-430 whichev unfolded book foldable ~600+, and folding shut drops back under it. iPads also answer on identity, since iPadOS hands out od - `roomyForPanels` when landscape and at least 1000px wide, which is what it takes to host the sidebar, the panel and a readabl foldables miss it in BOTH orientations — their long side is barely wider than a tablet's short one — so they keep the portr Every consumer re-decides instead of remembering wha open sidebar closes if the device folds shut under it. iPad behaviour is unchanged: its landscape widths all clear the panel ones do not, exactly as the previous orientation check did. Hardware keyboards are read natively. iOS reports them through GCKeyboard, published to the web layer at document start and kep disconnect and foregrounding; the layer stops inferring once that answers. A single early publish was not enough — the connect no already-attached keyboard fires before the page exists, and GameController can populate late — so the state is re-published across resume. With a keyboard attached the draft screen keeps its starter chips and the composer never collapses; tablets skip the colla Runtimes with no native answer fall back to inferring it from the keyboard bridge, and only ever conclude "hardware" from silen Also: sidebar rows no longer sit on a differently ti footer is no longer clipped by an over-tall content box, the resize handles moved above the panes' own overlays so they can actu now-unreachable overflow menu, fullscreen terminal/MCP/notes surfaces and their locale key are deleted. Device behaviour is unverified — the tablet layout, keyboard bridge and the foldable size class have not been exercised on hardware, and the 600/1000 thresholds are derived fr rather than measured on a foldable.
58 lines
2.2 KiB
TypeScript
58 lines
2.2 KiB
TypeScript
import { afterEach, describe, expect, test } from 'bun:test';
|
|
|
|
import { readTabletLayout, type TabletLayout } from './device';
|
|
|
|
// No module mocking here on purpose: mock.module is process-global and would
|
|
// leak into every other test file. Outside a Capacitor shell isIPadApp() is
|
|
// already false, so a bare viewport stub isolates the geometry rules.
|
|
const originalWindow = globalThis.window;
|
|
|
|
const setViewport = (width: number, height: number) => {
|
|
(globalThis as { window?: unknown }).window = {
|
|
innerWidth: width,
|
|
innerHeight: height,
|
|
// isIPadApp() reaches for the Capacitor markers; a plain web location
|
|
// keeps it on its `false` path without mocking the module.
|
|
location: { protocol: 'https:', search: '' },
|
|
};
|
|
};
|
|
|
|
const withViewport = (width: number, height: number): TabletLayout => {
|
|
setViewport(width, height);
|
|
return readTabletLayout();
|
|
};
|
|
|
|
afterEach(() => {
|
|
(globalThis as { window?: unknown }).window = originalWindow;
|
|
});
|
|
|
|
describe('readTabletLayout', () => {
|
|
test('a phone stays a phone in both orientations', () => {
|
|
expect(withViewport(390, 844).enabled).toBe(false);
|
|
// The long side alone must never qualify — this is the case a plain
|
|
// width threshold gets wrong.
|
|
expect(withViewport(844, 390).enabled).toBe(false);
|
|
});
|
|
|
|
test('a tablet qualifies in both orientations', () => {
|
|
expect(withViewport(834, 1194).enabled).toBe(true);
|
|
expect(withViewport(1194, 834).enabled).toBe(true);
|
|
});
|
|
|
|
test('side panels need real width, so a tablet in portrait keeps the drawer', () => {
|
|
expect(withViewport(834, 1194).roomyForPanels).toBe(false);
|
|
expect(withViewport(1194, 834).roomyForPanels).toBe(true);
|
|
});
|
|
|
|
test('an unfolded foldable is a tablet but never roomy enough for panels', () => {
|
|
// Book foldables are near-square: the long side is barely wider than a
|
|
// tablet's short one, so both orientations keep the portrait layout.
|
|
expect(withViewport(690, 840)).toEqual({ enabled: true, roomyForPanels: false });
|
|
expect(withViewport(840, 690)).toEqual({ enabled: true, roomyForPanels: false });
|
|
});
|
|
|
|
test('folding shut drops back to the phone layout', () => {
|
|
expect(withViewport(370, 900).enabled).toBe(false);
|
|
});
|
|
});
|