[i3ass] any tool in there that can help with this issue?

TimRegeant commented

2025-06-18 17:15:52 +00:00

(Migrated from github.com)

I have having the same issue as described in this https://github.com/i3/i3/issues/3567 i3 issue.

Basically, using firefox in container C of monitor 1, if I bookmark a page, the bookmark dialog box window opens in monitor 1 but then automatically moves to monitor 2 (and not centered) for some reason. Here is what i3info shows for the bookmark dialog window:

title: about:blank - New Bookmark — Firefox
instance: Navigator
class: firefox
role: browser
title-format:
type: dialog
marks: []
win_id: 27263694
con_id: 93879207023616

I have a default i3king rule:

DEFAULT
floating enable, move position center

But it doesn´t prevent the bookmark dialog from moving to monitor 2 (uncentered, the dialog is on the right edge of the monitor). I assume that is because it has the instance of Navigator which I use in another rule to launch the browser in container C with i3run (not sure though).

I tried another i3king rule using the dialog title:

title="about:blank - New Bookmark — Firefox" instance=Navigator
floating enable, move position center

But it doesn´t stop the dialog from shifting to monitor 2. Anyone have an idea why this is happening and how to fix it?

I have having the same issue as described in this https://github.com/i3/i3/issues/3567 i3 issue. Basically, using firefox in container C of monitor 1, if I bookmark a page, the bookmark dialog box window opens in monitor 1 but then automatically moves to monitor 2 (and not centered) for some reason. Here is what i3info shows for the bookmark dialog window: title: about:blank - New Bookmark — Firefox instance: Navigator class: firefox role: browser title-format: type: dialog marks: [] win_id: 27263694 con_id: 93879207023616 I have a default i3king rule: DEFAULT floating enable, move position center But it doesn´t prevent the bookmark dialog from moving to monitor 2 (uncentered, the dialog is on the right edge of the monitor). I assume that is because it has the instance of Navigator which I use in another rule to launch the browser in container C with i3run (not sure though). I tried another i3king rule using the dialog title: title="about:blank - New Bookmark — Firefox" instance=Navigator floating enable, move position center But it doesn´t stop the dialog from shifting to monitor 2. Anyone have an idea why this is happening and how to fix it?

budRich commented

2025-06-21 08:53:36 +00:00

(Migrated from github.com)

I appreciate how detailed this issue is written. Do you by any chance start the main firefox window on monitor 2 and then move it to monitor 1 before opening the bookmarks window?

I wonder if it maybe is so that move position center (which is 100% an i3 command, not i3king) is somehow moving the window to the center of the workarea (the combined monitor area), and if one of the monitors are in portrait and the other in landscape. the center of the workarea would probably be somewhere on the landscape monitor.

Can you post the screen geometry (try the command xrandr or something), like mon1: 1920x1080 at x0y0; mon2 1080x1920 at x1921y0.

Also what happens if you change the DEFAULT rule to just: floating enable (i.e. remove:, move position center). does it still send it away.

If you know that you always want (i don't really like this solution, but it can work as a quick fix) firefox and its dialog windows on monitor 1 you could force move it there, don't use the title, use class=firefox window_type=dialog as the criteria. I think there is a i3 move command to move to the primary monitor, but i don't know it from the top of my head.

Another tip, is to run i3king with --verbose flag, you get detailed output about which window triggered which window rule and such.

PS.
I low-key want to rewrite i3king as a standalone wm-agnostic X11 window ruler.

I appreciate how detailed this issue is written. Do you by any chance start the main firefox window on monitor 2 and then move it to monitor 1 before opening the bookmarks window? I wonder if it maybe is so that move position center (which is 100% an i3 command, not i3king) is somehow moving the window to the center of the workarea (the combined monitor area), and if one of the monitors are in portrait and the other in landscape. the center of the workarea would probably be somewhere on the landscape monitor. Can you post the screen geometry (try the command xrandr or something), like mon1: 1920x1080 at x0y0; mon2 1080x1920 at x1921y0. Also what happens if you change the DEFAULT rule to just: floating enable (i.e. remove:, move position center). does it still send it away. If you know that you always want (i don't really like this solution, but it can work as a quick fix) firefox and its dialog windows on monitor 1 you could force move it there, don't use the title, use `class=firefox window_type=dialog` as the criteria. I think there is a i3 move command to move to the primary monitor, but i don't know it from the top of my head. Another tip, is to run i3king with `--verbose` flag, you get detailed output about which window triggered which window rule and such. --- PS. I low-key want to rewrite i3king as a standalone wm-agnostic X11 window ruler.

1ntronaut commented

2025-06-21 14:51:14 +00:00

(Migrated from github.com)

I have some thoughts about your problem and possible causes and/or fixes.

Please note that I hardly ever use i3fyra to control 2 monitors; for myself, I actually use another workspace to handle the second monitor (I almost always need it to be fullscreen anyway).

@TimRegeant

I have a default i3king rule:

DEFAULT
floating enable, move position center

I would avoid using move position center (i3-msg move position center) to control the window placement. I have run into more issues for (floating) window placement when combining i3-wm-i3fyra-i3king-i3Kornhe. Therefore, to move floating windows, I (successfully) use the following (in i3king config)
- exec --no-startup-id i3Kornhe 5 --oneshot
Also removing the move position center from the DEFAULT rule, as @budRich already suggested, could maybe just work in your usecase.
as an example, I use these rules to handle GIMP's several windows (move main GIMP window to workspace 6; auto-float all it's dialog-type windows, move them to bottom right corner of the screen)

~/.config/i3king/rules

DEFAULT \
  class=(URxvt|XTerm|st-256color|St) instance=auto, \
  class=Xfce4-terminal role=auto
    floating enable

set $X   exec --no-startup-id
set $TC  exec --no-startup-id i3fyra --conid $CONID --move
set $TWS move container to workspace number

GLOBAL \
  class=URxvt instance=auto, \
  instance=firefox
    title_format $INSTANCE

class=URxvt instance=floatterm
  floating enable, sticky enable, \
  $X i3-msg border pixel 4, $X i3Kornhe 8 --oneshot

...

class=Gimp instance=gimp
  $TWS 6

class=Gimp instance=gimp type=dialog 
  floating enable, $X i3-msg border pixel 4, $X i3Kornhe 9 --oneshot

@budRich

Another tip, is to run i3king with --verbose flag, you get detailed output about which window triggered which window rule and such.

I always run an i3king --verbose instance (in full bud-flavored i3fyra-fanboy style) to monitor i3king's activity (the window is also i3king-controlled to spawn in container D)

~/.config/i3/config

set $i3king exec --no-startup-id i3term -s -i i3king \
          --font 'FixedFixedsys' \
          --font-size "12" \
          --palette=base16-greenscreen-dark \
          -- i3king --verbose

$i3king

Also don't forget to 'restart' the i3king process: either by killing and re-launching the currently running one, or by using the following command line:
- kill -USR1 $(< "$XDG_RUNTIME_DIR/i3ass/i3king.pid")
- (I have this aliased to reking for use in my zshrc and bashrc): alias reking='kill -USR1 $(< "$XDG_RUNTIME_DIR/i3ass/i3king.pid")'
P.S. it's amazing what kind of errors even I have been able to 'fix' or detect, when using i3king --verbose. Except for the following error, which continues to elude me. For the life of me, I cannot find the line in i3king (or any other i3wm or i3fyra-related scripts I use) and I cannot figure out what triggers it:

i3king --verbose output:

...
[{"success":true}]
[{"success":true}]
[{"success":true}]
[{"success":true}]
[{"success":true}]
[{"success":true}]
[{"success":true}]
/usr/bin/i3king: line 383: execute: bad array subscript
...

If you know that you always want (i don't really like this solution, but it can work as a quick fix) firefox and its dialog windows on monitor 1 you could force move it there, don't use the title, use class=firefox window_type=dialog as the criteria. I think there is a i3 move command to move to the primary monitor, but i don't know it from the top of my head.

@budRich @TimRegeant: be careful to not mix i3wm's and i3king's syntax (see also, my example for GIMP's windows above):
"use class=firefox window_type=dialog as the criteria"
- for i3wm: the syntax for window type is window_type
- for i3king: the syntax for window type is type
bud is right here, but using the i3wm command (i3-msg move container to output left) doesn't (always) play nicely with i3fyra, i3king and/or xdotool. I think this is (in my case) caused by using the braceleft/braceright keybindings.

~/.config/i3/config

set $super    bindsym Mod4 

...

$super+Shift+braceleft            move container to output left, focus output left
$super+Shift+braceright           move container to output right, focus output right

Regarding firefox:

I find firefox (or forks thereof) particularly annoying and/or incompatible with either i3wm or i3fyra-i3king naming conventions, as well as it playing nicely with i3run commands.
For the longest time I've been trying to properly configure librewolf windows to behave nicely in i3fyra and on i3fyra workspace.. but haven't been successful.

There seems to be a mutually exclusive conflicting configuration somewhere in i3wm config, i3king config OR in any of the scripts themselves (i3fyra,i3run,i3king,...), where it's either:

1. The librewolf windows do not get renamed properly, but the i3run command spawns librewolf, but keeps spawning new windows of librewolf. i3king also makes sure it is put in container C and remains there and i3fyra --float floats the window and/or auto-tiles it correctly in container C.
1. OR: the librewolf windows DO get renamed properly, but the main window is never put in the right container, BUT running the i3run command DOES run librewolf, shows+focuses i3fyra container with existing librewolf window. Also: when using i3fyra --float on any librewolf window, does make it floating, but does never make the window tiling (nor put it in the correct container C)
for context:

~/.config/i3/config

set $i3run   exec --no-startup-id i3run
...
bindsym $mod+Shift+w   $i3run -s -g --class librewolf \
                       --instance Navigator --rename-instance librewolf \
                       --title LibreWolf --rename-title librewolf \
                       -- librewolf

~/.config/i3king/rules

set $X   exec --no-startup-id
set $TC  exec --no-startup-id i3fyra --conid $CONID --move
...
TITLE class=LibreWolf instance=LibreWolf role=About
  /^(.+)About\sLibrewolf$/ librewolf-about
    $TC B

TITLE class=LibreWolf instance=Librewolf type=dialog role=GtkFileChooserDialog
  /^(.+)Open\sFile$/ librewolf-file-chooser
    $TC B

...

TITLE class=librewolf instance=Navigator
  /^((.+)\s—\s((LibreWolf)|(Librewolf)))$/ librewolf
    $TC C

TITLE class=LibreWolf role=Popup 
  /^(.+)\s—\s(LibreWolf)$/ librewolf-popup
    floating enable, $X i3-msg border pixel 4

I have some thoughts about your problem and possible causes and/or fixes. - Please note that I hardly ever use i3fyra to control 2 monitors; for myself, I actually use another workspace to handle the second monitor (I almost always need it to be fullscreen anyway). --- > @TimRegeant >> I have a default i3king rule: >> >> DEFAULT >> floating enable, move position center - I would avoid using `move position center` (`i3-msg move position center`) to control the window placement. I have run into more issues for (floating) window placement when combining i3-wm-i3fyra-i3king-i3Kornhe. Therefore, to move floating windows, I (successfully) use the following (in i3king config) - `exec --no-startup-id i3Kornhe 5 --oneshot` - Also removing the `move position center` from the DEFAULT rule, as @budRich already suggested, could maybe just work in your usecase. - as an example, I use these rules to handle GIMP's several windows (move main GIMP window to workspace 6; auto-float all it's dialog-type windows, move them to bottom right corner of the screen) > ~/.config/i3king/rules ``` DEFAULT \ class=(URxvt|XTerm|st-256color|St) instance=auto, \ class=Xfce4-terminal role=auto floating enable set $X exec --no-startup-id set $TC exec --no-startup-id i3fyra --conid $CONID --move set $TWS move container to workspace number GLOBAL \ class=URxvt instance=auto, \ instance=firefox title_format $INSTANCE class=URxvt instance=floatterm floating enable, sticky enable, \ $X i3-msg border pixel 4, $X i3Kornhe 8 --oneshot ... class=Gimp instance=gimp $TWS 6 class=Gimp instance=gimp type=dialog floating enable, $X i3-msg border pixel 4, $X i3Kornhe 9 --oneshot ``` --- > @budRich >> Another tip, is to run i3king with --verbose flag, you get detailed output about which window triggered which window rule and such. - I always run an `i3king --verbose` instance (in full bud-flavored i3fyra-fanboy style) to monitor i3king's activity (the window is also i3king-controlled to spawn in container D) > ~/.config/i3/config ``` set $i3king exec --no-startup-id i3term -s -i i3king \ --font 'FixedFixedsys' \ --font-size "12" \ --palette=base16-greenscreen-dark \ -- i3king --verbose $i3king ``` - **Also** don't forget to 'restart' the i3king process: either by killing and re-launching the currently running one, or by using the following command line: - `kill -USR1 $(< "$XDG_RUNTIME_DIR/i3ass/i3king.pid")` - (I have this aliased to `reking` for use in my zshrc and bashrc): `alias reking='kill -USR1 $(< "$XDG_RUNTIME_DIR/i3ass/i3king.pid")'` - **P.S.** it's amazing what kind of errors even I have been able to 'fix' or detect, when using `i3king --verbose`. **Except** for the following error, which continues to elude me. For the life of me, I cannot find the line in i3king (or any other i3wm or i3fyra-related scripts I use) and I cannot figure out what triggers it: > `i3king --verbose` output: ``` ... [{"success":true}] [{"success":true}] [{"success":true}] [{"success":true}] [{"success":true}] [{"success":true}] [{"success":true}] /usr/bin/i3king: line 383: execute: bad array subscript ... ``` --- >> If you know that you always want (i don't really like this solution, but it can work as a quick fix) firefox and its dialog windows on monitor 1 you could force move it there, don't use the title, use class=firefox window_type=dialog as the criteria. I think there is a i3 move command to move to the primary monitor, but i don't know it from the top of my head. - @budRich @TimRegeant: be careful to **not mix i3wm's and i3king's syntax** (see also, my example for GIMP's windows above): - "use class=firefox window_type=dialog as the criteria" - for **i3wm**: the syntax for window type is `window_type` - for **i3king**: the syntax for window type is `type` - bud is right here, but using the i3wm command (`i3-msg move container to output left`) doesn't (always) play nicely with i3fyra, i3king and/or xdotool. I think this is (in my case) caused by using the `braceleft`/`braceright` keybindings. > ~/.config/i3/config ``` set $super bindsym Mod4 ... $super+Shift+braceleft move container to output left, focus output left $super+Shift+braceright move container to output right, focus output right ``` --- Regarding firefox: - I find firefox (or forks thereof) particularly annoying and/or incompatible with either i3wm or i3fyra-i3king naming conventions, _as well as_ it playing nicely with i3run commands. - For the longest time I've been trying to properly configure librewolf windows to behave nicely in i3fyra and on i3fyra workspace.. but haven't been successful. There seems to be a mutually exclusive conflicting configuration somewhere in i3wm config, i3king config OR in any of the scripts themselves (i3fyra,i3run,i3king,...), where it's either: - 1. The librewolf windows do not get renamed properly, but the i3run command spawns librewolf, but keeps spawning new windows of librewolf. i3king also makes sure it is put in container C and remains there and `i3fyra --float` floats the window and/or auto-tiles it correctly in container C. - 2. OR: the librewolf windows DO get renamed properly, but the _main window_ is **never** put in the right container, BUT running the i3run command DOES run librewolf, shows+focuses i3fyra container with existing librewolf window. Also: when using `i3fyra --float` on any librewolf window, does make it floating, but does never make the window tiling (nor put it in the correct container C) - for context: > ~/.config/i3/config ``` set $i3run exec --no-startup-id i3run ... bindsym $mod+Shift+w $i3run -s -g --class librewolf \ --instance Navigator --rename-instance librewolf \ --title LibreWolf --rename-title librewolf \ -- librewolf ``` > ~/.config/i3king/rules ``` set $X exec --no-startup-id set $TC exec --no-startup-id i3fyra --conid $CONID --move ... TITLE class=LibreWolf instance=LibreWolf role=About /^(.+)About\sLibrewolf$/ librewolf-about $TC B TITLE class=LibreWolf instance=Librewolf type=dialog role=GtkFileChooserDialog /^(.+)Open\sFile$/ librewolf-file-chooser $TC B ... TITLE class=librewolf instance=Navigator /^((.+)\s—\s((LibreWolf)|(Librewolf)))$/ librewolf $TC C TITLE class=LibreWolf role=Popup /^(.+)\s—\s(LibreWolf)$/ librewolf-popup floating enable, $X i3-msg border pixel 4 ```

👍 1

TimRegeant commented

2025-06-29 13:13:47 +00:00

(Migrated from github.com)

Thanks guys, appreciate all the suggestions. Unforunately, after trying everything you suggested, it still doesn't behave. I put it down to the program itself not behaving. The reason I say that is I see the bookmark dialog doing everything I set rules up for....then there is a pause, then it jumps to the second monitor - no matter what I do or what rules I set. Running i3king --verbose also proves the rules are hitting so it doesn't seem to be i3king issue.

TimRegeant commented

2025-06-29 13:13:55 +00:00

(Migrated from github.com)

To address some of your specific suggestions:

@budRich @1ntronaut

I wonder if it maybe is so that move position center (which is 100% an i3 command, not i3king) is somehow moving the
window to the center of the workarea (the combined monitor area), and if one of the monitors are in portrait and the other in
landscape. the center of the workarea would probably be somewhere on the landscape monitor.

Ok, took that command out but didn't make any difference to the problem. Of course without the center command, then when starting out on the first monitor it didn't center so that was working.

I also tried specific commands like move output DP-2.

Can you post the screen geometry (try the command xrandr or something), like mon1: 1920x1080 at x0y0; mon2 1080x1920
at x1921y0.

Sure,
Screen 0: minimum 8 x 8, current 5120 x 1600, maximum 32767 x 32767
DP-0 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
DP-2 connected primary 2560x1600+2560+0 (normal left inverted right x axis y axis) 518mm x 324mm

DP-0 is on the left, DP-2 on the right as I look at them.

Also what happens if you change the DEFAULT rule to just: floating enable (i.e. remove:, move position center). does it still
send it away.

Yep.

If you know that you always want (i don't really like this solution, but it can work as a quick fix) firefox and its dialog windows
on monitor 1 you could force move it there, don't use the title, use class=firefox window_type=dialog as the criteria. I think
there is a i3 move command to move to the primary monitor, but i don't know it from the top of my head.

Same thing.

Another tip, is to run i3king with --verbose flag, you get detailed output about which window triggered which window rule and
such.

Yes, that confirmed the rules were being matched.

To address some of your specific suggestions: @budRich @1ntronaut >I wonder if it maybe is so that move position center (which is 100% an i3 command, not i3king) is somehow moving the >window to the center of the workarea (the combined monitor area), and if one of the monitors are in portrait and the other in >landscape. the center of the workarea would probably be somewhere on the landscape monitor. Ok, took that command out but didn't make any difference to the problem. Of course without the center command, then when starting out on the first monitor it didn't center so that was working. I also tried specific commands like move output DP-2. >Can you post the screen geometry (try the command xrandr or something), like mon1: 1920x1080 at x0y0; mon2 1080x1920 >at x1921y0. Sure, Screen 0: minimum 8 x 8, current 5120 x 1600, maximum 32767 x 32767 DP-0 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 518mm x 324mm DP-2 connected primary 2560x1600+2560+0 (normal left inverted right x axis y axis) 518mm x 324mm DP-0 is on the left, DP-2 on the right as I look at them. >Also what happens if you change the DEFAULT rule to just: floating enable (i.e. remove:, move position center). does it still >send it away. Yep. >If you know that you always want (i don't really like this solution, but it can work as a quick fix) firefox and its dialog windows >on monitor 1 you could force move it there, don't use the title, use class=firefox window_type=dialog as the criteria. I think >there is a i3 move command to move to the primary monitor, but i don't know it from the top of my head. Same thing. >Another tip, is to run i3king with --verbose flag, you get detailed output about which window triggered which window rule and >such. Yes, that confirmed the rules were being matched.

TimRegeant commented

2025-06-29 13:25:11 +00:00

(Migrated from github.com)

This image shows where the dialog ends up. The bookmark dialog itself ends up on the left monitor except the right border of the dialog is still on the right monitor somehow attached or overlaying the left border of the browser window.

![Image](https://github.com/user-attachments/assets/4288fb9d-fb1c-4cd7-a7f8-f7cbbcb36f56) This image shows where the dialog ends up. The bookmark dialog itself ends up on the left monitor *except* the right border of the dialog is still on the right monitor somehow attached or overlaying the left border of the browser window.

budRich commented

2025-06-29 23:17:20 +00:00

(Migrated from github.com)

@TimRegeant Thanks for the update! and as always excellent support from @1ntronaut , you know how these crazy scripts works (and not work) better than me now :D.

I will do a deepdive on firefoxed windows tomorrow and see what is going on here. stay tuned, and keep me posted if you figure something out.

@TimRegeant Thanks for the update! and as always excellent support from @1ntronaut , you know how these crazy scripts works (and not work) better than me now :D. I will do a deepdive on firefoxed windows tomorrow and see what is going on here. stay tuned, and keep me posted if you figure something out.

TimRegeant commented

2025-06-30 03:09:59 +00:00

(Migrated from github.com)

Thanks. Was trying not to muddy the waters, but in actuallity I am running waterfox, a fork of firefox. Before you were doing a deep dive, I tried firefox and it seems to work ok. I guess waterfox is similar to librefox mentioned earlier and it just doesn't behave well.

1ntronaut commented

2025-06-30 08:26:40 +00:00

(Migrated from github.com)

@TimRegeant
It's unfortunate that my suggestions didn't help. I'm at a loss here.

@budRich

@TimRegeant Thanks for the update! and as always excellent support from @1ntronaut , you know how these crazy scripts works (and not work) better than me now :D.

I will do a deepdive on firefoxed windows tomorrow and see what is going on here. stay tuned, and keep me posted if you figure something out.

I'm curious to view your next findings with regards to firefoxed windows.

@TimRegeant It's unfortunate that my suggestions didn't help. I'm at a loss here. @budRich > [@TimRegeant](https://github.com/TimRegeant) Thanks for the update! and as always excellent support from [@1ntronaut](https://github.com/1ntronaut) , you know how these crazy scripts works (and not work) better than me now :D. > > I will do a deepdive on firefoxed windows tomorrow and see what is going on here. stay tuned, and keep me posted if you figure something out. I'm curious to view your next findings with regards to firefoxed windows.

TimRegeant commented

2025-06-30 13:08:36 +00:00

(Migrated from github.com)

Yes, all I can say is that the bookmark dialog is matched by i3king and performs any commands required. Then after about 1 second, the dialog moves to the position on the left monitor shown in the picture above. It seems the browser itself is moving this dialog after i3king processes its rule.

Maybe wmctrl can work in some way. I'll try out a few things with that tool.

Yes, all I can say is that the bookmark dialog is matched by i3king and performs any commands required. Then after about 1 second, the dialog moves to the position on the left monitor shown in the picture above. It seems the browser itself is moving this dialog after i3king processes its rule. Maybe wmctrl can work in some way. I'll try out a few things with that tool.

TimRegeant commented

2025-07-02 15:14:42 +00:00

(Migrated from github.com)

Hello, have some interesting findings but still no solution.

Normally I open the browser on primary monitor (right side monitor) container C via i3fyra.

set $to_container exec --no-startup-id i3fyra --conid $CONID --move
instance=waterfox-instance window_type=normal
$to_container C

The rule for the bookmark dialog:
class=waterfox window_type=dialog
floating enable, move position center

this works, but of course the bookmarks dialog is somehow forced to the left monitor after the dialog rule is performed. Interesting that wmctrl lists the left monitor as desktop 0.

0 * DG: N/A VP: 0,0 WA: N/A 6
1 - DG: N/A VP: 0,0 WA: N/A 7
2 - DG: N/A VP: 2560,0 WA: N/A 1
3 - DG: N/A VP: 2560,0 WA: N/A 2

I have set in the config to use workspace 1-5 on right monitor and 6-10 on left monitor.
set $fm DP-2
set $sm DP-0

set $ws1 "1"
set $ws2 "2"
set $ws3 "3"
set $ws4 "4"
set $ws5 "5"
set $ws6 "6"
set $ws7 "7"
set $ws8 "8"
set $ws9 "9"
set $ws10 "10"

workspace $ws1 output $fm
workspace $ws2 output $fm
workspace $ws3 output $fm
workspace $ws4 output $fm
workspace $ws5 output $fm
workspace $ws6 output $sm
workspace $ws7 output $sm
workspace $ws8 output $sm
workspace $ws9 output $sm
workspace $ws10 output $sm

xrandr reports as:
Screen 0: minimum 8 x 8, current 5120 x 1600, maximum 32767 x 32767
DP-0 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
DP-2 connected primary 2560x1600+2560+0 (normal left inverted right x axis y axis) 518mm x 324mm

However, if I change the browser rule to open the browser in workspace 3 which is on the right side monitor

instance=waterfox-instance window_type=normal
move workspace 3

the bookmark dialog's rule is honored as usual but afterwards the dialog is forced to move to the left monitor automatically again.

But if I then change the rule to open the browser in workspace 7 which is on the left monitor

instance=waterfox-instance window_type=normal
move workspace 7

Then the rule for the Bookmark dialog is honored, centered and it is not moved to the edge of the left monitor.

So, it appears the browser or i3 itself is forcing the bookmark dialog to the left monitor even if the browser is on the right monitor. If the browser is on the left monitor it works fine.

Hello, have some interesting findings but still no solution. Normally I open the browser on primary monitor (right side monitor) container C via i3fyra. set $to_container exec --no-startup-id i3fyra --conid $CONID --move instance=waterfox-instance window_type=normal $to_container C The rule for the bookmark dialog: class=waterfox window_type=dialog floating enable, move position center this works, but of course the bookmarks dialog is somehow forced to the left monitor after the dialog rule is performed. Interesting that wmctrl lists the left monitor as desktop 0. 0 * DG: N/A VP: 0,0 WA: N/A 6 1 - DG: N/A VP: 0,0 WA: N/A 7 2 - DG: N/A VP: 2560,0 WA: N/A 1 3 - DG: N/A VP: 2560,0 WA: N/A 2 I have set in the config to use workspace 1-5 on right monitor and 6-10 on left monitor. set $fm DP-2 set $sm DP-0 set $ws1 "1" set $ws2 "2" set $ws3 "3" set $ws4 "4" set $ws5 "5" set $ws6 "6" set $ws7 "7" set $ws8 "8" set $ws9 "9" set $ws10 "10" workspace $ws1 output $fm workspace $ws2 output $fm workspace $ws3 output $fm workspace $ws4 output $fm workspace $ws5 output $fm workspace $ws6 output $sm workspace $ws7 output $sm workspace $ws8 output $sm workspace $ws9 output $sm workspace $ws10 output $sm xrandr reports as: Screen 0: minimum 8 x 8, current 5120 x 1600, maximum 32767 x 32767 DP-0 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 518mm x 324mm DP-2 connected primary 2560x1600+2560+0 (normal left inverted right x axis y axis) 518mm x 324mm However, if I change the browser rule to open the browser in workspace 3 which is on the right side monitor instance=waterfox-instance window_type=normal move workspace 3 the bookmark dialog's rule is honored as usual but afterwards the dialog is forced to move to the left monitor automatically again. But if I then change the rule to open the browser in workspace 7 which is on the left monitor instance=waterfox-instance window_type=normal move workspace 7 Then the rule for the Bookmark dialog is honored, centered and it is not moved to the edge of the left monitor. So, it appears the browser or i3 itself is forcing the bookmark dialog to the left monitor even if the browser is on the right monitor. If the browser is on the left monitor it works fine.

1ntronaut commented

2025-08-20 17:57:51 +00:00

(Migrated from github.com)

@budRich Just confirming above problem is still present and wanted to note that the same faulty behaviour exists when using any application with a firefox-oid or firefox-based UI (firefox forks, of course, but also f.i. Thunderbird and Zotero)

Rows
Columns

[i3ass] any tool in there that can help with this issue? #223