Solving the i3 Startup Race: Why assign Fails for LibreOffice

I tweaked my i3 configuration to automate application placement. During this process, I encountered a frustrating issue. LibreOffice was ignoring my workspace assignments. While the main suite started correctly, specific components like LibreOffice Writer refused to land in their designated workspace.

The first attempt

I originally used the assign directive in my config as it was working well with other applications.

assign [class="libreoffice"] $ws4

When that failed, I used xprop to verify window’s attributes:

WM_CLASS(STRING) = "libreoffice", "libreoffice-writer"
WM_ICON_NAME(COMPOUND_TEXT) = "Untitled 1 — LibreOffice Writer"
_NET_WM_ICON_NAME(UTF8_STRING) = "Untitled 1 — LibreOffice Writer"
WM_NAME(COMPOUND_TEXT) = "Untitled 1 — LibreOffice Writer"
_NET_WM_NAME(UTF8_STRING) = "Untitled 1 — LibreOffice Writer"

Even after updating the config to use the exact libreoffice-writer class, the window still appeared on whatever workspace I happened to be using at the moment.

Why assign fails: The startup Race

After digging into the i3 documentation, the culprit became clear: Timing.

The assign directive is triggered the exact millisecond a window is first “mapped” (created).

The Problem: Heavy applications like LibreOffice often change their window properties after the window is initially created.

When LibreOffice Writer starts, it might initially report a generic class. By the time it identifies itself as libreoffice-writer, the assign check has already passed. i3 has moved on, leaving your window stranded on the wrong workspace.

The Solution: for_window

Unlike assign, the for_window directive acts as a listener. It executes a command whenever a window’s properties change to match your condition.

By switching to a move command, we catch the window the moment it settles into its final title/class:

for_window [instance="libreoffice"] move container to workspace $ws5

The trade-off

The only downside? You will notice the window “flash” briefly on your current workspace before it is taken away to its destination. This is the visual proof of i3 catching the window mid-startup and moving it.

Lesson learned: In i3, assign is great for well-behaved apps. However, for applications that mutate window properties on startup, a delayed move to workspace rule is far more reliable.