Reported: #122 by tjedelhauser, August 2026 · Module: Self‑Service Portal · Fixed in: #1389, #1390

Raising a ticket from the portal on an ordinary desktop screen, the box you type your problem into was about 300px wide and 62px tall, tucked into the top‑right corner — while Mailbox, Priority and Attachments, the things you barely interact with, had the entire width of the page beneath it.

The reporter's screenshot was taken at 1888px, and it shows the shape precisely: a large empty area on the left where the message should be, and the editor squeezed into the corner.

The compose screen is a two‑column layout — the message on the left, the settings panel on the right:

.compose-body {
    display: grid;
    grid-template-columns: 1fr 300px;
}

That container has three children, not two:

<div class="compose-body">
    <div class="compose-label-row"> Description … </div>
    <div class="compose-editor">    the TinyMCE box  </div>
    <aside class="compose-side">    mailbox, priority, attachments </aside>
</div>

CSS Grid does not leave a gap when it runs out of the cells you described. It auto‑places each child into the next free cell, creating implicit rows as it goes:

So the label took the column meant for the message, the message was pushed into the column meant for the panel, and the panel dropped to a row of its own. Every element did exactly what it was told; nothing errored.

🔑 Adding a child to a grid is a layout change, even when it is "just a label". Auto‑placement fills the next cell with whatever comes next — it has no notion of which child was supposed to be where.

.compose-label-row was added in #1284, part of the portal's mobile round, and for a good reason: the message body was the only field on the form with nothing naming it.

It is correct on a phone. Below 900px the layout collapses to a single column:

@media (max-width: 900px) { .compose-body { grid-template-columns: 1fr; } }

…and in a one‑column grid, auto‑placement stacks all three children in DOM order — label, editor, panel — which is exactly right. The two‑column desktop arrangement is the only one where a third child has anywhere wrong to go, and no phone‑width test could have revealed it.

🔑 A change that is correct in the layout you are testing can be wrong in the layout you are not. A media query does not only change sizes; it changes how many cells there are, and therefore what a new child does.

Stated placement instead of auto‑placement, so the arrangement no longer depends on how many children happen to be present:

.compose-body {
    grid-template-columns: 1fr 300px;
    grid-template-rows: auto 1fr;      /* label sized to content, editor takes the rest */
}
.compose-label-row { grid-column: 1; grid-row: 1; }
.compose-editor    { grid-column: 1; grid-row: 2; }
.compose-side      { grid-column: 2; grid-row: 1 / -1; }

A fourth child added later cannot repeat this: unplaced children now flow past the stated cells rather than displacing them.

⚠️ The mobile block has to undo the placement, not just the column count. grid-row: 1 / -1 on the panel would otherwise sit it beside the label in a one‑column grid, and grid-template-rows: auto 1fr would hand the editor's row all the leftover height:

@media (max-width: 900px) {
    .compose-body { grid-template-columns: 1fr; grid-template-rows: none; }
    .compose-label-row, .compose-editor, .compose-side { grid-column: auto; grid-row: auto; }
}

Between 769px and 900px — where a tablet held upright lands — the editor measured 806 × 49: a toolbar with a sliver underneath.

In a single column the flex chain has no leftover height to distribute, so flex: 1 on the editor resolves to almost nothing. That had been found and fixed during the phone round, with the symptom recorded in the stylesheet in as many words ("measured on a phone it was 266x50") — but the remedy was written into the max-width: 768px block, while the single‑column layout it was remedying starts at 900px.

So the fix was right and its media query was one breakpoint too narrow, leaving 131px of widths uncovered. It predates #122 rather than being caused by it.

🔑 A rule that fixes a layout belongs at the breakpoint that introduces that layout, not at the width you happened to be testing at.

One file, CSS only. No markup, no JavaScript, no other page.

Measured at eleven widths from 1888px down to 360px, driving the real page behind a portal session.

The 360px row is the control that matters: the phone layout is byte‑identical before and after, which is the whole point of the fix being placement rather than a rewrite.

The wiki's usual finding is "it was N places, not one". Here it genuinely was one, and that is worth showing rather than asserting. A detector was written for the shape — a multi‑track grid with more visible children than tracks, no declared rows to hold them, and no explicit placement — and run across the portal and ten analyst screens.

Its first form was too blunt: it flagged the waffle menu's 3×3 dot grid, a 22‑module launcher and a 26‑field detail grid, all of which are meant to wrap onto many rows. Narrowing it to grids that have not declared enough rows for their children and have not placed them explicitly left:

• self-service/new-ticket.php — clean after the fix (the stated placement reads as deliberate, which is what it is);
• .waffle-modules — repeat(4, 1fr) with 22 children, an intentionally wrapping launcher;
• one two‑column settings form with 7 fields, likewise intentional.

No other instance of the fault.

If you raise tickets from the portal on a desktop or a laptop, the description box now fills the left‑hand side of the screen at full height, and the settings sit in a panel on the right. On a phone nothing changes. If you are on a tablet in portrait, the message box is no longer a sliver.

• Mobile‑Friendly — the rollout this came out of, and its one hard rule, which this is a reminder applies in both directions
• Bugs resolved