### System details

AMD Ryzen 7 7840HS; AMD Radeon 780M compositor + NVIDIA RTX 4060 Laptop GPU; BOE 2560x1600@165 Hz built-in display at scale 1.6; Omarchy 4.0.2-1; kernel 7.1.9-arch1-2; Hyprland 0.56.2-1; Aquamarine 0.14.0-2; Mesa 26.2.1-1; 1Password 8.12.34-34.

### What's wrong?

## What's wrong?

Electron/Chromium secondary windows can fail to repaint correctly under native Wayland at fractional scale `1.6`. In the attached clean reproduction, opening 1Password Settings leaves stale regions from the previous locked window/menu, and switching Settings categories produces duplicated or displaced selection backgrounds and content.

1Password is the clearest current reproduction, but this is not believed to be specific to 1Password: similar corruption has previously appeared in Obsidian's initial/setup UI. I have also encountered secondary-window problems in a Chromium Bitwarden extension popup, although that may overlap with Omarchy's generic floating-window sizing rules and is not needed for this minimal reproduction.

## Steps to reproduce

1. Use the normal Omarchy session with its default Electron/Ozone Wayland environment and a monitor scale of `1.6`.
2. Fully quit 1Password, including its background/tray process, then launch it normally from Omarchy.
3. While 1Password is locked, open its menu and choose **Settings**.
4. Click between Settings categories such as Browser, Security, and Appearance.
5. Observe stale/duplicated regions and incorrectly repainted content in the Settings window.

## Expected behavior

Electron/Chromium secondary windows should repaint correctly at the fractional scale offered by Omarchy's display settings.

## Actual behavior

Parts of the previous window state remain visible, while newly selected Settings content is duplicated or drawn in the wrong regions. The attached recording shows this happening repeatedly.

## Isolation / workaround

After fully quitting 1Password, launching it with the following command completely removes the corruption while keeping the monitor at scale `1.6`:

```sh
/opt/1Password/1password --disable-features=WaylandFractionalScaleV1
```

Launching normally reproduces the problem again. The only relevant change is disabling Chromium's `WaylandFractionalScaleV1` feature.

Omarchy currently forces native Wayland globally for Electron/Chromium applications in `/usr/share/omarchy/default/hypr/envs.lua`:

```lua
hl.env("ELECTRON_OZONE_PLATFORM_HINT", "wayland")
hl.env("OZONE_PLATFORM", "wayland")
```

The monitor is configured using Omarchy's current Lua convention:

```lua
local omarchy_gdk_scale = 2
local omarchy_monitor_scale = 1.6

hl.env("GDK_SCALE", tostring(omarchy_gdk_scale))
hl.monitor({ output = "", mode = "preferred", position = "auto", scale = omarchy_monitor_scale })
```

This looks likely to be an upstream Chromium/Electron/Wayland fractional-scale rendering defect, but Omarchy exposes the combination out of the box: it offers scale `1.6`, globally forces Electron onto native Wayland, and ships 1Password without a compatibility flag. It may warrant an Omarchy-side compatibility default, or guidance on the correct upstream component if that is preferred.

## Related reports

- #9904 reports a distinct fractional-scale failure in 1Password’s browser-unlock popup (double-scaled/clipped layout) and an incompatible generic window-size rule.
- #7642 covers a different failure caused by globally forced Ozone/Wayland (an Electron app creates no window).
- #7676 covers a different Chromium popup rendering problem that also occurs at integer scale.
- Hyprland discussion 11627 reports Chromium 148 issues with `WaylandFractionalScaleV1` and the same feature-disable workaround.

## Recording

Attached below.

https://github.com/user-attachments/assets/56e3a3a7-869a-468e-89d1-c3f62f2d32ad