mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[BUG]: Firefox sometimes doesn't tile after opening #344
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Insprill on GitHub (Apr 18, 2024).
Describe the bug
Firefox sometimes (more often than not) doesn't tile correctly after being opened. Increasing the delay here to 50ms fixes the issue in my testing. 25ms works most of the time, but it would still fail occasionally.
6b42587af4/komorebi/src/window.rs (L493-L495)As a side note, has an issue been created on Mozilla's bug tracker to potentially get this issue fixed in Firefox instead of having to work around it here?
To Reproduce
Steps to reproduce the behavior:
Operating System
komorebic checkOutput@LGUG2Z commented on GitHub (Apr 18, 2024):
Nothing has been opened on the Firefox tracker AFAIK. There are a few other programs I'm sure that this delay could be useful for, I think it makes sense to look at making the list of executables to match against configurable as well as the timing, which I suspect is probably dependent on the specs of the machine where komorebi is running.
@mmikeww commented on GitHub (Apr 20, 2024):
my suspicion is that my chrome extension bugs would also be fixed if they could also be delayed before being tiled
perhaps this configurability setting should be added to the applications.yaml and keep a list of all known programs in there
@Insprill commented on GitHub (Apr 20, 2024):
Do we know what the applications, Firefox at least in this case, are doing that causes them to not be tiled correctly? Investigating that would be better since relying on fixed delays is extremely fragile. I don't know much about the inner workings of Komorebi, but could it detect when an application tries to resize/reposition itself shortly after opening (or always?) and force it back to the correct size/place?
@mmikeww commented on GitHub (Apr 20, 2024):
Of course that would be preferable. But what Firefox might be doing, vs
what the chrome extensions might be doing, vs whatever the next problem is,
could all be different. One thing you can count on in Windows, is that
there are never ending edge cases. So I think it's worthwhile to have a
catch all method sooner rather than later to simply have a window match
where we can trigger an intentional delay. Saves user and dev headaches in
the meantime until deeper realer fixes can be found
On Sat, Apr 20, 2024, 2:14 PM Pierce Thompson @.***>
wrote:
@Impasse52 commented on GitHub (Dec 31, 2024):
I'm experiencing this same behavior with Zen browser, I wonder if that's a coincidence since Zen is also based on Gecko. Has there been any progress on implementing a workaround/solution like the ones suggested above?
@LGUG2Z commented on GitHub (Dec 31, 2024):
You can now customize the slow application identifier list and compensation time: https://komorebi.lgug2z.com/schema#slow_application_compensation_time
I'm using this and it's fairly reliable for me with Zen and Firefox, but it's not perfect.
Ultimately this is a Gecko bug which needs to be solved upstream - feel free to link any issues on the Gecko issue tracker related to this issue, but this isn't something we can do anything more about in komorebi for now.
@Impasse52 commented on GitHub (Dec 31, 2024):
Thank you for pointing to the solution! Unfortunately though, I'm not able to get it to work. Are you able to tell me what's wrong here?
I've added the following to my config, according to the schema you linked:
but this doesn't seem to do anything sadly. I open Zen, yet it doesn't tile straight away. Any ideas?
EDIT: Whoops, turns out I was using an older version of Komorebi. Updated through winget, changed the link in the config to the newer schema and restarted. Everything works now! Thank you for this amazing piece of software, happy new year :)