diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-17 09:28:49 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-17 09:28:49 +0200 |
| commit | af30a10b83366416c25eaacec0b4df77526d0924 (patch) | |
| tree | 1395bf4d9000b262cebbf7d66fcb6c9bf22975eb /packages/meshbay-hub/tests/test_layout_responsive.py | |
| parent | 42047dac4041e72e09499e3adf145f1c0f83b284 (diff) | |
| download | meshbay-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/tests/test_layout_responsive.py')
| -rw-r--r-- | packages/meshbay-hub/tests/test_layout_responsive.py | 12 |
1 files changed, 9 insertions, 3 deletions
diff --git a/packages/meshbay-hub/tests/test_layout_responsive.py b/packages/meshbay-hub/tests/test_layout_responsive.py index 741e728..0e2444c 100644 --- a/packages/meshbay-hub/tests/test_layout_responsive.py +++ b/packages/meshbay-hub/tests/test_layout_responsive.py @@ -12,9 +12,15 @@ for 440 px: `margin-left: auto` pushed the excess off the right-hand side rather than the left — which is exactly how it was seen. -These assertions read the stylesheet. That is weak evidence and it is what is -available: there is no browser in this suite, so a layout cannot be measured -here, only its inputs pinned. What they buy is that the four rules holding the +These assertions read the stylesheet, which pins the inputs to a layout without +measuring the layout. That was all there was when they were written; it is no +longer. `test_layout_measured.py` renders the real stylesheet in Chrome at a +phone width and asserts on rectangles, which is what caught the transfers panel +hanging 138 px off the left of a 320 px screen — a defect no reading of +`width: 330px` would have revealed, since it came from where the panel was +anchored rather than from how wide it was. + +Prefer that for anything new. What these buy is that the four rules holding the toolbar together cannot be removed without something saying so. """ |