Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save hjanuschka/5143963e0eed86ff1567e910433802f6 to your computer and use it in GitHub Desktop.

Select an option

Save hjanuschka/5143963e0eed86ff1567e910433802f6 to your computer and use it in GitHub Desktop.
Chromium --app mode Wayland subsurface positioning bug

Chromium --app Mode Wayland Subsurface Positioning Bug

Summary

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.

Environment

  • 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)

Command Used

chromium --ozone-platform=wayland --app=http://localhost:8080/login.html

Technical Findings

The Problem

Chromium 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

Normal Chrome Works Correctly

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.

Comparison

Mode Subsurface Position Result
Normal Chrome (499, 68), (211, 68) ✅ Correct - inside window
Chrome --app (-298, -4) ❌ Wrong - outside window to the left

Analysis

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:

  1. Chrome --app mode may be calculating positions assuming a different window origin
  2. There may be a coordinate space mismatch (buffer vs logical coordinates with fractional scaling)
  3. The --app mode window may have different internal geometry assumptions

Reproduction Steps

  1. Run Hyprland (or another Wayland compositor)
  2. Launch: chromium --ozone-platform=wayland --app=<any-url-with-password-field>
  3. Trigger a popup (e.g., login to a site to get "Save Password" prompt)
  4. Observe: popup appears at top-left of screen, outside the app window

Workaround

Use Chromium without --app mode, or use a regular browser window.

Files Changed During Investigation (Hyprland)

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.

Suggested Chromium Bug Report

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

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