Issue 122 Description Box Was A Stub In The Corner

The description box was a stub in the corner

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

---

What you saw

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.

---

What was actually wrong

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:

cell	got	width
row 1, col 1 (1fr)	.compose-label-row	1476px
row 1, col 2 (300px)	.compose-editor	300 × 62
row 2, col 1 (1fr)	.compose-side	1476px

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.

---

⚠️ It was our own mobile work, and here is why it was invisible

.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.

---

The fix

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; }
}

---

A second fault found on the way: the tablet band

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.

---

📁 Files changed

File	What
🟩 self-service/new-ticket.php	Stated grid placement for the three panes; the mobile block resets it; the editor's minimum height moved from the 768px block to the 900px one

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

---

How it was verified

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

	before	after
1888px	editor 300 × 62 at x=1541	editor 1476 × 609 at x=47
900px	editor 806 × 49	editor 806 × 240
360px	editor 310 × 240	editor 310 × 240 — unchanged

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.

It was one place, not several

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.

---

What this means for you

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.

---

Related

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