[i34wm] WORKAROUND for handling FireFox windows by i3fyra+i3king+i3run #226

New issue

Open

opened 2025-10-17 14:28:05 +00:00 by 1ntronaut · 0 comments

1ntronaut commented

2025-10-17 14:28:05 +00:00

(Migrated from github.com)

Not a fix, but hopefully a solution for issue #223 |

After fiddling about and being annoyed by LibreWolf disregarding i3king (it's rightful ruler),
I think I found a way to make LibreWolf obey. It's kind of a workaround, or a dirty fix, but the windows are now back in my control.

See my workup of notes and examples below. @TimRegeant @budRich please try and let me know if it works for you as well.

Firefox workaround | ----------------------------------
Workaround for applications based on Firefox codebase such as Thunderbird and forks (e.g. LibreWolf)
i3king's default behaviour is to set the title_format to $INSTANCE (unless you have also set additional GLOBAL or DEFAULT rules). However, the TITLE rule will also 'always execute the command title_format $TITLE (see i3king manpage).
Using a single TITLE rule will result in undesirable and/or inconsistent window properties for i3king to match. This makes it so that with only a single rule entry, i3king will only be able to EITHER rename a window's properties according to matching rules OR invoke i3fyra to move and assign the window to one of the ABCD containers.
Therefore, two rule entries are required in the i3king config (rules) file to:

1. First, match the spawned window with it's original class+instance, and set the desired title_format (to something other than $INSTANCE)
1. Second, match the spawned window to it's original class+instance (while still retaining the window's new title_format you have just defined in the TITLE rule), and execute the command (exec --no-startup-id i3fyra --conid $CONID --move A|B|C|D) to move this window to the desired i3fyra container.
  The above workaround does the job. It is fully compatible with i3run and i3fyra behaviour (hiding/showing/summoning/(re)focusing the configured windows and containers), whether or not they are invoked from command line or via i3wm config keybindings (assuming correct configuration).
  Inevitably, this workaround also has it's limitations. Given the information above I can conclude that this workaround will only work for windows that spawn with at least one different values for the 'class' and 'instance' and 'title_format' properties.
  Additionally, any child windows the main instance must have at least one value that is different from other (child) windows, in order for i3king to be able to distinguish them and handle them accordingly.
  The latter applies to any window property i3king can match it rules to (title , instance, class, role, title_format). Here, 'title' refers to the string value set for WM_NAME by X compositor, as shown when using f.i. xprop.

Lastly, some example cases:

~/.config/i3/config

# Correct configuration for launching browser:
bindsym $mod+Shift+w   $i3run -s -g --class librewolf \
                      --instance Navigator --rename-instance librewolf \
                      --title LibreWolf --rename-title librewolf \
                      -- librewolf

~/.config/i3king/rules

## LibreWolf main window, changing title_format to 'librewolf'
TITLE class=librewolf instance=Navigator
  /^((.+)\s—\s((LibreWolf)|(Librewolf)))$/ librewolf
    $TC C
# This rule **MUST** be defined **AFTER** the TITLE rule. It makes sure LibreWolf will spawn/open in i3fyra container C, and will also (un)hide when pressing the i3wm keybinding.
class=librewolf instance=Navigator
  $TC C

## TITLE rule for any 'Popup' window that LibreWolf might spawn, for which I haven't set any i3king rules below. Makes these windows floating, acting sort of like a safety net.
TITLE class=LibreWolf role=Popup 
  /^(.+)\s—\s(LibreWolf)$/ librewolf-popup
    floating enable, $X i3-msg border pixel 4

## LibreWolf file chooser dialog (Open File" popup)
TITLE class=librewolf instance=librewolf role=GtkFileChooserDialog
  /^(.+)Open\sFile$/ librewolf-file-chooser
    $TC A
# Assign and move window to i3fyra container A (auto-tiling it) 
class=librewolf instance=librewolf role=GtkFileChooserDialog
  $TC A

## LibreWolf's about window; accessed by clicking on the menu>Help>About LibreWolf. Renames
TITLE class=librewolf instance=Browser role=About
  /^(.+)About\sLibrewolf$/ librewolf-about
    $TC B
# Assign and move window to i3fyra container B (auto-tiling it) 
class=librewolf instance=Browser role=About 
  $TC B

## Another popup/dialog I came across, the colorpicker, which can be configured as stated below.
TITLE class=librewolf instance=librewolf type=dialog
  /^(.+)Choose\sa\scolor$/ librewolf-colorpicker
    $TC B
# Assign and move window to i3fyra container B (auto-tiling it) 
class=librewolf instance=librewolf type=dialog
  $TC B

Not a fix, but hopefully a solution for issue #223 | --- After fiddling about and being annoyed by LibreWolf disregarding i3king (it's rightful ruler), I think I found a way to make LibreWolf obey. It's kind of a workaround, or a dirty fix, but the windows are now back in my control. See my workup of notes and examples below. @TimRegeant @budRich please try and let me know if it works for you as well. `Firefox workaround | ----------------------------------` Workaround for applications based on Firefox codebase such as Thunderbird and forks (e.g. LibreWolf) i3king's default behaviour is to set the title_format to $INSTANCE (unless you have also set additional GLOBAL or DEFAULT rules). However, the TITLE rule will **also** 'always execute the command `title_format $TITLE` (see i3king manpage). Using a single TITLE rule will result in undesirable and/or inconsistent window properties for i3king to match. This makes it so that with only a _single_ rule entry, i3king will only be able to **EITHER** rename a window's properties according to matching rules **OR** invoke i3fyra to move and assign the window to one of the ABCD containers. Therefore, two rule entries are required in the i3king config (rules) file to: - 1. First, match the spawned window with it's original class+instance, and set the desired title_format (to something other than $INSTANCE) - 2. Second, match the spawned window to it's original class+instance (while still retaining the window's new title_format you have just defined in the TITLE rule), and execute the command (`exec --no-startup-id i3fyra --conid $CONID --move A|B|C|D`) to move this window to the desired i3fyra container. The above workaround does the job. It is fully compatible with i3run and i3fyra behaviour (hiding/showing/summoning/(re)focusing the configured windows and containers), whether or not they are invoked from command line or via i3wm config keybindings (assuming correct configuration). Inevitably, this workaround also has it's limitations. Given the information above I can conclude that this workaround will only work for windows that spawn **with at least one different values** for the 'class' and 'instance' and 'title_format' properties. Additionally, any child windows the main instance **must have** at least one value that is different from other (child) windows, in order for i3king to be able to distinguish them and handle them accordingly. The latter applies to any window property i3king can match it rules to (title , instance, class, role, title_format). Here, 'title' refers to the string value set for WM_NAME by X compositor, as shown when using f.i. `xprop`. Lastly, some example cases: ~/.config/i3/config ``` # Correct configuration for launching browser: bindsym $mod+Shift+w $i3run -s -g --class librewolf \ --instance Navigator --rename-instance librewolf \ --title LibreWolf --rename-title librewolf \ -- librewolf ``` ~/.config/i3king/rules ``` ## LibreWolf main window, changing title_format to 'librewolf' TITLE class=librewolf instance=Navigator /^((.+)\s—\s((LibreWolf)|(Librewolf)))$/ librewolf $TC C # This rule **MUST** be defined **AFTER** the TITLE rule. It makes sure LibreWolf will spawn/open in i3fyra container C, and will also (un)hide when pressing the i3wm keybinding. class=librewolf instance=Navigator $TC C ## TITLE rule for any 'Popup' window that LibreWolf might spawn, for which I haven't set any i3king rules below. Makes these windows floating, acting sort of like a safety net. TITLE class=LibreWolf role=Popup /^(.+)\s—\s(LibreWolf)$/ librewolf-popup floating enable, $X i3-msg border pixel 4 ## LibreWolf file chooser dialog (Open File" popup) TITLE class=librewolf instance=librewolf role=GtkFileChooserDialog /^(.+)Open\sFile$/ librewolf-file-chooser $TC A # Assign and move window to i3fyra container A (auto-tiling it) class=librewolf instance=librewolf role=GtkFileChooserDialog $TC A ## LibreWolf's about window; accessed by clicking on the menu>Help>About LibreWolf. Renames TITLE class=librewolf instance=Browser role=About /^(.+)About\sLibrewolf$/ librewolf-about $TC B # Assign and move window to i3fyra container B (auto-tiling it) class=librewolf instance=Browser role=About $TC B ## Another popup/dialog I came across, the colorpicker, which can be configured as stated below. TITLE class=librewolf instance=librewolf type=dialog /^(.+)Choose\sa\scolor$/ librewolf-colorpicker $TC B # Assign and move window to i3fyra container B (auto-tiling it) class=librewolf instance=librewolf type=dialog $TC B ```