Skip to content

Stop the thread panel wearing the UA dialog's padding - #145

Merged
max-sixty merged 1 commit into
mainfrom
fix/panel-ua-padding
Aug 31, 2026
Merged

Stop the thread panel wearing the UA dialog's padding#145
max-sixty merged 1 commit into
mainfrom
fix/panel-ua-padding

Conversation

@leaf-agent

Copy link
Copy Markdown
Collaborator

Problem

335bf9a made .lf-panel a <dialog>. Its rule resets every other box default the UA puts on one — margin: 0, border: 0, max-width: none, max-height: none — but states padding only on the two sides that carry a safe-area inset, so dialog { padding: 1em } is still standing on the top and the left. At the chrome's font size that is 14px of sheet belonging to nothing inside it.

It shows up twice. The head's own padding: 10px 14px lands inside that strip, so the title sits 28px in and the head's bottom rule stops 14px short of the sheet's left edge instead of running its width. And a finger landing in the strip down the left of a covering sheet — where a thumb holding a phone lands — meets the dialog rather than the thread list, and scrolls nothing. That is the second failure test_coarse_pointer_resize_reach_stays_reachable_without_trapping_scroll reports, which #144 measured and attributed to #121 without a mechanism.

It was invisible until #121 landed, because the reserved gutter hung the whole panel a bar's width off the left of the window and put the list back under the strip by accident.

Solution

State the panel's padding as the shorthand, for the same reason margin and border above it are shorthands: a rule that states one side of a <dialog>'s box leaves the rest of the UA's standing. The safe-area sides mirror .lf-tray-panel, which already does this correctly — that sheet takes the left inset, this one the right, and both take the bottom.

Testing

uv run pytest tests — 724 passed, 6 skipped, on this branch rebased on 0b7f148.

The target test cannot reach the swipe on main alone: the modal panel intercepts an earlier click. With #144 cherry-picked on top of this branch it passes; with #144 alone it does not.

this branch                      1 failed   (wait_for_function on .lf-threads scrollTop)
#144 rebased, without this       1 failed   (same line)
#144 rebased + this              1 passed
The measurement, and how the strip was found

MANY_DECISIONS_PAGE at 320×800 with the panel open and covering, which is the state the test swipes in. swipe(12, 280) asks the sheet to scroll its list.

tree .lf-panel box .lf-threads box elementFromPoint(12, 280)
1ca4f40 (pre-#121) -15 … 305 0 … 305 .lf-threads
main post-#121 0 … 320 15 … 320 DIALOG.lf-panel
this branch 0 … 320 1 … 320 .lf-threads

The 15px is padding-left: 14px plus the rule's own border-left: 1px. Computed padding on .lf-panel before this change is ['14px', '0px', '0px', '14px'] — top and left from the UA, right and bottom from the rule's safe-area declarations, which resolve to 0px with no notch.

Pre-#121 the panel's box hung 15px off the left of the window, so its content box started at the window's edge and the same point was the list. #121 put the panel where it belongs, which is what exposed the strip.

The visual change

Same fixture, viewport and state — corpus.html at 700×900 with the panel open, screenshotting .lf-panel itself.

The head's border-bottom is the clearest tell: before, it starts 14px in from the sheet's left edge and the "Threads" title sits 28px in; after, the rule runs the full width of the sheet and the title sits at the 14px its own rule states. The whole sheet's content moves up 14px and left 14px onto the position its rules already ask for. Nothing else in the panel changes.

Regression sweep

Every nightly file, -n 4, on this branch. The failures are the standing board and each reproduces on clean main:


Automated fix for failed run 33329482656. That run's other 32 failures are all owned: #144 (the covering panel), #137 (the versions menu), #134 (the catalog digest), and #121, #132, #136, #138, #141, #143 since merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants