Yabai: firefox odd tiling

[lostasterisk]

firefox seems to handle tiling unusually:
—
a space is created for new windows, but they don't move to that space. firefox seems to override the position since the placement of the new window is the same as where it would be with no tiling. [see below]

here is a screenshot and a corresponding query of an instance of this issue.

[{ "id":657, "pid":758, "app":"Firefox", "title":"launch – bysimeon", "frame":{ "x":1487.0000, "y":94.0000, "w":1361.0000, "h":814.0000 }, "level":0, "role":"AXWindow", "subrole":"AXStandardWindow", "movable":1, "resizable":1, "split":"horizontal", "floating":0, "sticky":0, "border":0, "zoom-parent":0, "zoom-fullscreen":0, "native-fullscreen":0 },{ "id":454, "pid":758, "app":"Firefox", "title":"launch – bysimeon", "frame":{ "x":1465.0000, "y":72.0000, "w":1365.0000, "h":814.0000 }, "level":0, "role":"AXWindow", "subrole":"AXStandardWindow", "movable":1, "resizable":1, "split":"horizontal", "floating":0, "sticky":0, "border":0, "zoom-parent":0, "zoom-fullscreen":0, "native-fullscreen":0 },{ "id":419, "pid":758, "app":"Firefox", "title":"Commands · koekeishiya/yabai Wiki", "frame":{ "x":50.0000, "y":72.0000, "w":1365.0000, "h":1678.0000 }, "level":0, "role":"AXWindow", "subrole":"AXStandardWindow", "movable":1, "resizable":1, "split":"vertical", "floating":0, "sticky":0, "border":0, "zoom-parent":0, "zoom-fullscreen":0, "native-fullscreen":0 }]

[koekeishiya]

Looks like the window fails to move shortly after it has been created, for some reason. Which version of Firefox are you running? Mine seem to work just fine (Firefox Quantum 61.0.1 64-bit). I have not used Firefox in a long long time, so I assume they probably hit version 70.0.1 or something by now.

[pcr910303]

Actually I also have seen similar layouts on Safari, too.
I'm not sure about frontend development, but it looks like popups and windows can set it's own position, and if the code setting the position runs shortly after yabai set's the window position, that sort of thing happens.

I usually 'wave' the window after things like that happen.

[lostasterisk]

I was on 67.0, I updated to 68.0 and it stopped happening...

curious though, since this seems to happen for other people in other browsers as well. would it be possible to create a delayed position check with a signal, for browser windows?

[dominiklohmann]

curious though, since this seems to happen for other people in other browsers as well. would it be possible to create a delayed position check with a signal, for browser windows?

There's currently no way to just "reset" windows without causing them to flicker.

• You can reset a single window by sending it to another space and pulling it back (yabai -m window $id --space $space). This causes the target window and its parent window to flicker and might cause layout changes.
• You can reset a space by toggling padding or gaps twice (yabai -m space --toggle padding). This causes all windows on the space to flicker, but is guaranteed not to cause layout changes.

Hypothetically...

Assuming a (currently nonexistent) yabai -m window --reset command, one could do the following:

# reset-firefox.sh 
# the window_created signal sets $1 to process id and $2 to window id 
# you can delay with a "sleep 0.1" here if needed
yabai -m query --windows --window "${2}" | jq -re '.app == "FireFox"' \
    && yabai -m window "${2}" --reset

# yabairc
yabai -m signal --add event=window_created action="path/to/reset-firefox.sh"

[narze]

I reset the window by "wiggling" it, seems like a hack but it works with Firefox and Slack.

# Wiggle window
ctrl + alt + cmd - x : yabai -m window --resize top_right:-1:-1 && \
                       yabai -m window --resize top_right:1:1 && \
                       yabai -m window --resize bottom_left:-1:-1 && \
                       yabai -m window --resize bottom_left:1:1

I'll try to hook it with some signal later.

[koekeishiya]

Is this still an issue on master, after #188 was solved? I believe they may be caused by the same underlying issue with the AX API.

[narze]

Yes, I've upgraded yabai to HEAD yesterday and the issue on Firefox & Slack still occurred.

[capaldo]

Is this still an issue on master, after #188 was solved? I believe they may be caused by the same underlying issue with the AX API.

@koekeishiya I continue to have this issue on firefox as well (both the current release and nightly).

[lake-effect]

So this is a weird possibly related bug, also on OSX:

Steps to reproduce:

1. Run yabaiwm on OSX Mojave
2. Log into laptop with clamshell closed, observe proper tiling with all windows
3. Pluck out display cables and do some work with the clamshell
4. Return to desk and plug display cables in again, clamshell closed
5. Firefox windows all sink to the bottom of the secondary display and tile as though being down there is only natural
6. Maximizing the window works but fullscreen leaves a similar margin

[dschetel]

i also experience this issue.
Initially Firefox seemed always to be handled as floating.
After adding
yabai -m rule --add label="Firefox" app="Firefox" manage=on
Firefox is moved to a space on initial launch, but after the initial placement i cannot swap firefox with other programs
(still running macOS Mojave)

[capaldo]

I honestly think this has to do with how Firefox is spawning new tabs and windows not an issue that'll have a fix.

[narze]

Yeah, Firefox still has the issues. But no more on Slack 🤔

[bensleveritt]

Just popped by to say that in many (possibly every) 3rd party window manager fails to get Firefox to behave. It's presumably something in their window management code that takes time to work, as setting the same resize/move instruction seems to work... eventually (jostling about a bit in the process).

I wanted to raise a ticket against Firefox, but I'm not sure I'm articulate enough...

[lake-effect]

Just popped by to say that in many (possibly every) 3rd party window manager fails to get Firefox to behave. It's presumably something in their window management code that takes time to work, as setting the same resize/move instruction seems to work... eventually (jostling about a bit in the process).

I wanted to raise a ticket against Firefox, but I'm not sure I'm articulate enough...

I don't know how picky they are but just filing a ticket that lists all of these other tickets filed about FF behavior in windowmanagers would probably be convincing.

[bensleveritt]

@lake-effect Hardest part of that is finding a public list of issues. Most of the WMs I've used are closed source, with private bug trackers. I have contacted a few to see if they'd support contacting Firefox though

[koekeishiya]

My advice would be to use a different browser. I personally would not have the patience to put up with that. Although I never had this particular issue with Firefox myself. Is this happening on clean installs, or is your version heavily customized?

[bensleveritt]

It's Firefox Developer Edition on clean installs (of which I've had quite a few this past year, thanks no-thanks Apple).

Surprised you've not encountered it, I assumed it was consistent. The fact that it's not is troubling, and will make it harder to reproduce...

Is there any chance you could explain your window management strategy, so I could reduce my issue to a core reproducible state and submit that to them? I'm hoping there might be a simple command you can call to test it out.

[koekeishiya]

Surprised you've not encountered it, I assumed it was consistent. The fact that it's not is troubling, and will make it harder to reproduce...

I stopped using Firefox more or less when they removed the ability for completely customizing the UI. I had a custom userChrome.css at some point with minimal titlebar etc, and back then everything was working fine for me - no slowness with tiling etc.

Is there any chance you could explain your window management strategy, so I could reduce my issue to a core reproducible state and submit that to them? I'm hoping there might be a simple command you can call to test it out.

So there isn't really anything magical here. Yabai subscribes to the window created notification (just one of many), performs some logic to figure out if the window should be managed (and the region it should have), and then requests Firefox to take on that region using the macOS accessibility API (all window utilities on macOS have to go through this API):

AXUIElementSetAttributeValue(window->ref, kAXPositionAttribute, position_ref);
AXUIElementSetAttributeValue(window->ref, kAXSizeAttribute, size_ref);

[lake-effect]

I should mention I don't see this issue at all on current OSX (Catalina) + yabai versions. I originally reported the behavior upthread on Mojave (thus the sand dune background). Of course we don't have much of a clue what's changed on the FF side, although they've been been on a major improvement push for the browser since they started moving Servo in.

edit: spoke too soon, FF is starting to ignore yabai 😞

[arnm]

I also am experiencing this issue. It happens when I drag a tab our of the browser to create a new window. Sadly, I had to switch back to chunkwm because of this :(

[lake-effect]

@arnm Do you think FF handling has regressed in yabai compared to chunkwm?

[arnm]

@arnm Do you think FF handling has regressed in yabai compared to chunkwm?

I dont think this issue is FF specific. I was using chrome.

[narze]

Should we list the app names which are having problems with yabai?

ps. I don't know why but Firefox on my macbook is working well now. But isn't on another machine.

[koekeishiya]

I also am experiencing this issue. It happens when I drag a tab our of the browser to create a new window. Sadly, I had to switch back to chunkwm because of this :(

I believe this was caused by #473 which has been fixed.

[bensleveritt]

Amazing, it very much seems like you've fixed it. Thank you so much @koekeishiya !

[bensleveritt]

Hmm, still happens at times, though definitely less. Will see if I can actually find a pattern to this...

[koekeishiya]

My comment above was specifically for the part I quoted, and not the root cause mentioned in this issue. I'm afraid that is something that will have to be handled by the Firefox devs.

[koekeishiya]

I just installed and played around with stock Firefox 76.0.1 and I cannot reproduce any problems. Closing this.

[nuynait]

Updated: Problem solved by restart the OS..... mmm......

I am experiencing the same issue. I am using Firefox 81.0.1. Just upgraded to yabai-v3.3.0, MacOS: 10.15.5.

It was all good until last week. The upgrade is done after I have experienced strange tiling issue with my firefox.

I do have a customized userChrome.css for firefox to remove the navigation and tab/toolbar. Here is a screencast:

In the screencast, all I did is to use CMD-N to create new window repeatedly.

[nuynait]

Updated: Problem solved by restart the OS..... mmm......

Uninstalled my Firefox and trash all Firefox related folders. (It removed the customized userChrome.css. Then I downloaded the newest release version of Firefox. Version: 81.0.1. Same issue. No difference. Here is a screencast (repeatedly use CMD-N to create new window):

[nuynait]

Problem solved by restart the OS..... mmm......

[yanzhang0219]

@nuynait I think the problem you mentioned could be solved by restarting the yabai service as well. You could try launchctl kickstart -k "gui/${UID}/homebrew.mxcl.yabai" next time when you have this problem.

[nuynait]

@yanzhang0219 I did restart using brew service restart koekeishiya/formulae/yabai several times, which is not working.

Thanks for the tips. Will try next time if I have this problem. Not yet upgrade with an SSD so it took me a long time to do a logout & login / restart...

[capaldo]

@yanzhang0219 I did restart using brew service restart koekeishiya/formulae/yabai several times, which is not working.

Thanks for the tips. Will try next time if I have this problem. Not yet upgrade with an SSD so it took me a long time to do a logout & login / restart...

It works for me briefly when I initially start Firefox or restart the yabai service but the issue comes back after a few minutes.

[DarkFlame57]

Having the same problem. Strangely, everything is fine with tor browser though. Maybe some kind of about:config tinkering may help?

[sliminality]

I also have this issue on Catalina 10.15.6 and Firefox 83. Restarting with brew services or launchctl doesn't help.

[narze]

I saw this video about how to use Yabai, and notice that he does not have this issue at all with Notion app (it should have the same weird-tiling problem like Firefox does).

[sliminality]

@narze I think Notion recently started having that problem, possibly with the recent Electron update. It's possible the screencast was filmed before the update.

[narze]

@sliminality That makes sense. Recently I guessed that maybe the problem was from .macos setup script (about animation & delays), but they were not the case.

[sliminality]

Edit: Updating Firefox Developer Edition to 84.0b6 (64-bit) seems to have fixed the issue for me!

---

It looks like Firefox wasn't registering window_created events at all. If I add the following signal:

yabai -m signal --add event=window_created app="^Firefox$" action="echo 'firefox'"
yabai -m signal --add event=window_created app="^licecap$" action="echo 'licecap'"

and start yabai by running yabai, activating LICEcap logs to stdout, but not Firefox.

[koekeishiya]

Made some change to master, lets see if that fixes it.