# The layout is wrong on a phone Layout comes from 56 ordered stylesheet layers behind a single index, and a defect at one width is usually invisible in the source and obvious in a browser. Report four things — the route, the viewport width, the `data-ui` name of the element, and the theme — because every visible element carries a `data-ui` name and that is what makes the report reproducible. - **Status:** Available - **Audience:** both - **In the app:** #/home, #/inbox - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/mobile-layout-broken/ ## Where the layout comes from There is no component framework rewriting the page. The styling is 56 ordered layers imported through one index, and every visible element carries a `data-ui` name — which is the handle for a bug report as much as for a test. Because the layers are ordered, the same token name defined in more than one of them resolves by order and specificity rather than by whichever file you happened to open, so reading the source is not a reliable way to find out what a value actually is. The computed value on the live element is. One width is worth naming. The Assistant draws Chat, Needs You, Standing, Memory and Files into a single scroller: at 600 pixels wide and above that is a sidebar, and below it the same content moves into the More menu. A defect that appears only on a narrow phone and never on a desktop very often sits either side of that switch. ## What tends to go wrong - **Something covering something else.** A stack of notifications sat over the assistant launcher on one audience's screens: nothing was broken in the markup, and the control simply could not be clicked. - **A remembered size.** Panel sizes persist per person, and a size remembered from a wider window can hide a control entirely at a narrower one. Reloading does not clear it, because remembering it is the feature. - **A control pushed off the edge.** Long unbreakable text — a URL, an identifier, an address — widens a container and takes the buttons beside it out of reach. - **A theme-dependent difference.** Colour and border tokens differ between light and dark, so an element that is merely low-contrast in one can be invisible in the other. > **Careful** Two of the three defects found on one day in September 2026 were invisible in the code and obvious within thirty seconds of looking at the screen — a notification stack covering the launcher, and a remembered size hiding it. A layout report is worth more than a description of what the code should do. ## What Connect completed Everything except the presentation. The data behind the screen is correct and complete, the request was authorised and scoped as usual, and nothing was lost or altered by the layout being wrong. Work you did before the layout broke is saved; a control you cannot reach is a control you cannot reach, not an action that half happened. ## What Connect did not complete It did not fall back to a usable arrangement, and it did not reset the remembered panel size on your behalf. There is also no in-product way to report a layout defect from the screen it happens on, so the four details below have to travel with the report by hand. ## What you can do 1. Rotate the device, or resize the window past 600 pixels and back. - Result: If the control reappears, you have found the breakpoint involved, which narrows the search enormously. 2. Reset any panel you have dragged to a custom size. - Result: A remembered size is per person and survives reloads, so it can follow you between sessions and look like a product defect. 3. Switch theme once. - Result: If the element becomes visible in the other theme, the problem is a colour token rather than a layout rule, and that is a different fix. 4. Note the route, the width, the `data-ui` name and the theme. - Result: Those four reproduce it. Without the width in particular, a layout report cannot be reproduced by anybody on a different screen. ## What an administrator can do - Look at the same screen as both audiences at the reported width. A defect on one audience's screens and not the other's is common enough here to be checked first rather than last. - Read the computed value on the live element rather than the stylesheet. With ordered layers, a token that looks correct in the source can be overridden by another layer defining the same name. - Check whether the element is present but covered. Something rendered underneath a notification stack is a different fix from something that never rendered. ## When to escalate Escalate when a control cannot be reached at all at a common width — that is a functional defect wearing a cosmetic disguise — or when the same screen is usable for one audience and not the other. Include the four details above; a layout report without a viewport width is usually unreproducible and quietly ends up closed. ## Questions ### Is there a supported minimum width? The published behaviour change is at 600 pixels, where the assistant's side panel becomes a menu. Below that the product is expected to work; a control that becomes unreachable there is a defect worth reporting rather than an unsupported size. ### Why does my colleague not see the same problem? Two reasons are common: a remembered panel size, which is per person, and the audience difference between an Owner session and a customer session. Both produce a defect that is real and reproducible only for some people. ### The text is legible but almost invisible in dark mode. Is that the same bug? It is a related one with a different cause. Colour tokens are defined per theme, so a value that is fine in one can be wrong in the other; report the theme alongside the element name. ## Related - [Defects that are invisible in the source and obvious in a browser](https://connectbyjbrh.com/research/invisible-ui-defects/) - [A focus ring that was defined, valid-looking and computed to nothing](https://connectbyjbrh.com/research/focus-rings-that-computed-to-none/) - [Keyboard navigation gets stuck](https://connectbyjbrh.com/docs/troubleshooting/keyboard-trap/) - [Connect Assistant](https://connectbyjbrh.com/docs/assistant/) - [One implementation, two audiences](https://connectbyjbrh.com/research/two-audiences-one-implementation/) - [Troubleshooting](https://connectbyjbrh.com/docs/troubleshooting/) ## What this page is based on - `docs-source/sources/GENERAL.md` §4, §8 — the frontend layers and the assistant shell - `CLAUDE.md` — the two-audiences gate and the Owner-only defects of 2026-09-04 - Connect capability registry (docs-source/facts.py)