Mobile Friendly Change Management

Mobile: Change Management

Change Management is the eighth module made mobile‑friendly. Same hard rule: one @media (max-width: 768px) block, desktop byte‑identical.

🧰 Code‑level catalogue of the techniques: Mobile: Techniques & Tricks.

Shipped as #1184, commit 9d8a16d6. LAYER 23.

---

Scope — six pages, three of them free

Page	State
change-management/ — list, detail, editor	Done — sidebar → header strip, cards stacked, pane hiding (LAYER 23)
change-management/approvals.php	Done — sidebar becomes a single scrolling filter row
change-management/table.php	Done by opting in — inherits .dt-wrap from the Assets round
change-management/calendar.php	Done by opting in — inherits the Calendar layer
change-management/settings/	Done by opting in — the shared settings rules, plus the body marker
change-management/help.php	Done by opting in — inherits 16h

🔑 Half the module cost nothing. That is the return on building earlier layers around shared class names (.dt-page, .calendar-grid, .container) rather than page ids — a new module that reuses a component inherits its mobile treatment for free.

---

The widest starting point of the rollout

viewport = 360   docScrollW = 1286   ← on ALL SIX pages
index.php      sidebar 280  →  list pane   80px
approvals.php  sidebar 260  →  list pane  100px

1286px on a 360px screen, and an 80px column of content — the narrowest yet recorded here. The 1286 was the shared header, so opting in fixed it outright; the 80px was not touched by that at all.

---

LAYER 23

It mirrors LAYER 22 closely, because the module is built the same way: a fixed sidebar beside a flexible pane, plus a list/detail swap the module already does in its own JS.

⚠️ grid-column: 1 / -1 is not enough when the DOM order fights you

The sidebar holds three sections: Search, Status filters, New change — in that order. Making the filters span both columns should have left the two buttons sharing the top line. It didn't, because the filters sit between them in the DOM, so the grid placed Search on row 1, filters on row 2, and New change on row 3.

.changes-sidebar .sidebar-section:has(.status-filter-list) {
    grid-column: 1 / -1;
    order: 1;              /* ← move the filters LAST */
}

order moves the filters after both buttons, which puts the two actions side by side and reads better anyway: do the thing, then narrow what you are looking at.

The approvals sidebar has no wrapper to convert

Its filters are direct children of the sidebar, with no list element around them, so there is nothing to turn into a strip. The sidebar itself becomes the scrolling row, with the "Filter" heading riding along at the start rather than being hidden — it costs one word of scroll and it is the only thing naming what the chips are.

One wrapper covers three panes

var showView = window.showView;
window.showView = function (view) {
    var out = showView.apply(this, arguments);
    setPane(view === 'detail' || view === 'editor' ? view : 'list');
    return out;
};

A cleaner hook than Problem Management's two wrappers: showView('list' | 'detail' | 'editor') is a single synchronous function, so there is no promise to wait on and no failure path to guard.

---

⚠️ The bug the measurements could not see

Every containment check passed — docScrollW === innerWidth, zero uncontained elements — while the change list looked like this: priority and status pills marching off the right‑hand edge, and the assignee colliding with the date.

.change-card         { display: flex; align-items: center; gap: 16px; }  /* ref | title+meta | badges */
.change-card-badges  { flex-shrink: 0; }                                  /* ← four badges that will not give way */

Four badges that refuse to shrink make the card wider than the screen whatever the panes do, and because an ancestor scrolls, the document never widens. The page was contained; the content was off the edge of the box it sat in.

.change-card        { flex-direction: column; align-items: stretch; gap: 6px; }
.change-card-title  { white-space: normal; overflow: visible; }   /* two lines beat an ellipsis here */
.change-card-meta   { flex-wrap: wrap; gap: 2px 12px; }
.change-card-badges { flex-wrap: wrap; flex-shrink: 1; }

🔑 flex-shrink: 0 is the single most common cause of a row that will not fit a phone. It is correct on desktop — it stops badges being squashed into illegibility — and it is exactly wrong at 360px, where something has to give. Grep a module's CSS for it before wondering why a row overflows.

---

⚠️ …and a false positive in my own probe

The first sweep reported table.php as having a table overflowing its parent: 938 > 326. It wasn't a bug. The parent is the scroller — .dt-wrap with overflow-x: auto — so scrollWidth > clientWidth is precisely what a working scroller looks like.

// A table is only WRONG if it is wider than its box AND no ancestor scrolls.
let scrolled = false;
for (let p = t; p; p = p.parentElement) {
    const ox = getComputedStyle(p).overflowX;
    if (ox === 'auto' || ox === 'scroll') { scrolled = true; break; }
}

Re‑checked against asset-management/table.php as a known‑good control: identical readings. When a probe reports a fault on shipped code that has been through a device pass, suspect the probe first.

---

Verification

Check	Result
All six pages at 360px	✅ contained, zero uncontained, no unscrolled table spills
Pane cycle: list → detail → editor → back	✅ sidebar grid → none → none → grid
Desktop @ 1200px and 1400px	body block/row, sidebar 280px, cards still flex-direction: row
data-cm-pane on desktop	✅ never appears, at any point in the cycle
mobile.js parse check	✅ with a negative control
Looked at, not only measured	✅ — and it is the only thing that caught the card bug

---

Known rough edges

• Pre‑existing, not introduced here: at a 1200px desktop window this module's shared header needs 1282px, so the page scrolls sideways until roughly 1290. It is fine at 1400. That is a desktop header issue — this module carries more nav items than the others — and is deliberately left alone.

---

Round 2 (#1185) — "a scrollbar appears but nothing scrolls"

Ed, viewing a change on a phone. The vertical scroll had been working all along; the bar he could see was a horizontal one belonging to .changes-main, and dragging it moved almost nothing.

Written up in full as Techniques §12 — the short version is that .changes-main sets only overflow-y: auto, and per spec that makes overflow-x compute to auto too. It was silently a horizontal scroller, and every containment check passed because an ancestor scroller absorbed the overflow.

The only signal without looking at the page: the pane's box height was 650px and its clientHeight 635px. That 15px is a horizontal scrollbar.

Three things were too wide, all found by measuring against the pane's content edge:

.risk-matrix-wrapper	a flex row — 140px info panel + 30px gap + 256px grid = 426px in a 336px pane. Stacked.
.change-detail-header	space-between with a nowrap action group. The buttons ran past the edge, and once they wrapped, Back sat centred against a two-row block and read as though Delete were lying on top of it. Now packs from the left and wraps as one group.
.linked-incidents-table	squeezed a prose subject. Card feed by §11 — and it is headerless already, so reading order was carrying the meaning anyway.

⚠️ And one mistake worth keeping

I first matched the sticky header's -30px full-bleed to .changes-main's new 12px padding. Wrong box — its parent is .change-detail-content, whose 30px padding is what the -30px cancels. Setting -12px against a still-30px padding un-bled it and made the overflow worse, which is how the error announced itself.

Result: horizontal scrollbar 15px → 0px, scrollWidth === clientWidth, zero elements past the content edge, vertical scroll unaffected. Desktop at 1400px unchanged on every rule touched.

---

Round 3 (#1186) — "you cannot scroll down the page"

Reported twice, and the second time made it clear the first fix had not touched the real cause. The page scrolled the whole time. You could not see it happen.

.change-detail-sticky-header carries the title, the actions and the 11-item meta grid:

	bar height	pane height
1200px	388px	592px	pins, content scrolls beneath, behaves
360px	818px	590px	taller than the thing it is pinned inside

A position: sticky element taller than its scrollport can never scroll away — it stays pinned over the whole visible area. Impact, Category and Requester were not the top of a stuck page; they were the stuck header, filling the screen.

Static below the breakpoint fixes it. Desktop keeps its pinned summary untouched.

🔴 Why I missed it twice

Every measurement said the page scrolled, because it did:

pane.scrollHeight  // 5332
pane.clientHeight  //  590
pane.scrollTop = 500;
pane.scrollTop     //  500  ← works perfectly

scrollTop moves content that is entirely hidden behind a pinned block exactly as it moves content you can see. I was asserting the container could scroll, never that anything visible moved.

The check that finds it, now written up as Techniques §13:

const before = elementFromPoint(cx, cy);   // detail-meta-label
pane.scrollTop = 500;
const after  = elementFromPoint(cx, cy);   // cab-review-section
// before !== after — THIS is what "the page scrolled" means

---

Round 4 (#1187) — the editor "spilling off the side"

Ed, editing a change on a phone: "can you put the tiny mce editor on its own sort of full screen panel — it's causing all sorts of things to spill off the side of the screen."

Two asks in one sentence, and the spill turned out to have its own cause.

The widget was 578px inside a 264px parent

The six rich-text fields — Description, Reason, Risk, Test plan, Rollback, PIR — share one widget behind a tab strip. It is a flex item, and a flex item defaults to min-width: auto: it will not shrink below its own min-content width, which here was the six tabs laid end to end.

.cm-rich-text-widget   578px      ← a flex ITEM that refuses to shrink
its flex parent        264px
.editor-form           292 / 292  ← "contained", because IT is the scroller

TinyMCE then sized its editor to the 578px widget, .editor-form absorbed the difference, and every containment check passed. Two rules fixed it — min-width: 0 on the widget and the usual tab scroller — taking the widget to 264px and the form to scrollWidth === clientWidth. Written up as Techniques §14.

The panel takes the tabs with it

	docked	full screen
widget	264 × 337	360 × 640 — the viewport exactly
typing area	300px	544px

Modelled on the Knowledge editor's pop-out (LAYER 17i) with one difference that matters: Knowledge has one field, this has six behind a strip, so the strip goes full screen too. Full screen on Description that could not reach Rollback would only have moved the problem. The bar names the field being edited, read live from the active tab; Close and the device back button are both ways out, because this tinymce.init has no fullscreen plugin and therefore no toolbar exit.

height: auto !important on .tox-tinymce is load-bearing — init({ height: 300 }) writes an inline pixel height, and a flex: 1 that does not beat it gives you a full-screen panel with a 300px typing area, which looks like the feature working.

⚠️ Two faults caught before shipping

tr() was not in scope. The sibling tr() helpers are nested inside their own module functions. Using one in initChangesMobile would have been a runtime ReferenceError that a parse check cannot see — the file parses perfectly.

The open button was a sibling of the widget. refreshFormLayout() re-parents the widget with host.appendChild(richTextWidget) so it follows whichever section anchors it, and sets display: none on it when nothing does. A sibling button would have been stranded in the section the widget left — or left offering full screen on a hidden widget. Bar and button now live inside the widget. The check is to call the relocating function yourself:

w.refreshFormLayout();
widget.contains(button)   // true — a page that was only loaded never shows you this

🔴 And a harness that measured the wrong thing

The first run reported no editor at all. showView('editor') shows the pane; editCurrentChange() is what calls initEditors(). I had reached the view by the shortest route that rendered it, and skipped the initialisation I came to measure — the same shape of error as Round 3, where the assertion sat next to the question.

w.showView('editor')   → .tox-tinymce count = 0    ← proves nothing
w.editCurrentChange()  → 6 of 6 initialised        ← the real path

Verification

Check	Result
Widget width at 360px	578 → 264; .editor-form 292 / 292
Tab strip	scrolls, 264 / 799
Full-screen panel	360 × 640, exactly the viewport; typing area 300 → 544
Survives refreshFormLayout()	✅ button still inside the widget and visible
Device back button	✅ exits; open button returns
Desktop @ 1200 and 1400px	min-width: auto, position: static, tabs overflow-x: visible, no button, no bar, class never appears
mobile.js parse check	✅ with a negative control

---

Round 5 (#1188) — "lots of padding around the panels"

Ed, still on the edit screen: "there is lots of padding around the panels — I think we only need a few pixels around them for it to look nice."

Measured from the viewport down to a single field:

.editor-form   margin 20px 30px  +  padding 30px   = 88px of 360
field input                                          264px wide

A quarter of the screen on empty space. The 30px is correct on a wide screen — the form is a card floating on the app background and a card needs to breathe. At 360px there is nothing for it to float against.

	before	after
.editor-form	margin: 20px 30px · padding: 30px	margin: 8px · padding: 12px
.editor-header	16px 30px	12px
.editor-footer	12px 30px 16px	10px 12px 12px
field width	264px	312px

12px is what .change-detail-content already uses, so reading a change and editing one now sit on the same margin.

⚠️ Every one of those selectors is shared with Knowledge

.editor-form, .editor-header, .editor-footer and .editor-scroll are not Change Management's. Both modules named their editor the same thing, and LAYER 17's bare rule

.editor-form { padding: 14px; }     /* written for Knowledge */

has been reaching this page all along — which is why the measured padding was 14px and not the 30px the module's own stylesheet declares.

So every rule in 23d is scoped to body.cm-editor-open, a class only change-management.js ever sets. That also means it beats the LAYER 17 rule on specificity (0,2,0 vs 0,1,0) rather than on load order, which is the more robust of the two.

🔑 Before styling a bare .editor-* / .detail-* / .list-* class, grep it across the other modules' CSS. A generic name is usually two modules' name. The tell here was benign — a padding that did not match the stylesheet — but the same shape of mistake going the other way would have silently restyled Knowledge.

The control that proves it: the same headless run loaded knowledge/index.php in a second iframe and asserted its .editor-form still reads margin: 0px; padding: 14px with body.cm-editor-open === false.

Verification

Check	Result
Field width at 360px	264 → 312px
Form contained	344px wide, doc scrollWidth 360
Genuine spills past the form's content edge	zero — the .rich-text-tab hits are the swipe strip, an ancestor scrolls (the Round 1 false positive)
Full-screen panel still exact	✅ 360 × 640, typing area 544px, back button exits
Knowledge control, same run	✅ margin: 0px, padding: 14px, cm-editor-open false
Desktop @ 1400px	margin: 20px 30px, padding: 30px, header 16px 30px, zero spills
Looked at, not only measured	✅ screenshot

---

Round 6 (#1189-#1193) — the edit screen, five more findings

Ed worked through the edit screen on a phone. Every one of these is a case of a rule that is correct in the place it was written.

#1189 The three risk fields huddled against the right edge

.risk-scoring-row { align-items: flex-end; }   /* Change Management: BOTTOM-align */
.editor-form .form-row { flex-direction: column; }   /* LAYER 17: a KNOWLEDGE rule */

align-items acts on the cross axis. The moment the second rule flipped the row into a column, the first one stopped meaning bottom and started meaning right — so all three shrank to their content and lined up on the right at 135 / 135 / 79px.

Neither rule is wrong on its own, and the module that owns each is unaware of the other.

🔑 A property whose meaning depends on flex-direction is a booby trap for any layer that restacks a row. align-items, justify-content, align-self and the margin: auto push all swap axis with the direction. Grep for them before restacking someone else's row.

Now likelihood and impact two-up with the derived score as a bar beneath: 150 / 150 / 312.

#1190 Cards, and one editor at a time

Round 4 put the tabbed widget full screen, and Ed came back with "the tinymce editor is still causing a bit of havoc with the screen layout" — because six TinyMCE instances were still living in a 312px column, each an iframe with its own toolbar, sizing itself independently.

His suggestion, and it is the right shape: show the six fields as read-only cards, each with an Edit button that opens the full-screen editor.

	before	after
TinyMCE instances in the form	6	0
while editing	6	1
fields visible at once	1 (behind a swipe strip)	all 6, with excerpts

The cards also answer a question the tab strip could not: which parts of this change are still empty? One card reads "Not provided" and you can see it without tapping anything.

🔴 The trap, and why this is not a display rule

function getEditorContent(id) {
    const editor = tinymce.get(id);
    return editor ? editor.getContent() : '';     // ← '' when nothing is initialised
}

saveChange() reads all six fields through that, and editorsReady is set but never read — nothing guards it. Simply not initialising the editors would have made Save silently blank all six fields.

So on mobile the textarea becomes the source of truth, and four accessors are wrapped:

wrapped	why
getEditorContent	reads the textarea when no editor is live — this is the one that prevents the data loss
setEditorContent	writes the textarea, so loading a change still fills the fields
initEditors	skips TinyMCE and clears the textareas itself
destroyEditors	closes the panel first, so Cancel mid-edit cannot strand it

That third one is not obvious. The create path clears through tinymce.get(id) directly rather than through setEditorContent:

initEditors(() => { editorIds.forEach(id => { const e = tinymce.get(id); if (e) e.setContent(''); }); });

With no editors that clears nothing, so a new change would have opened pre-filled with the last one's text. The wrapper clears the textareas itself, which covers both callers.

⚠️ editorIds is a top-level const and therefore not a property of the global object — unlike the four functions, which are function declarations and are. The field list is read from the DOM instead. Same trap as the let at script top level note.

No sanitiser needed: the card excerpt is assigned through textContent, so no author-written HTML is ever parsed into the page. And the labels reuse change-management.detail.edit / .not_provided / common.close — the detail view already says exactly those words about exactly these fields, so a phone borrows them rather than adding three strings to 24 locales.

#1191 The date fields, and a limit worth stating

Work start / Work end / Outage start / Outage end are data-width="half" — 146px to show a date, a time and a picker icon.

⚠️ No probe saw this. The parts of an <input type="datetime-local"> live in shadow DOM and overflow inside the control without ever changing its scrollWidth. It measured 144 / 144 — perfectly contained — while reading as clipped. Same family as the crushed table in §11: containment is not legibility.

Ed asked for the time on a line below the date. That cannot be done. The only styling hooks for the parts of a datetime-local are ::-webkit-datetime-edit-*, which are WebKit/Blink-only, and iOS Safari renders the control as a native spinner that ignores them entirely — a rule that "worked" in headless Chrome would have done nothing on the phone the bug came from. Full width gives 312px, which shows 23/02/2026 21:06 in full, which is the outcome that was actually wanted.

:has(input[type="datetime-local"]) rather than the four field keys, so a date field added through Form fields settings is covered without another rule.

#1192 A button that had never been styled

.search-btn { width: 100%; }     /* its ONLY rule in change-management.css */

So the phone drew the browser's default: grey rgb(107,107,107), square corners, 13.3px text, 19px tall — under half a tap target, sitting beside a properly drawn teal one. Problem Management styles the same shared class correctly in its own page, so the fix borrows that shape rather than inventing a third look, and stays an outline button: two solid teal buttons side by side would both read as "the" action.

🔑 And .btn-full { width: 100% } had never applied to New change either. .btn sets no display, so <a class="btn btn-full"> is an inline box — and width does not apply to inline boxes. It had been content-width all along, sitting at the left of its grid cell, which is exactly the gap Ed could see. display: inline-block is what lets both the width reset and the 44px tap height take effect.

#1193 Three modules zooming, one report

iOS zooms into any focused field under 16px and leaves the page zoomed. .search-modal is shared by Change Management, Problem Management and Tickets, and mobile.css had no rule for it at all — LAYER 3's anti-zoom only knows .modal-content, and this is another module-owned class it cannot see.

All three were zooming for the identical reason, so all three were fixed rather than scoping to the one that got reported.

🔴 And one I did to myself

Section 23e had precisely zero measured effect — the Watchtower signal. It was not load order this time. My explanatory comment contained a nested comment terminator:

/* ...
       .risk-scoring-row { align-items: flex-end; }   /* = BOTTOM-align */
   ...the rest of the comment is now CSS... */

CSS comments do not nest. That inner */ closed the comment early, and the parser consumed the remaining prose — and the rules after it — while recovering. A brace count cannot see it, so the checks now include a comment-nesting scan:

awk '{ n=gsub(/\/\*/,"",$0); m=gsub(/\*\//,"",$0);
       if (c && n) print "NESTED /* line " NR;
       c += n-m; if (c<0) c=0; if (c>1) c=1 }' mobile.css

Verification

Check	Result
TinyMCE instances in the form at 360px	6 → 0; exactly 1 while editing
getEditorContent with no editor live	156 chars — the data-loss trap closed
Captured save payload	all 5 populated fields intact, the empty one empty
Create path	all 6 textareas cleared, all 6 cards read "Not provided"
A field hidden in Form fields settings	5 cards, PIR absent
cancelEdit() mid-edit	panel closes, instance removed, back to detail
Risk row	150 / 150 / 312, no longer right-hugging
Date fields	146 → 312px, 23/02/2026 21:06 in full
Buttons	Search 19 → 44px and styled; New change ends at 348 = the exact content edge
Search modal fields under 16px	0 in Change Management, Problem Management and Tickets
Desktop @ 1400px	6 instances, 0 cards, tab strip flex, risk row 317×3, dates two-up at 486, buttons untouched
Looked at, not only measured	✅ screenshots of the cards, the schedule and the sidebar

Known rough edges

• The Search button is unstyled on desktop too — the same 19px grey system button at 1400px. A real defect, but a desktop change sits outside this rollout's "desktop byte-identical" contract, so it is flagged rather than fixed here.
• refreshFormLayout() calls switchTab(firstVisible) when the active tab is hidden, and switchTab reads the implicit global event. Pre-existing, harmless to the cards (they do not read .active), untouched.

Reference

• Mobile‑Friendly — the overview and the rollout state
• Mobile: Techniques & Tricks — the code‑level catalogue
• Mobile: Problem Management — the layer this one mirrors
• Change Management — the module itself