aboutsummaryrefslogtreecommitdiffstats
path: root/packages/meshbay-hub/src/meshbay_hub/static/style.css
diff options
context:
space:
mode:
authorChristophe Besson <cbesson@gmail.com>2026-08-17 09:28:49 +0200
committerChristophe Besson <cbesson@gmail.com>2026-08-17 09:28:49 +0200
commitaf30a10b83366416c25eaacec0b4df77526d0924 (patch)
tree1395bf4d9000b262cebbf7d66fcb6c9bf22975eb /packages/meshbay-hub/src/meshbay_hub/static/style.css
parent42047dac4041e72e09499e3adf145f1c0f83b284 (diff)
downloadmeshbay-af30a10b83366416c25eaacec0b4df77526d0924.tar.gz
fix(hub): the transfers panel hung off the side of a phone
Reported: on mobile you see only the right-hand edge of the panel, without the content. Measured, before anything was changed: 320 px viewport -> panel at -138..192, 138 px off the left 360 px -> -98..232 412 px -> -46..284 The panel is 330 px wide and anchored to the right edge of its button — but that button is not at the right edge of the screen, since the bell and the user menu come after it. What falls off is the left-hand side, which is where the file names are, so what stayed on screen was a strip of progress bars belonging to nothing. Narrowing it would not have helped: the overflow comes from where the right edge is pinned, not from the width. Below the existing 768 px breakpoint the panel is anchored to the viewport instead, full width on a phone and capped at 420 px on a tablet, where stretching two filenames across 750 px would be silly. Desktop keeps its 330 px against the button. The interesting part is how it was found. The responsive tests read numbers out of the stylesheet and said, in their own docstring, that a layout could not be measured because the suite had no browser. It has one now — Chrome, from the video work — so layout_probe.py renders the real stylesheet at a given width and returns rectangles. `width: 330px` was never the thing worth asserting on. An iframe carries the viewport, because a headless window will not go below about 500 px, and one browser measures every width: launching one per test put three minutes on the suite against twenty-six seconds for all of them. Checked that the new tests fail with the rule removed — three of them do — and that they pass with it back.
Diffstat (limited to 'packages/meshbay-hub/src/meshbay_hub/static/style.css')
-rw-r--r--packages/meshbay-hub/src/meshbay_hub/static/style.css23
1 files changed, 23 insertions, 0 deletions
diff --git a/packages/meshbay-hub/src/meshbay_hub/static/style.css b/packages/meshbay-hub/src/meshbay_hub/static/style.css
index 5987d1c..1ba0ef0 100644
--- a/packages/meshbay-hub/src/meshbay_hub/static/style.css
+++ b/packages/meshbay-hub/src/meshbay_hub/static/style.css
@@ -1522,6 +1522,29 @@ button:disabled { opacity: 0.5; cursor: not-allowed; }
.group-header { margin-bottom: 10px; gap: 8px; }
.group-tabs { margin-bottom: 10px; }
.chat-messages { padding: 12px; }
+
+ /* The transfers panel stops hanging off its button.
+ It is 330 px wide and anchored to the button's right edge, but that button
+ is not at the right edge of the screen — the bell and the user menu come
+ after it. So the panel extended past the left of the viewport: measured at
+ 138 px lost on a 320 px screen, 98 px at 360. What is cut is the left-hand
+ side, which is where the file names are, so what remained was a strip of
+ progress bars belonging to nothing.
+ Anchoring to the viewport instead of to the button is the only thing that
+ helps: capping the width does not, since the overflow comes from where the
+ right edge is pinned. */
+ .transfer-panel {
+ position: fixed;
+ top: 52px;
+ right: 8px;
+ /* Full width on a phone, and no wider than the desktop panel on a tablet,
+ where stretching it across 768 px would be silly. Both edges are pinned
+ to the viewport, so the width follows from the screen rather than from
+ where the button happens to sit. */
+ left: max(8px, calc(100vw - 428px));
+ width: auto;
+ max-height: calc(100vh - 68px);
+ }
}
/* ── Notification bell ───────────────────────────────────────────────────── */