When running Chromium with --app flag on Wayland (Hyprland compositor), popup dialogs (like "Save Password" prompts) appear outside the window bounds, positioned to the top-left of the screen instead of inside the application window.
- Compositor: Hyprland 0.53.0
- Chromium Version: 144.0.7559.109 (Arch Linux)
- Display: 2560x1600 @ 1.6 scale factor
- Ozone Platform: Wayland (
--ozone-platform=wayland)
chromium --ozone-platform=wayland --app=http://localhost:8080/login.htmlChromium in --app mode sends negative coordinates via wl_subsurface.set_position() for popup subsurfaces:
wl_subsurface.set_position: x=-298 y=-4
This causes the popup to appear at:
- Window position:
(802, 28) - Subsurface offset:
(-298, -4) - Resulting global position:
(504, 24)— which is to the left of the Chrome window
When running Chromium without --app mode, subsurface positions are positive and correct:
coordsGlobal: relPos=499,68 winPos=802,28
coordsGlobal: relPos=211,68 winPos=802,28
These positions place UI elements correctly within the window bounds.
| Mode | Subsurface Position | Result |
|---|---|---|
| Normal Chrome | (499, 68), (211, 68) |
✅ Correct - inside window |
Chrome --app |
(-298, -4) |
❌ Wrong - outside window to the left |
The wl_subsurface.set_position protocol allows negative coordinates (they're relative to the parent surface origin). However, Chromium's --app mode appears to be calculating these positions incorrectly.
Possible causes:
- Chrome
--appmode may be calculating positions assuming a different window origin - There may be a coordinate space mismatch (buffer vs logical coordinates with fractional scaling)
- The
--appmode window may have different internal geometry assumptions
- Run Hyprland (or another Wayland compositor)
- Launch:
chromium --ozone-platform=wayland --app=<any-url-with-password-field> - Trigger a popup (e.g., login to a site to get "Save Password" prompt)
- Observe: popup appears at top-left of screen, outside the app window
Use Chromium without --app mode, or use a regular browser window.
During debugging, we found and fixed an unrelated bug in Hyprland's nested subsurface position accumulation:
// src/protocols/core/Subcompositor.cpp - posRelativeToParent()
// BUG: was using m_parent instead of surf in the traversal loop
auto subsurface = sc<CSubsurfaceRole*>(surf->m_role.get())->m_subsurface.lock();
// Previously incorrectly used: m_parent->m_role.get()This fix is unrelated to the Chromium --app bug but was discovered during investigation.
This should be reported to the Chromium project as a Wayland/Ozone bug affecting --app mode subsurface positioning.
Component: Internals>Ozone>Wayland Labels: OS-Linux, Proj-Ozone