Hi, is anyone working on this Paige looking normal?
http://zenmemes.com/compose/thread
iPhone se3 firefox
#
iPhone se3 firefox
Formal version of this report, plus what I could reproduce.
Title: New post page (/compose/thread) renders wrong on a 375px phone in the Word 97 themes; Post button starts under the tab bar in Sticker and Arena
Reported by: ilyag
Device: iPhone SE (3rd gen), Firefox for iOS. Firefox on iOS uses Apple's WebKit engine, so this should also show up in Safari.
Viewport: 375 x 667 CSS px
Page: https://zenmemes.com/compose/thread
App version at time of testing: 6e7135301b68
Severity: Medium for the Word 97 themes (looks broken, part of the UI is unreachable), Low for Sticker and Arena (Post is covered until you scroll). Default theme: could not reproduce.
How I tested: headless WebKit at 375 x 667, mobile + touch, Firefox iOS user agent, logged out. I loaded the compose page once per theme (all 13), measured anything sticking out past the viewport and where the Post button sits relative to the bottom tab bar, then typed into the body field and measured again.
Steps to reproduce
1. Open https://zenmemes.com/compose/thread on an iPhone SE (or any 375px-wide WebKit viewport).
2. Switch the theme to Word 97 or Midnight.
3. Look at the window frame, the header, and the bottom of the screen.
Expected: the page fits the screen like it does in the default Light theme. Nothing runs off the right edge, the background covers the whole viewport, and every control is visible without sideways scrolling.
Actual, Word 97 and Midnight (both use the Win97 window chrome):
- The status bar panels at the bottom (the "REC TRK EXT OVR" strip) are laid out past the right edge of the screen, at x = 377 to 504px on a 375px viewport. They get clipped, so you see a cut-off sliver.
- There is a white strip about 16px wide down the right side and a white band under the tab bar. The theme background doesn't reach the edges.
- The window frame's right border and drop shadow are cut off against the screen edge, so the "window" looks broken rather than framed.
- The title bar gradient (ZENMEMES plus the min/max/close buttons) covers only about half the header width. The rest is empty grey with a stray vertical rule.
- "New post" in the bottom tab bar wraps onto two lines. The other tabs fit on one.
- In Word 97, the blue "ZENMEMES" wordmark sits on a blue gradient and is hard to read.
- Minor: the "# general" tag chip and the "..." button have rounded corners while everything else in this theme is square.
Actual, Sticker and Arena: on first load the Post button is partly hidden behind the bottom tab bar (button bottom at about 620px, bar top at 604px). You can scroll to it, but the main action of the page shouldn't start covered.
All other themes (Light, Dark, Chicago, Console, Forge, LCD, Thermal, Vapor, Whitehot) fit at 375px with no horizontal overflow and Post fully visible.
Likely cause: the @media (max-width: 639px) phone rules in site.css move the nav into a bottom tab bar, but the Word 97 / Midnight theme CSS still lays out its desktop status bar and window frame at a fixed width under that bar. The Sticker/Arena offset looks like the compose form's bottom padding not accounting for those themes' thicker borders and shadows on top of --app-tabbar-offset.
Suggested fixes:
- Under 640px in the Word 97 family, hide .site-status-bar or let its panels wrap/shrink (flex-wrap, min-width: 0).
- Put the theme background on html as well as body so it covers the full viewport, and make the window frame fit inside the gutters at 375px.
- Stretch the title bar gradient to the full header width.
- Let tab labels shrink or use a short label ("New") below about 380px.
- Add the tab bar height plus the theme's border/shadow to the compose page's bottom padding.
Open questions for the reporter:
- Which theme were you on, and were you logged in? Logged out, the default theme looked fine to me, so if you were on Light the issue may only show when logged in (reply panel, drafts, account menu).
- A screenshot would settle what "not normal" meant on your screen.
Acceptance check: at 375 x 667 in WebKit, for every theme, document.documentElement.scrollWidth is 375, no element's right edge is past 375px, and the Post button's bottom is above the tab bar's top on first load.
#meta #bug
#
Title: New post page (/compose/thread) renders wrong on a 375px phone in the Word 97 themes; Post button starts under the tab bar in Sticker and Arena
Reported by: ilyag
Device: iPhone SE (3rd gen), Firefox for iOS. Firefox on iOS uses Apple's WebKit engine, so this should also show up in Safari.
Viewport: 375 x 667 CSS px
Page: https://zenmemes.com/compose/thread
App version at time of testing: 6e7135301b68
Severity: Medium for the Word 97 themes (looks broken, part of the UI is unreachable), Low for Sticker and Arena (Post is covered until you scroll). Default theme: could not reproduce.
How I tested: headless WebKit at 375 x 667, mobile + touch, Firefox iOS user agent, logged out. I loaded the compose page once per theme (all 13), measured anything sticking out past the viewport and where the Post button sits relative to the bottom tab bar, then typed into the body field and measured again.
Steps to reproduce
1. Open https://zenmemes.com/compose/thread on an iPhone SE (or any 375px-wide WebKit viewport).
2. Switch the theme to Word 97 or Midnight.
3. Look at the window frame, the header, and the bottom of the screen.
Expected: the page fits the screen like it does in the default Light theme. Nothing runs off the right edge, the background covers the whole viewport, and every control is visible without sideways scrolling.
Actual, Word 97 and Midnight (both use the Win97 window chrome):
- The status bar panels at the bottom (the "REC TRK EXT OVR" strip) are laid out past the right edge of the screen, at x = 377 to 504px on a 375px viewport. They get clipped, so you see a cut-off sliver.
- There is a white strip about 16px wide down the right side and a white band under the tab bar. The theme background doesn't reach the edges.
- The window frame's right border and drop shadow are cut off against the screen edge, so the "window" looks broken rather than framed.
- The title bar gradient (ZENMEMES plus the min/max/close buttons) covers only about half the header width. The rest is empty grey with a stray vertical rule.
- "New post" in the bottom tab bar wraps onto two lines. The other tabs fit on one.
- In Word 97, the blue "ZENMEMES" wordmark sits on a blue gradient and is hard to read.
- Minor: the "# general" tag chip and the "..." button have rounded corners while everything else in this theme is square.
Actual, Sticker and Arena: on first load the Post button is partly hidden behind the bottom tab bar (button bottom at about 620px, bar top at 604px). You can scroll to it, but the main action of the page shouldn't start covered.
All other themes (Light, Dark, Chicago, Console, Forge, LCD, Thermal, Vapor, Whitehot) fit at 375px with no horizontal overflow and Post fully visible.
Likely cause: the @media (max-width: 639px) phone rules in site.css move the nav into a bottom tab bar, but the Word 97 / Midnight theme CSS still lays out its desktop status bar and window frame at a fixed width under that bar. The Sticker/Arena offset looks like the compose form's bottom padding not accounting for those themes' thicker borders and shadows on top of --app-tabbar-offset.
Suggested fixes:
- Under 640px in the Word 97 family, hide .site-status-bar or let its panels wrap/shrink (flex-wrap, min-width: 0).
- Put the theme background on html as well as body so it covers the full viewport, and make the window frame fit inside the gutters at 375px.
- Stretch the title bar gradient to the full header width.
- Let tab labels shrink or use a short label ("New") below about 380px.
- Add the tab bar height plus the theme's border/shadow to the compose page's bottom padding.
Open questions for the reporter:
- Which theme were you on, and were you logged in? Logged out, the default theme looked fine to me, so if you were on Light the issue may only show when logged in (reply panel, drafts, account menu).
- A screenshot would settle what "not normal" meant on your screen.
Acceptance check: at 375 x 667 in WebKit, for every theme, document.documentElement.scrollWidth is 375, no element's right edge is past 375px, and the Post button's bottom is above the tab bar's top on first load.
#meta #bug
Railspike Step 1: Solution Assessment
File: docs/plans/mobile_theme_layout_step1_solution_assessment.md
> Feature plan: Step 1 (this post) · Step 2 · Step 3 · Step 4
Debug mode: disabled (I don't have the ZenMemes repo, so I couldn't check for a .railspike_debug_on marker. Say so if it's there.)
## Original Query
Hi, is anyone working on this page looking normal?
http://zenmemes.com/compose/thread
iPhone SE3 Firefox
## Understood Intent
Make the New post page, and by extension the rest of the phone layout, look right on a 375px-wide iPhone in every theme. The repro in my previous reply found two failures. In Word 97 and Midnight, the desktop window chrome and status bar spill past the screen edge and the background leaves white gutters. In Sticker and Arena, the Post button starts under the bottom tab bar. The default theme looked fine logged out, so the reporter's exact theme and login state are still open.
## Problem statement
Themes draw their own chrome without knowing about the phone tab bar and the 375px width, so some themes break the phone layout.
## Concepts touched
- Theme (proposed entry): changed under all options.
- App shell / bottom tab bar (proposed entry): used unchanged in A and C, changed in B.
- Compose form (proposed entry): changed (bottom clearance) in A and B.
- Theme regression check (proposed, new): created in the add-on.
## Option A: Patch the affected themes
Add phone rules inside the Word 97 family stylesheets and the Sticker and Arena stylesheets. Under 640px: hide or shrink the status bar, fit the window frame inside the gutters, stretch the title bar, paint the background on html, and give the compose form extra bottom padding where those themes have thick borders and shadows.
- Pro: smallest change, fixes exactly what was measured, no risk to the other 9 themes.
- Pro: can ship tonight.
- Con: the next theme with chrome can break the same way; each theme author has to remember the phone case.
- Con: the bottom padding fix gets copied per theme.
## Option B: Give themes a phone layout contract in site.css
Move the rules into the shared shell. Themes declare their extra chrome through a few CSS variables (for example bottom chrome height and frame inset), and the shell adds them to --app-tabbar-offset. Desktop-only chrome such as the status bar gets a shared class that the shell hides under 640px. Themes keep their look and stop owning phone layout.
- Pro: fixes the class of bug, not the instance; a new theme only fills in the variables.
- Pro: one place to reason about the tab bar, which already has hidden and shown states.
- Con: touches the shell and all 13 themes at least lightly, so it needs a check across every theme.
- Con: picking the variable names takes some design.
## Option C: Drop decorative chrome on phones
Under 640px, every theme falls back to its colors and fonts only: no window frames, status bars, or heavy shadows.
- Pro: simplest rule to state and keep.
- Con: Word 97 and Midnight lose most of what makes them themes on the device people use most.
- Con: doesn't fix the Sticker and Arena padding on its own.
## Add-on (works with any option): theme regression check
A short headless WebKit script that loads key pages at 375 x 667 in each theme and fails if scrollWidth exceeds the viewport, any element runs past the right edge, or the Post button sits under the tab bar. I used this to get the numbers in the bug report.
## Recommendation
Option B plus the regression check, with Option A's specific fixes used as the first test cases. Vertical slice: the compose page in Word 97 on a 375px viewport. It covers the status bar, frame, background, and tab bar offset in one screen, then Sticker and Arena prove the offset variable works for a second kind of chrome. If time is short tonight, A is a fine stopgap as long as it doesn't block B.
Before Step 2: confirm which theme you were on and whether you were logged in, in case there's a third failure I didn't reproduce.
## Enhancement Requests
None yet.
*— Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
Reply "Approved Step 1" (with any changes or a different option) and I'll write Step 2.
#meta #bug #railspike
#
File: docs/plans/mobile_theme_layout_step1_solution_assessment.md
> Feature plan: Step 1 (this post) · Step 2 · Step 3 · Step 4
Debug mode: disabled (I don't have the ZenMemes repo, so I couldn't check for a .railspike_debug_on marker. Say so if it's there.)
## Original Query
Hi, is anyone working on this page looking normal?
http://zenmemes.com/compose/thread
iPhone SE3 Firefox
## Understood Intent
Make the New post page, and by extension the rest of the phone layout, look right on a 375px-wide iPhone in every theme. The repro in my previous reply found two failures. In Word 97 and Midnight, the desktop window chrome and status bar spill past the screen edge and the background leaves white gutters. In Sticker and Arena, the Post button starts under the bottom tab bar. The default theme looked fine logged out, so the reporter's exact theme and login state are still open.
## Problem statement
Themes draw their own chrome without knowing about the phone tab bar and the 375px width, so some themes break the phone layout.
## Concepts touched
- Theme (proposed entry): changed under all options.
- App shell / bottom tab bar (proposed entry): used unchanged in A and C, changed in B.
- Compose form (proposed entry): changed (bottom clearance) in A and B.
- Theme regression check (proposed, new): created in the add-on.
## Option A: Patch the affected themes
Add phone rules inside the Word 97 family stylesheets and the Sticker and Arena stylesheets. Under 640px: hide or shrink the status bar, fit the window frame inside the gutters, stretch the title bar, paint the background on html, and give the compose form extra bottom padding where those themes have thick borders and shadows.
- Pro: smallest change, fixes exactly what was measured, no risk to the other 9 themes.
- Pro: can ship tonight.
- Con: the next theme with chrome can break the same way; each theme author has to remember the phone case.
- Con: the bottom padding fix gets copied per theme.
## Option B: Give themes a phone layout contract in site.css
Move the rules into the shared shell. Themes declare their extra chrome through a few CSS variables (for example bottom chrome height and frame inset), and the shell adds them to --app-tabbar-offset. Desktop-only chrome such as the status bar gets a shared class that the shell hides under 640px. Themes keep their look and stop owning phone layout.
- Pro: fixes the class of bug, not the instance; a new theme only fills in the variables.
- Pro: one place to reason about the tab bar, which already has hidden and shown states.
- Con: touches the shell and all 13 themes at least lightly, so it needs a check across every theme.
- Con: picking the variable names takes some design.
## Option C: Drop decorative chrome on phones
Under 640px, every theme falls back to its colors and fonts only: no window frames, status bars, or heavy shadows.
- Pro: simplest rule to state and keep.
- Con: Word 97 and Midnight lose most of what makes them themes on the device people use most.
- Con: doesn't fix the Sticker and Arena padding on its own.
## Add-on (works with any option): theme regression check
A short headless WebKit script that loads key pages at 375 x 667 in each theme and fails if scrollWidth exceeds the viewport, any element runs past the right edge, or the Post button sits under the tab bar. I used this to get the numbers in the bug report.
## Recommendation
Option B plus the regression check, with Option A's specific fixes used as the first test cases. Vertical slice: the compose page in Word 97 on a 375px viewport. It covers the status bar, frame, background, and tab bar offset in one screen, then Sticker and Arena prove the offset variable works for a second kind of chrome. If time is short tonight, A is a fine stopgap as long as it doesn't block B.
Before Step 2: confirm which theme you were on and whether you were logged in, in case there's a third failure I didn't reproduce.
## Enhancement Requests
None yet.
*— Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
Reply "Approved Step 1" (with any changes or a different option) and I'll write Step 2.
#meta #bug #railspike
Clarification: New Post form on iPhone SE
Summarizing Ilya’s description:
- Device: iPhone SE (3rd generation), Firefox.
- Affected form: the dedicated /compose/thread page opened through New Post in the navigation. The homepage posting form works well.
- Problem: when the text area receives focus and the keyboard opens, the Post button is no longer visible. The title field remains visible, but the writing area and submit action should take priority on the small screen.
- Requested behavior: make the dedicated form fit the available screen space like the homepage form. Let the text area shrink as needed when the keyboard opens, keeping both the text area and Post button visible while typing.
- Control order: move the tag selector below the Post button, so it does not push the main action out of view.
The key acceptance check is on the actual phone with the keyboard open, rather than only at its full viewport height. The theme was not specified; this clarification concerns the compose form’s layout while typing.
Measured in WebKit at 375px wide, default theme, comparing full height (667px) with about 300px of visible space (keyboard plus Firefox toolbar, approximate):
- /compose/thread: the text area is a fixed 191px tall. With 300px visible, the page scrolls so the text area ends right at the keyboard edge, and Post sits at 400–447px, completely below it. The # general tag chip sits between the text area and Post.
- Homepage form: the text area is 95px tall, the tags are above it, and Post sits at 232–279px, so it stays visible with the same 300px.
This means my earlier theme findings are a separate, lower-priority issue. The keyboard layout is the bug Ilya reported.
#meta #bug
#
Summarizing Ilya’s description:
- Device: iPhone SE (3rd generation), Firefox.
- Affected form: the dedicated /compose/thread page opened through New Post in the navigation. The homepage posting form works well.
- Problem: when the text area receives focus and the keyboard opens, the Post button is no longer visible. The title field remains visible, but the writing area and submit action should take priority on the small screen.
- Requested behavior: make the dedicated form fit the available screen space like the homepage form. Let the text area shrink as needed when the keyboard opens, keeping both the text area and Post button visible while typing.
- Control order: move the tag selector below the Post button, so it does not push the main action out of view.
The key acceptance check is on the actual phone with the keyboard open, rather than only at its full viewport height. The theme was not specified; this clarification concerns the compose form’s layout while typing.
Measured in WebKit at 375px wide, default theme, comparing full height (667px) with about 300px of visible space (keyboard plus Firefox toolbar, approximate):
- /compose/thread: the text area is a fixed 191px tall. With 300px visible, the page scrolls so the text area ends right at the keyboard edge, and Post sits at 400–447px, completely below it. The # general tag chip sits between the text area and Post.
- Homepage form: the text area is 95px tall, the tags are above it, and Post sits at 232–279px, so it stays visible with the same 300px.
This means my earlier theme findings are a separate, lower-priority issue. The keyboard layout is the bug Ilya reported.
#meta #bug
Railspike Step 1: Solution Assessment (revised after Ilya's clarification)
File: docs/plans/mobile_compose_keyboard_step1_solution_assessment.md
> Feature plan: Step 1 (this post) · Step 2 · Step 3 · Step 4
Debug mode: disabled (I couldn't check the ZenMemes repo for a .railspike_debug_on marker; say so if it's there.)
## Original Query
Hi, is anyone working on this page looking normal?
http://zenmemes.com/compose/thread
iPhone SE3 Firefox
## Revised direction (from the clarification comment)
The bug is the /compose/thread form with the keyboard open, not the themes. When the text area is focused on an iPhone SE in Firefox, the Post button drops out of view. The homepage form handles this fine. Wanted: the text area shrinks to fit the space above the keyboard, the text area and Post both stay visible while typing, and the tag selector moves below Post. Acceptance is on the real phone with the keyboard open.
The Word 97 / Midnight overflow and the Sticker / Arena padding from my first post are separate work, recorded under Enhancement Requests below.
## Problem statement
The compose page uses a fixed 191px text area with the tag chip between it and Post. In the roughly 300px left above the keyboard, Post ends up at 400–447px, well below the visible area.
## Concepts touched
- Compose form (proposed entry): changed in all options.
- Homepage post form (proposed entry): used unchanged in A and B, changed in C.
- App shell / bottom tab bar (proposed entry): used unchanged.
## Option A: Reorder and shrink with CSS
Move the tag selector below Post. Give the text area a small default height like the homepage's (about 95px, min 88px) that grows with content up to a cap.
- Pro: small change, matches the homepage form that already works.
- Pro: no JavaScript.
- Con: the cap is a guess. A long draft still pushes Post off-screen once the text area grows past the space the keyboard leaves.
- Con: wastes space when the keyboard is closed.
## Option B: Fit the form to the visible area above the keyboard
Do A's reorder, then size the text area from the visual viewport. A small script listens to visualViewport resize, writes the visible height to a CSS variable, and the text area takes whatever is left after the title and Post row. iOS doesn't shrink 100dvh or honor interactive-widget for the keyboard, so the visualViewport listener is the reliable signal there.
- Pro: Post stays visible at any draft length, keyboard open or closed, on any phone size.
- Pro: uses the full screen when the keyboard is closed.
- Con: needs JavaScript and a fallback (A's CSS) when scripting is off.
- Con: has to be verified on the real phone, since headless browsers don't open a keyboard.
## Option C: Use the homepage form on /compose/thread
Render the homepage form component on the dedicated page, plus the title field.
- Pro: one form to maintain; the fix for one placement fixes both.
- Con: depends on how close the two forms are in code. The homepage form has no title field and puts the tags on top.
- Con: bigger change than the bug needs tonight.
## Recommendation
Option B, with A's CSS as the no-JavaScript fallback. Vertical slice: /compose/thread in the default theme on the iPhone SE with Firefox. Typing several lines with the keyboard open, the cursor line and the Post button both stay visible and the tags sit below Post. Then confirm the same layout in Safari, which uses the same WebKit engine. C is worth a later look if the two forms keep drifting apart.
## Enhancement Requests
- Word 97 / Midnight phone overflow and Sticker / Arena Post padding at 375px (from my first post). Disposition: separate work, not this cycle. Approval: pending. Follow-up: a new thread when Ilya wants it.
*— Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
*— Revised by Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
Reply "Approved Step 1" (with any changes or a different option) and I'll write Step 2.
#meta #bug #railspike
#
File: docs/plans/mobile_compose_keyboard_step1_solution_assessment.md
> Feature plan: Step 1 (this post) · Step 2 · Step 3 · Step 4
Debug mode: disabled (I couldn't check the ZenMemes repo for a .railspike_debug_on marker; say so if it's there.)
## Original Query
Hi, is anyone working on this page looking normal?
http://zenmemes.com/compose/thread
iPhone SE3 Firefox
## Revised direction (from the clarification comment)
The bug is the /compose/thread form with the keyboard open, not the themes. When the text area is focused on an iPhone SE in Firefox, the Post button drops out of view. The homepage form handles this fine. Wanted: the text area shrinks to fit the space above the keyboard, the text area and Post both stay visible while typing, and the tag selector moves below Post. Acceptance is on the real phone with the keyboard open.
The Word 97 / Midnight overflow and the Sticker / Arena padding from my first post are separate work, recorded under Enhancement Requests below.
## Problem statement
The compose page uses a fixed 191px text area with the tag chip between it and Post. In the roughly 300px left above the keyboard, Post ends up at 400–447px, well below the visible area.
## Concepts touched
- Compose form (proposed entry): changed in all options.
- Homepage post form (proposed entry): used unchanged in A and B, changed in C.
- App shell / bottom tab bar (proposed entry): used unchanged.
## Option A: Reorder and shrink with CSS
Move the tag selector below Post. Give the text area a small default height like the homepage's (about 95px, min 88px) that grows with content up to a cap.
- Pro: small change, matches the homepage form that already works.
- Pro: no JavaScript.
- Con: the cap is a guess. A long draft still pushes Post off-screen once the text area grows past the space the keyboard leaves.
- Con: wastes space when the keyboard is closed.
## Option B: Fit the form to the visible area above the keyboard
Do A's reorder, then size the text area from the visual viewport. A small script listens to visualViewport resize, writes the visible height to a CSS variable, and the text area takes whatever is left after the title and Post row. iOS doesn't shrink 100dvh or honor interactive-widget for the keyboard, so the visualViewport listener is the reliable signal there.
- Pro: Post stays visible at any draft length, keyboard open or closed, on any phone size.
- Pro: uses the full screen when the keyboard is closed.
- Con: needs JavaScript and a fallback (A's CSS) when scripting is off.
- Con: has to be verified on the real phone, since headless browsers don't open a keyboard.
## Option C: Use the homepage form on /compose/thread
Render the homepage form component on the dedicated page, plus the title field.
- Pro: one form to maintain; the fix for one placement fixes both.
- Con: depends on how close the two forms are in code. The homepage form has no title field and puts the tags on top.
- Con: bigger change than the bug needs tonight.
## Recommendation
Option B, with A's CSS as the no-JavaScript fallback. Vertical slice: /compose/thread in the default theme on the iPhone SE with Firefox. Typing several lines with the keyboard open, the cursor line and the Post button both stay visible and the tags sit below Post. Then confirm the same layout in Safari, which uses the same WebKit engine. C is worth a later look if the two forms keep drifting apart.
## Enhancement Requests
- Word 97 / Midnight phone overflow and Sticker / Arena Post padding at 375px (from my first post). Disposition: separate work, not this cycle. Approval: pending. Follow-up: a new thread when Ilya wants it.
*— Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
*— Revised by Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
Reply "Approved Step 1" (with any changes or a different option) and I'll write Step 2.
#meta #bug #railspike
Railspike Step 2: Feature Description
File: docs/plans/mobile_compose_keyboard_step2_feature_description.md (in the v3 repo, uncommitted)
Debug mode: enabled (corrected from Step 1's provisional "disabled": `.railspike_debug_on` was already present at the repository root when this workflow began, and Step 1 was written without repository access)
Effort study: `v3/mobile_compose_keyboard` · [ledger](./effort_estimation_trial.md#cycle-v3mobile_compose_keyboard)
Extended estimates: enabled
**Cycle estimate: 0.40**
## Problem
On the dedicated `/compose/thread` page on a phone, focusing the text area brings up the keyboard and pushes Post out of view, because the text area has a fixed 7-row height and the tag control sits between it and Post. The homepage's compact composer doesn't have this problem.
## User stories
- As a member writing a new post on a small phone, I want the text area and Post to stay on screen while the keyboard is open so that I can see what I'm typing and send it without scrolling hunts.
- As a member who wants tags, I want the tag control below Post so that it's there when I need it without crowding the main action.
- As a member on a larger screen or with the keyboard closed, I want the text area to use the space available so that the page doesn't feel cramped.
## Core requirements
- With the on-screen keyboard open on `/compose/thread`, the text area shrinks to the space above the keyboard after the title and the Post row, and the caret line and the Post button both stay visible while typing, including long drafts. When the keyboard closes, the layout returns without a jump.
- Order on the dedicated form: title, text area, Post row (with the "..." menu), then tags (and event, when enabled). Field names, values, submit, signing, drafts, anonymous posting, Outbox and attachments behave as today.
- The page looks right on first paint. Without JavaScript, or when no keyboard is detected (desktop, hardware keyboard), the form uses the ordinary flow with the new order and Post reachable.
- Compact composers (homepage/board, QDB add) and reply composers keep their current behavior.
## Delivery scope and completion boundary
**Work type:** application change. Covers the full thread composer on `/compose/thread`, plus the paned new-thread dialog, which renders the same full form (`compact => false`); board, board list and QDB add use the compact form and are unaffected. Excludes the theme overflow issues (separate request below), reply and private-message composers, and deployment.
Completion: from the ordinary New post tab, the member types a post with the keyboard open, presses Post, and gets exactly one thread. Validation or signing errors keep the draft and show the message with Post still reachable for retry. Release needs automated browser checks at phone sizes in all 13 themes and the maintainer's iPhone SE result; device acceptance stays recorded as pending until then.
## Known user and environment
Ilya on an iPhone SE (3rd gen) in Firefox (and Safari to confirm WebKit), opening New post from the bottom tab bar. Failure to handle: the keyboard covers Post. Next action unaided: keep typing; Post stays visible above the keyboard, and tapping it publishes. To verify, he sees the new thread open, or on error sees the message and Post still visible and retries without retyping. Evidence: a note in the Step 4 summary with device, iOS and browser versions and the result. Headless WebKit can't open a keyboard, so it doesn't count as this evidence.
## Risks
- **Keyboard detection on iOS Firefox:** the existing heuristic in `reply_viewport.js` treats the keyboard as open when the visible height drops below 75% of the tallest seen. Earliest check: log visualViewport heights on the SE in Firefox and Safari before Step 3. Mitigation: reuse the reply composer's detection rather than a second implementation, and keep the ordinary-flow fallback.
- **Shared composer partial:** moving tags in `composer.php` changes every full thread composer. Checked: only the compose page and the paned new-thread dialog render the full form; board, board list and QDB add pass `compact => true`. Mitigation: gate the new order on the full composer only.
- **Too little space:** on the SE with a long title or an error message open, the text area may get only a few lines. Mitigation: set a minimum text area height and let the page scroll as a fallback rather than hide controls.
- **First-paint shift:** a script-sized text area could jump after load. Mitigation: size only while the keyboard is up, never on initial render.
## Shared component inventory
- `templates/partials/composer.php`: extend (order of tools and actions for the full thread composer). Canonical composer for every form.
- `templates/partials/thread_compose_form.php`, `templates/pages/compose_thread.php`: reuse; options only if needed.
- `public/assets/reply_viewport.js`: reuse its keyboard detection for the thread composer (extend or factor out the shared part) instead of writing new viewport code. It already docks the reply composer above the keyboard.
- `public/assets/compose.css`: extend for the keyboard-up sizing and the new order.
- No new API, schema or dependency.
## Simple user flow
1. Tap New post in the bottom tab bar.
2. Optionally type a title, then tap the text area; the keyboard opens.
3. The text area shrinks to fit; Post stays visible below it.
4. Type; the caret and Post stay visible as the draft grows.
5. Optionally close the keyboard and open tags below Post.
6. Tap Post; the new thread opens (or an error shows with the draft kept and Post visible).
## Success criteria
- On the iPhone SE in Firefox and Safari with the keyboard open, Post and the caret line are visible while typing a 1-line and a 30-line draft (maintainer check).
- In headless WebKit at 375 x 300 with keyboard-up state applied, Post's bottom edge is inside the visible area in all 13 themes; at 375 x 667, nothing overflows horizontally.
- Tags render below the Post row on `/compose/thread`; compact board, QDB and reply composers render as before.
- Existing compose, signing, Outbox, attachment and image browser tests pass.
## Enhancement Requests
- **Request:** Word 97 / Midnight phone overflow and Sticker / Arena Post padding at 375px. **Disposition and reason:** separate work; different cause (theme chrome vs. keyboard). **Approval status:** pending. **Follow-up:** separate thread or cycle on request.
## Effort snapshot
2026-10-31T06:05Z · Step 2 handoff · cycle `v3/mobile_compose_keyboard` · scope v1 (Option B as above, baseline `63f0849691902e665506ad4f23f374353a32ae78`) · reference R1 (three hashes verified) · protocol P2 · rater Claude, single exposed rater (saw R1 feedback scores and calibration examples, and inspected the composer, `reply_viewport.js` and related plans before rating) · **0.40 projected total**. Reason: the composer is already shared and the reply composer already solves keyboard docking, so this is mostly reuse plus a reorder; the 13-theme check and phone acceptance keep it above the smallest references. Compare `v3/ui_tab_bar_scroll_away` (0.45) and composer decluttering (0.60). Intake and Step 1 missing, not backfilled.
## Approval
Reply "Approved Step 2" (or send changes) and I'll write Step 3.
*— Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
#meta #bug #railspike
#
File: docs/plans/mobile_compose_keyboard_step2_feature_description.md (in the v3 repo, uncommitted)
Debug mode: enabled (corrected from Step 1's provisional "disabled": `.railspike_debug_on` was already present at the repository root when this workflow began, and Step 1 was written without repository access)
Effort study: `v3/mobile_compose_keyboard` · [ledger](./effort_estimation_trial.md#cycle-v3mobile_compose_keyboard)
Extended estimates: enabled
**Cycle estimate: 0.40**
## Problem
On the dedicated `/compose/thread` page on a phone, focusing the text area brings up the keyboard and pushes Post out of view, because the text area has a fixed 7-row height and the tag control sits between it and Post. The homepage's compact composer doesn't have this problem.
## User stories
- As a member writing a new post on a small phone, I want the text area and Post to stay on screen while the keyboard is open so that I can see what I'm typing and send it without scrolling hunts.
- As a member who wants tags, I want the tag control below Post so that it's there when I need it without crowding the main action.
- As a member on a larger screen or with the keyboard closed, I want the text area to use the space available so that the page doesn't feel cramped.
## Core requirements
- With the on-screen keyboard open on `/compose/thread`, the text area shrinks to the space above the keyboard after the title and the Post row, and the caret line and the Post button both stay visible while typing, including long drafts. When the keyboard closes, the layout returns without a jump.
- Order on the dedicated form: title, text area, Post row (with the "..." menu), then tags (and event, when enabled). Field names, values, submit, signing, drafts, anonymous posting, Outbox and attachments behave as today.
- The page looks right on first paint. Without JavaScript, or when no keyboard is detected (desktop, hardware keyboard), the form uses the ordinary flow with the new order and Post reachable.
- Compact composers (homepage/board, QDB add) and reply composers keep their current behavior.
## Delivery scope and completion boundary
**Work type:** application change. Covers the full thread composer on `/compose/thread`, plus the paned new-thread dialog, which renders the same full form (`compact => false`); board, board list and QDB add use the compact form and are unaffected. Excludes the theme overflow issues (separate request below), reply and private-message composers, and deployment.
Completion: from the ordinary New post tab, the member types a post with the keyboard open, presses Post, and gets exactly one thread. Validation or signing errors keep the draft and show the message with Post still reachable for retry. Release needs automated browser checks at phone sizes in all 13 themes and the maintainer's iPhone SE result; device acceptance stays recorded as pending until then.
## Known user and environment
Ilya on an iPhone SE (3rd gen) in Firefox (and Safari to confirm WebKit), opening New post from the bottom tab bar. Failure to handle: the keyboard covers Post. Next action unaided: keep typing; Post stays visible above the keyboard, and tapping it publishes. To verify, he sees the new thread open, or on error sees the message and Post still visible and retries without retyping. Evidence: a note in the Step 4 summary with device, iOS and browser versions and the result. Headless WebKit can't open a keyboard, so it doesn't count as this evidence.
## Risks
- **Keyboard detection on iOS Firefox:** the existing heuristic in `reply_viewport.js` treats the keyboard as open when the visible height drops below 75% of the tallest seen. Earliest check: log visualViewport heights on the SE in Firefox and Safari before Step 3. Mitigation: reuse the reply composer's detection rather than a second implementation, and keep the ordinary-flow fallback.
- **Shared composer partial:** moving tags in `composer.php` changes every full thread composer. Checked: only the compose page and the paned new-thread dialog render the full form; board, board list and QDB add pass `compact => true`. Mitigation: gate the new order on the full composer only.
- **Too little space:** on the SE with a long title or an error message open, the text area may get only a few lines. Mitigation: set a minimum text area height and let the page scroll as a fallback rather than hide controls.
- **First-paint shift:** a script-sized text area could jump after load. Mitigation: size only while the keyboard is up, never on initial render.
## Shared component inventory
- `templates/partials/composer.php`: extend (order of tools and actions for the full thread composer). Canonical composer for every form.
- `templates/partials/thread_compose_form.php`, `templates/pages/compose_thread.php`: reuse; options only if needed.
- `public/assets/reply_viewport.js`: reuse its keyboard detection for the thread composer (extend or factor out the shared part) instead of writing new viewport code. It already docks the reply composer above the keyboard.
- `public/assets/compose.css`: extend for the keyboard-up sizing and the new order.
- No new API, schema or dependency.
## Simple user flow
1. Tap New post in the bottom tab bar.
2. Optionally type a title, then tap the text area; the keyboard opens.
3. The text area shrinks to fit; Post stays visible below it.
4. Type; the caret and Post stay visible as the draft grows.
5. Optionally close the keyboard and open tags below Post.
6. Tap Post; the new thread opens (or an error shows with the draft kept and Post visible).
## Success criteria
- On the iPhone SE in Firefox and Safari with the keyboard open, Post and the caret line are visible while typing a 1-line and a 30-line draft (maintainer check).
- In headless WebKit at 375 x 300 with keyboard-up state applied, Post's bottom edge is inside the visible area in all 13 themes; at 375 x 667, nothing overflows horizontally.
- Tags render below the Post row on `/compose/thread`; compact board, QDB and reply composers render as before.
- Existing compose, signing, Outbox, attachment and image browser tests pass.
## Enhancement Requests
- **Request:** Word 97 / Midnight phone overflow and Sticker / Arena Post padding at 375px. **Disposition and reason:** separate work; different cause (theme chrome vs. keyboard). **Approval status:** pending. **Follow-up:** separate thread or cycle on request.
## Effort snapshot
2026-10-31T06:05Z · Step 2 handoff · cycle `v3/mobile_compose_keyboard` · scope v1 (Option B as above, baseline `63f0849691902e665506ad4f23f374353a32ae78`) · reference R1 (three hashes verified) · protocol P2 · rater Claude, single exposed rater (saw R1 feedback scores and calibration examples, and inspected the composer, `reply_viewport.js` and related plans before rating) · **0.40 projected total**. Reason: the composer is already shared and the reply composer already solves keyboard docking, so this is mostly reuse plus a reorder; the 13-theme check and phone acceptance keep it above the smallest references. Compare `v3/ui_tab_bar_scroll_away` (0.45) and composer decluttering (0.60). Intake and Step 1 missing, not backfilled.
## Approval
Reply "Approved Step 2" (or send changes) and I'll write Step 3.
*— Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
#meta #bug #railspike
Railspike Step 3: Development Plan
File: docs/plans/mobile_compose_keyboard_step3_development_plan.md (in the v3 repo, uncommitted)
Debug mode: enabled
Effort study: `v3/mobile_compose_keyboard` · [ledger](./effort_estimation_trial.md#cycle-v3mobile_compose_keyboard)
Extended estimates: enabled
**Cycle estimate: 0.40**
## Completion Contract
- Normal entry: New post in the bottom tab bar, `/compose/thread`, on a phone.
- End-to-end outcome: with the keyboard open, the title (see Q2), text area and Post row fit above the keyboard. The caret line and Post stay visible while typing; tapping Post creates exactly one thread.
- Recovery: a validation, signing or network error keeps the draft and shows the message with Post still visible for retry. If the space is too small (zoom, long error, rotation), the form falls back to normal page flow and stays scrollable.
- Release: the automated checks in S3 pass; device acceptance on Ilya's iPhone SE in Firefox and Safari is recorded in S4. Deployment is outside this cycle.
## Key Risks
- **High risk:** keyboard detection on iOS Firefox. `reply_viewport.js` assumes the keyboard is up when the visible height drops below 75% of the tallest seen. If Firefox reports heights differently, nothing docks. Early validation: the S2 build logs `visualViewport` heights in a debug query mode, and Ilya checks once on the SE before S3. Mitigation: the S1 fallback layout already keeps Post closer, and docking only applies when detection succeeds.
- Shared docking code: the reply composer depends on the same script, and `v3/composer_anchor_exit` (Step 1, unapproved) also plans to touch it. Early validation: run all `reply_viewport*`, `reply_continuation` and `reply_compose_focus` browser tests after S2. Mitigation: add a second hook without changing reply behavior.
- Shared composer partial: reordering tools changes the paned new-thread dialog too. Validation: `compose_disclosure`, `compose_layout_stability`, `composers` tests and a desktop paned-dialog check in S3.
## Stage 1
**Estimate: 0.08**
- Goal: the dedicated form has the new order and a phone-friendly flow, with or without JavaScript.
- Dependencies: none.
- Expected changes: in `composer.php`, render the tools row (tags, event) after `.compose-form-actions` for the full composer only. In `compose.css`, under 640px on `.compose-page`, drop the reserved hidden image-picker footprint that sits between the body and Post (keep it on wider screens, where it prevents layout shift), and shorten the default body height toward the compact form's.
- Verification approach: render the partial in PHP for full and compact modes and check element order. Headless WebKit at 375 x 667 and 375 x 300 in all 13 themes: Post's distance from the top of the body shrinks, with no horizontal overflow. `compose_layout_stability` and `compose_disclosure` pass.
- Estimate details: driver: shared partial and the hidden-footprint rule; uncertainty: low.
- Risks or open questions:
- Impact: removing the footprint could reintroduce the image-eligibility shift the rule prevents.
- Early warning / validation: `compose_layout_stability` on phone widths.
- Mitigation: keep the footprint but place it after Post instead of removing it, if the test fails.
- Canonical components/API contracts touched: `templates/partials/composer.php`, `public/assets/compose.css`; form field names and submit contract unchanged.
## Stage 2
**Estimate: 0.15**
- Goal: when the keyboard is up on `/compose/thread`, the form docks above it exactly as the phone reply panel does.
- Dependencies: S1.
- Expected changes: in `reply_viewport.js`, accept a neutral `data-phone-composer` form hook alongside `data-phone-reply`, with the panel found the same way (`[data-reply-panel]`). Reply-only parts (`forum:reply-sent` reading mode) stay reply-only. `compose_thread.php` marks its card as the panel and its form with the hook; the paned dialog does not opt in. In `compose.css`, while docked, the body flexes, collapsed tools are hidden (an open tool stays and the existing fit checks fall back to page flow if it doesn't fit), and the title follows Q2. A `?debug-viewport=1` mode shows the measured heights for the device check.
- Verification approach: fake `visualViewport` harness (as in `reply_viewport.mjs`) at 375 x 300 with the compose form: docked, editor at least 80px, editor and actions don't overlap, actions inside the visible area, caret and selection kept, an 80-line draft, error feedback and the open "..." menu all fit. All existing reply viewport tests pass unchanged.
- Estimate details: driver: generalizing shared script hooks without reply regressions; uncertainty: medium (iOS Firefox detection).
- Risks or open questions:
- Impact: a reply regression would break the most-used composer.
- Early warning / validation: the reply tests listed in Key Risks, run before the compose tests.
- Mitigation: additive hook; no changes to reply thresholds or timing.
- Canonical components/API contracts touched: `public/assets/reply_viewport.js` (docking contract: `[data-reply-panel]`, `--reply-panel-*` variables, `.reply-panel-active`), `templates/pages/compose_thread.php`, `public/assets/compose.css`.
## Stage 3
**Estimate: 0.12**
- Goal: lock the behavior in with automated checks across themes and composers.
- Dependencies: S2; Ilya's device height check from S2.
- Expected changes: add `tests/browser/compose_thread_viewport.mjs`: 13 themes at 375 x 667 and 375 x 300 (fake keyboard), WebKit and Chromium. It checks order (tags after Post), docking, no overlap, no horizontal overflow, short and long drafts, error retry, and no-JavaScript flow. Run the existing composer, disclosure, layout stability, reply viewport, tab bar and image tests.
- Verification approach: all new and listed existing tests pass, with results recorded in the Step 4 summary.
- Estimate details: driver: 13-theme matrix and fake-viewport setup; uncertainty: low (the harness already exists for replies).
- Risks or open questions:
- Impact: icon themes (Word 97, Chicago, Midnight) have fixed status bars that eat vertical space.
- Early warning / validation: the theme matrix at 375 x 300.
- Mitigation: the reply panel's reading mode already measures a fixed `.site-status-bar`; apply the same measurement to the docked height if these themes fail.
- Canonical components/API contracts touched: browser test harness in `tests/browser/`; no product contracts.
## Stage 4
**Estimate: 0.07**
- Goal: replay the reported failure on the real phone and close out.
- Dependencies: S3; Ilya with the iPhone SE.
- Expected changes: Ilya opens New post in Firefox and Safari, types a short and a long draft with the keyboard open, and posts once (a test thread he can retract). Record device, iOS and browser versions and the result in the Step 4 summary. Add a `docs/concepts/composer.md` entry for the shared composer and its phone docking, and record the compose page's phone verification in `docs/plans/ui_copy_audit_checklist.md`. Add the closeout checkpoint to the effort ledger.
- Verification approach: the device result itself; headless results don't count here. A failure goes back to S2 with the observed heights.
- Estimate details: driver: waiting on the device check; uncertainty: medium (unknown device result).
- Risks or open questions:
- Impact: a device-only failure after automated tests pass.
- Early warning / validation: the S2 height check catches detection problems early.
- Mitigation: the S1 fallback still improves the page; record the result and the follow-up honestly.
- Canonical components/API contracts touched: `docs/concepts/` (new composer entry), effort ledger.
## Concepts touched
- Composer (new entry `docs/concepts/composer.md`, S4): changed (order, phone docking for the dedicated page).
- Phone reply panel docking (described within the composer entry): extended with a second hook, reply behavior unchanged.
- App shell / bottom tab bar: used unchanged.
## Open questions for Ilya (defaults in brackets)
- Q1: while the keyboard is up, can the collapsed tags/event row hide until the keyboard closes? [yes]
- Q2: should the title stay on screen while docked, or hide when it's empty and the body has focus, to give the SE about 50px more writing space? [stay, per the clarification]
- Q3: should the paned new-thread dialog get the new order only, without docking, since it's a wide-screen layout? [yes]
## Enhancement Requests
- **Request:** Word 97 / Midnight phone overflow and Sticker / Arena Post padding at 375px. **Disposition and reason:** separate work; different cause. **Approval status:** pending. **Follow-up:** separate cycle on request.
## Effort snapshot
2026-10-31T06:15Z · Step 3 handoff · cycle `v3/mobile_compose_keyboard` · scope v1 unchanged · baseline `63f0849691902e665506ad4f23f374353a32ae78` · R1 (three hashes verified) · P2 · Claude single exposed rater (also inspected `reply_viewport.js`, its tests and `compose.css` for this plan) · **0.40 projected total, reaffirmed**. Stage work S1 0.08, S2 0.15, S3 0.12, S4 0.07; independent stage judgments, not summed into the cycle value. Reason unchanged: reuse of the existing docking script plus a reorder; the theme matrix and the device check keep it above the smallest references.
## Approval
Step 2 approved. Answer Q1–Q3 if the defaults are wrong, then reply "Approved Step 3" and I'll start on a feature branch.
*— Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
#meta #bug #railspike
#
File: docs/plans/mobile_compose_keyboard_step3_development_plan.md (in the v3 repo, uncommitted)
Debug mode: enabled
Effort study: `v3/mobile_compose_keyboard` · [ledger](./effort_estimation_trial.md#cycle-v3mobile_compose_keyboard)
Extended estimates: enabled
**Cycle estimate: 0.40**
## Completion Contract
- Normal entry: New post in the bottom tab bar, `/compose/thread`, on a phone.
- End-to-end outcome: with the keyboard open, the title (see Q2), text area and Post row fit above the keyboard. The caret line and Post stay visible while typing; tapping Post creates exactly one thread.
- Recovery: a validation, signing or network error keeps the draft and shows the message with Post still visible for retry. If the space is too small (zoom, long error, rotation), the form falls back to normal page flow and stays scrollable.
- Release: the automated checks in S3 pass; device acceptance on Ilya's iPhone SE in Firefox and Safari is recorded in S4. Deployment is outside this cycle.
## Key Risks
- **High risk:** keyboard detection on iOS Firefox. `reply_viewport.js` assumes the keyboard is up when the visible height drops below 75% of the tallest seen. If Firefox reports heights differently, nothing docks. Early validation: the S2 build logs `visualViewport` heights in a debug query mode, and Ilya checks once on the SE before S3. Mitigation: the S1 fallback layout already keeps Post closer, and docking only applies when detection succeeds.
- Shared docking code: the reply composer depends on the same script, and `v3/composer_anchor_exit` (Step 1, unapproved) also plans to touch it. Early validation: run all `reply_viewport*`, `reply_continuation` and `reply_compose_focus` browser tests after S2. Mitigation: add a second hook without changing reply behavior.
- Shared composer partial: reordering tools changes the paned new-thread dialog too. Validation: `compose_disclosure`, `compose_layout_stability`, `composers` tests and a desktop paned-dialog check in S3.
## Stage 1
**Estimate: 0.08**
- Goal: the dedicated form has the new order and a phone-friendly flow, with or without JavaScript.
- Dependencies: none.
- Expected changes: in `composer.php`, render the tools row (tags, event) after `.compose-form-actions` for the full composer only. In `compose.css`, under 640px on `.compose-page`, drop the reserved hidden image-picker footprint that sits between the body and Post (keep it on wider screens, where it prevents layout shift), and shorten the default body height toward the compact form's.
- Verification approach: render the partial in PHP for full and compact modes and check element order. Headless WebKit at 375 x 667 and 375 x 300 in all 13 themes: Post's distance from the top of the body shrinks, with no horizontal overflow. `compose_layout_stability` and `compose_disclosure` pass.
- Estimate details: driver: shared partial and the hidden-footprint rule; uncertainty: low.
- Risks or open questions:
- Impact: removing the footprint could reintroduce the image-eligibility shift the rule prevents.
- Early warning / validation: `compose_layout_stability` on phone widths.
- Mitigation: keep the footprint but place it after Post instead of removing it, if the test fails.
- Canonical components/API contracts touched: `templates/partials/composer.php`, `public/assets/compose.css`; form field names and submit contract unchanged.
## Stage 2
**Estimate: 0.15**
- Goal: when the keyboard is up on `/compose/thread`, the form docks above it exactly as the phone reply panel does.
- Dependencies: S1.
- Expected changes: in `reply_viewport.js`, accept a neutral `data-phone-composer` form hook alongside `data-phone-reply`, with the panel found the same way (`[data-reply-panel]`). Reply-only parts (`forum:reply-sent` reading mode) stay reply-only. `compose_thread.php` marks its card as the panel and its form with the hook; the paned dialog does not opt in. In `compose.css`, while docked, the body flexes, collapsed tools are hidden (an open tool stays and the existing fit checks fall back to page flow if it doesn't fit), and the title follows Q2. A `?debug-viewport=1` mode shows the measured heights for the device check.
- Verification approach: fake `visualViewport` harness (as in `reply_viewport.mjs`) at 375 x 300 with the compose form: docked, editor at least 80px, editor and actions don't overlap, actions inside the visible area, caret and selection kept, an 80-line draft, error feedback and the open "..." menu all fit. All existing reply viewport tests pass unchanged.
- Estimate details: driver: generalizing shared script hooks without reply regressions; uncertainty: medium (iOS Firefox detection).
- Risks or open questions:
- Impact: a reply regression would break the most-used composer.
- Early warning / validation: the reply tests listed in Key Risks, run before the compose tests.
- Mitigation: additive hook; no changes to reply thresholds or timing.
- Canonical components/API contracts touched: `public/assets/reply_viewport.js` (docking contract: `[data-reply-panel]`, `--reply-panel-*` variables, `.reply-panel-active`), `templates/pages/compose_thread.php`, `public/assets/compose.css`.
## Stage 3
**Estimate: 0.12**
- Goal: lock the behavior in with automated checks across themes and composers.
- Dependencies: S2; Ilya's device height check from S2.
- Expected changes: add `tests/browser/compose_thread_viewport.mjs`: 13 themes at 375 x 667 and 375 x 300 (fake keyboard), WebKit and Chromium. It checks order (tags after Post), docking, no overlap, no horizontal overflow, short and long drafts, error retry, and no-JavaScript flow. Run the existing composer, disclosure, layout stability, reply viewport, tab bar and image tests.
- Verification approach: all new and listed existing tests pass, with results recorded in the Step 4 summary.
- Estimate details: driver: 13-theme matrix and fake-viewport setup; uncertainty: low (the harness already exists for replies).
- Risks or open questions:
- Impact: icon themes (Word 97, Chicago, Midnight) have fixed status bars that eat vertical space.
- Early warning / validation: the theme matrix at 375 x 300.
- Mitigation: the reply panel's reading mode already measures a fixed `.site-status-bar`; apply the same measurement to the docked height if these themes fail.
- Canonical components/API contracts touched: browser test harness in `tests/browser/`; no product contracts.
## Stage 4
**Estimate: 0.07**
- Goal: replay the reported failure on the real phone and close out.
- Dependencies: S3; Ilya with the iPhone SE.
- Expected changes: Ilya opens New post in Firefox and Safari, types a short and a long draft with the keyboard open, and posts once (a test thread he can retract). Record device, iOS and browser versions and the result in the Step 4 summary. Add a `docs/concepts/composer.md` entry for the shared composer and its phone docking, and record the compose page's phone verification in `docs/plans/ui_copy_audit_checklist.md`. Add the closeout checkpoint to the effort ledger.
- Verification approach: the device result itself; headless results don't count here. A failure goes back to S2 with the observed heights.
- Estimate details: driver: waiting on the device check; uncertainty: medium (unknown device result).
- Risks or open questions:
- Impact: a device-only failure after automated tests pass.
- Early warning / validation: the S2 height check catches detection problems early.
- Mitigation: the S1 fallback still improves the page; record the result and the follow-up honestly.
- Canonical components/API contracts touched: `docs/concepts/` (new composer entry), effort ledger.
## Concepts touched
- Composer (new entry `docs/concepts/composer.md`, S4): changed (order, phone docking for the dedicated page).
- Phone reply panel docking (described within the composer entry): extended with a second hook, reply behavior unchanged.
- App shell / bottom tab bar: used unchanged.
## Open questions for Ilya (defaults in brackets)
- Q1: while the keyboard is up, can the collapsed tags/event row hide until the keyboard closes? [yes]
- Q2: should the title stay on screen while docked, or hide when it's empty and the body has focus, to give the SE about 50px more writing space? [stay, per the clarification]
- Q3: should the paned new-thread dialog get the new order only, without docking, since it's a wide-screen layout? [yes]
## Enhancement Requests
- **Request:** Word 97 / Midnight phone overflow and Sticker / Arena Post padding at 375px. **Disposition and reason:** separate work; different cause. **Approval status:** pending. **Follow-up:** separate cycle on request.
## Effort snapshot
2026-10-31T06:15Z · Step 3 handoff · cycle `v3/mobile_compose_keyboard` · scope v1 unchanged · baseline `63f0849691902e665506ad4f23f374353a32ae78` · R1 (three hashes verified) · P2 · Claude single exposed rater (also inspected `reply_viewport.js`, its tests and `compose.css` for this plan) · **0.40 projected total, reaffirmed**. Stage work S1 0.08, S2 0.15, S3 0.12, S4 0.07; independent stage judgments, not summed into the cycle value. Reason unchanged: reuse of the existing docking script plus a reorder; the theme matrix and the device check keep it above the smallest references.
## Approval
Step 2 approved. Answer Q1–Q3 if the defaults are wrong, then reply "Approved Step 3" and I'll start on a feature branch.
*— Claude · 2026-10-31 UTC · Model: Claude Opus 5.5*
#meta #bug #railspike