Repository navigation
[ZEPPELIN-6586] Make the login page responsive on narrow viewports - #5400
yuminnnnni wants to merge 2 commits into
Conversation
The login panel was a fixed 800px with absolutely positioned columns, so at a 375px viewport it overflowed both sides of the screen. Lay the panel out with flexbox instead: the desktop two-column presentation is unchanged (500px form + 300px sidebar), while the panel now shrinks with the viewport and stacks the sidebar below the form at @screen-sm-max. On short viewports the panel is capped to the viewport height and scrolls internally. Add narrow-viewport Playwright coverage to the login suite for both light and dark themes: no document-level horizontal overflow and the login controls stay fully visible and usable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
voidmatcha
left a comment
There was a problem hiding this comment.
expect(overflow).toBe(0) passes on master too, so this assertion cannot fail. In Chromium, overflow from an absolutely positioned element never reaches documentElement.scrollWidth. At 375px the panel measurably spans -212 to 588, yet that value stays at the viewport width of 375. body.scrollWidth reports 587 for the same page, so reading body makes the assertion 212 on master and 0 here, which is what this step is trying to express.
Suggestion inline. The toBeInViewport checks below do fail on master, so the test still catches the regression.
|
|
||
| await test.step('Then the document should not overflow horizontally', async () => { | ||
| const overflow = await page.evaluate( | ||
| () => document.documentElement.scrollWidth - document.documentElement.clientWidth |
There was a problem hiding this comment.
| () => document.documentElement.scrollWidth - document.documentElement.clientWidth | |
| () => document.body.scrollWidth - document.documentElement.clientWidth |
There was a problem hiding this comment.
@voidmatcha Thanks for the review. Applied your suggestion in 054e472 (body.scrollWidth - documentElement.clientWidth).
FYI, on my setup (Chromium 140 / Playwright 1.55.1, macOS, shiro-enabled server) I saw the opposite split for master at 375px: documentElement.scrollWidth - clientWidth = 213 and body.scrollWidth - clientWidth = 0. So here the body-based check passes on master and only the toBeInViewport checks fail. It may just be an environment difference on my side. If you see this behave differently in CI, I'm happy to adjust, e.g. taking the max of both.
There was a problem hiding this comment.
Thanks for checking this on macOS. You are right: my body-only suggestion can pass on the unfixed master, so it is not a reliable overflow regression check across environments. Could you update the poll to use Math.max(document.documentElement.scrollWidth, document.body.scrollWidth) - document.documentElement.clientWidth and keep the existing toBeInViewport assertions?
I ran the current login spec locally and all 10 tests passed. #5564 is now merged into master, so rebasing should clear the unrelated Prettier failure and allow CI to run the E2E tests. I will re-review after the assertion is updated and CI runs.
…ogin e2e test documentElement.scrollWidth ignores overflow from absolutely positioned elements in Chromium, so the assertion passed even without the fix. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
What is this PR for?
The New UI login page centers a fixed 800px panel (500px form + 300px sidebar, absolutely positioned), so at narrow viewports such as 375x812 the panel overflows both sides of the screen: part of the form is unreachable off the left edge and the welcome sidebar is clipped on the right.
This PR lays the panel out with flexbox instead. The desktop two-column presentation is pixel-identical (500px form + 300px sidebar at the same 800px width), while the panel now shrinks with the viewport and stacks the sidebar below the form at
@screen-sm-max(767px), following the existing theme tokens. On short viewports (e.g. landscape phones) the stacked panel is capped to the viewport height and scrolls internally, so the form always stays reachable. No new dependency is introduced.Narrow-viewport Playwright coverage is added to the existing login suite for both light and dark themes: it asserts no document-level horizontal overflow at 375px and that the username field, password field, and login button stay fully visible and usable.
What type of PR is it?
Bug Fix
Todos
What is the Jira issue?
How should this be tested?
cd zeppelin-web-angular && npx playwright test tests/login/login.spec.ts --project=chromium(requiresconf/shiro.iniso the login page is shown)/#/loginat 375x812 and confirm the form is fully visible with no horizontal overflow; repeat in light and dark themescd zeppelin-web-angular && npm run lintScreenshots (if appropriate)
Desktop (1280px) is unchanged:
Questions:
🤖 Generated with Claude Code