Skip to content

At phone width the session dock keeps its desktop 26–30px buttons, so a held reply is approved one-handed but everything beside it is not #1149

Closed

Description

@Birfy

Written-by: Dev4

Split out of #647 (PWA first slice), because it is the half this repository can fix and the rest cannot be fixed here.

The defect

On a phone the FlyBot session dock — the row above the composer where a held reply, a group invite, a notice and a room's Close are decided — keeps its desktop sizes. plugins/social/client.js has exactly one @media (max-width:640px) block and it raises only the held-reply card (.fs-hold .fs-btn, 40px, #362). Everything else in the same row stays at the desktop metrics:

  • .fs-btn → height:30px (client.js:153), used by Close on a closed room, Copy link, Join, the invite field's Go;
  • .fs-btn-sm → height:26px (:158), used by Invite by link (:2292), Approve all (:2456), the notice Accept / Decline (:3123-3124), a friend's bot Remove (:3359-3360);
  • .fs-link → no box at all: 12px text (:159), used for Auto-send from now on — the third decision on every approval card, including on the phone.

So the one screen the phone pass (#362) set out to make usable answers its main card at 40px and then asks the same finger to hit 26px buttons for every other decision in the dock. A 26px control is under half the 44pt / 48dp touch target both mobile platforms recommend, and on the same screen the held card is already at 40px — the two disagree with each other.

Reproduction (no browser needed; this is what the CSS says)

grep -n "max-width:640px" plugins/social/client.js          # one block
grep -n "^\.fs-btn{\|^\.fs-btn-sm{" plugins/social/client.js # 30px / 26px, outside the block

The block's own text, before this issue: @media (max-width:640px){.fs-hold .fs-btn{height:40px;…}.fs-hold .fs-hold-decide{…}} — nothing else.

Expected

Every control in the dock is at least 40px tall at ≤640px, matching the held card; the 12px text links get a real hit area; and the dock's bottom padding clears env(safe-area-inset-bottom) so the row above the composer is not under a phone's home indicator. Wider screens stay exactly as they are.

Not this issue

Installability and everything the home-screen app needs from the shell — a manifest of our own (the shipped one says DeepSeek Harness), raster 192/512 icons, a service worker, theme-color — lives in @deepseek-ai/dsh-web-frontend/dist, which this repository does not own and AGENTS.md hard rule 1 forbids patching. #647 keeps that half and the on-device QA.

Acceptance

  • the dock's buttons are 40px at ≤640px, from one media query, with the desktop 30/26px still outside it;
  • a test that fails when the new rules are removed (plugins/social/test/social.test.js, the same shape as core/test/mobile-layout.test.js);
  • docs/subsystems/social.md's phone line says what the dock now does.

Activity

  1. Birfy commented on Oct 25, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Dev4

    Two corrections on this issue, both from Dev3's reading on #647 and both already in the branch (85af6a00):

    • The env(safe-area-inset-bottom) half of the dock rule evaluates to 0 today: dsh-web-frontend's index.html is width=device-width, initial-scale=1 with no viewport-fit=cover. So it is not a fix for the home indicator — it is a rule that waits for a shell that sets one, and no other inset rule is worth adding before that (that half is DSH's, named in [Mobile] Android 客户端支持 #647).
    • The 40px height matches Mobile: PWA first, then native — approvals and reminders on the phone #362 rather than the 44pt/48dp both mobile platforms recommend; raising the two together is a follow-up, not this change.

    The rest of this issue stands: dock buttons 26–30px on a phone, Auto-send a 12px text run with no box.

  2. Birfy commented on Oct 25, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Dev4

    Scope moved: the dock half of this issue is now carried by #1150 (Dev3, Fixes #1147). Its global @media (max-width:640px) block lifts .fs-btn/.fs-btn-sm to 40px, gives .fs-link/.fs-hold-more a 40px hit area, and sizes the inputs — the session dock inherits all of it, so the buttons this issue was opened for are covered there, not in my withdrawn #1152.

    Why not two PRs: the same two rules with two different numbers (my dock-scoped .fs-link was 32px, #1150 global is 40px) would collide on one class. My branch is kept at 95383948 in case #1150 is bounced.

    What remains true from my earlier reading: env(safe-area-inset-bottom) is still 0 on this shell (dsh-web-frontend viewport has no viewport-fit=cover), so no bottom-inset rule is testable here yet — that stays with the install half in #647 as needs-human.

    Closing this one is the right call once #1150 is merged; until then it is the only open statement of the dock defect.

  3. added a commit that references this issue on Oct 25, 2026
    c1f2edc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions