## What happens

Dragging a tab out of a Chromium window to tear it into a new window leaves the browser
unresponsive. The new window is created but never follows the pointer, and Chromium stays
frozen until some unrelated input event arrives — pressing `SUPER` is the usual one — at
which point the torn-off window finally appears.

Dragging a tab **within** the same window (reordering) works perfectly. Only tearing a tab
**out**, which creates a new toplevel, hangs.

## Expected

The torn-off window follows the cursor during the drag and drops where it is released,
as it does on a stacking compositor.

## Steps to reproduce

1. Open Chromium (native Wayland, Omarchy's default flags) with two or more tabs.
2. Drag one tab out of the tab strip and release it over empty desktop space.
3. The browser stops responding. The new window is not visible.
4. Press `SUPER`. The torn-off window appears and the browser responds again.

## Root cause

Tearing a tab out makes Chromium create a new `xdg_toplevel` and then ask the compositor to
move that window with the pointer. Hyprland can only perform an interactive move on a
**floating** window.

`default/hypr/apps/browser.lua:4` forces every chromium-family window to tile:

```lua
o.window({ tag = "chromium-based-browser" }, { tag = "-default-opacity", tile = true, opacity = "1.0 0.985" })
```

The torn-off window is therefore tiled the instant it opens, the move request cannot be
honoured, and Chromium waits for a drag that never completes.

## Evidence

Hyprland `socket2` trace of the tear-out. The window opens, takes focus, and 660 ms later
focus leaves it again — it is tiled into the bottom half of the workspace, nowhere near the
pointer, which is still up in the tab strip:

```
22:20:49.204  windowtitlev2>>55d47388ac50,New Tab - Chromium
22:20:49.219  urgent>>55d47388ac50
22:20:49.219  openwindow>>55d47388ac50,2,chromium,New Tab - Chromium
22:20:49.219  activewindowv2>>55d47388ac50      <- torn-off window focused
22:20:49.878  activewindowv2>>55d4735e75e0      <- focus back to the original
```

Geometry during the stall, sampled from `hyprctl clients` every 250 ms — both windows tiled,
the new one placed in the half the cursor is not in:

```
original Chromium   at=[1932, 38]   size=[941, 508]   floating=False
torn-off window     at=[1932, 560]  size=[941, 508]   floating=False
```

## What fixes it

Letting the torn-off window float. Applied as a user rule:

```lua
o.window({ class = "chromium", title = "^New Tab - Chromium$" }, { float = true })
```

With this in place the tear-out completes normally — the window follows the cursor and drops
where released. Confirmed by the reporter.

## Caveats

- I did **not** isolate whether removing `tile = true` alone is sufficient, or whether the
  torn-off window additionally needs an explicit `float` rule. Hyprland tiles new toplevels
  by default, so removing the forced tile may not be enough on its own — worth checking
  before picking a fix.
- The title match above is a workaround, not a proposed fix: a plain `Ctrl+N` window carries
  the same `New Tab - Chromium` title at open and will also float.
- Reproduced on a two-monitor setup. I have not tested whether a single monitor also
  reproduces; nothing in the mechanism appears monitor-dependent.
- `input:follow_mouse` was initially suspected and ruled out — setting it to `0` does not
  help.

## System

```
omarchy          4.0.2-1
hyprland         0.56.2-1
chromium         151.0.7922.173-1
kernel           7.1.9-arch1-2
cpu              AMD Ryzen AI 9 HX 370 w/ Radeon 890M
monitors         HDMI-A-1 1920x1080@60, DP-1 1920x1080@60
```