starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[BUG]: Firefox starts unmanaged until move it with komorebi #238

New Issue
Closed
opened 2026-01-05 14:49:12 +01:00 by adam · 2 comments
adam commented 2026-01-05 14:49:12 +01:00
Owner
Copy Link

Originally created by @Carl-Robert on GitHub (Sep 5, 2023).

Describe the bug
Firefox remembers window size and position and always opens up to that part of the screen. Moving Firefox around with komorebi (make it main or shuffle it around) makes it tile properly. Simply re-tiling with komorebi isn't enough to fix it.

Note: Firefox seems to do this also on HashTWM, so Firefox might be to blame here.

To Reproduce
Steps to reproduce the behavior:

  1. Start Firefox and some other programs to make it not maximized.
  2. Close Firefox and other programs.
  3. Start Firefox again on an empty screen.
  4. Firefox occupies the same area as it did when closed and it isn't maximized until move it around with komorebi.

Expected behavior
Firefox should tile immediately like other programs, no matter what size/position it had saved.

Operating System

OS Name:                   Microsoft Windows 11 Enterprise
OS Version:                10.0.22631 N/A Build 22631

komorebic check Output
Provide the output of komorebic check

For example:

No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\User

Looking for configuration files in C:\Users\User

No komorebi configuration found in C:\Users\User

If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration

For some reason I get that error even though komorebi is started with a configuration file (no gaps modified), so this shouldn't be relevant to this issue. The configuration file is "C:\Users\User\komorebi.json" so it is a little weird komorebic check claims it isn't found in that folder.

Originally created by @Carl-Robert on GitHub (Sep 5, 2023). **Describe the bug** Firefox remembers window size and position and always opens up to that part of the screen. Moving Firefox around with komorebi (make it main or shuffle it around) makes it tile properly. Simply re-tiling with komorebi isn't enough to fix it. Note: Firefox seems to do this also on HashTWM, so Firefox might be to blame here. **To Reproduce** Steps to reproduce the behavior: 1. Start Firefox and some other programs to make it not maximized. 2. Close Firefox and other programs. 3. Start Firefox again on an empty screen. 4. Firefox occupies the same area as it did when closed and it isn't maximized until move it around with komorebi. **Expected behavior** Firefox should tile immediately like other programs, no matter what size/position it had saved. **Operating System** ``` OS Name: Microsoft Windows 11 Enterprise OS Version: 10.0.22631 N/A Build 22631 ``` **`komorebic check` Output** Provide the output of `komorebic check` For example: ``` No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\User Looking for configuration files in C:\Users\User No komorebi configuration found in C:\Users\User If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration ``` For some reason I get that error even though komorebi is started with a configuration file (no gaps modified), so this shouldn't be relevant to this issue. The configuration file is "C:\Users\User\komorebi.json" so it is a little weird komorebic check claims it isn't found in that folder.
adam added the bug label 2026-01-05 14:49:12 +01:00
adam closed this issue 2026-01-05 14:49:13 +01:00
adam commented 2026-01-05 14:49:13 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Sep 5, 2023):

This is indeed a bug with Firefox not sending the right signals on launch; you can see some comments in the code related to special handling for Firefox here (without which, this behaviour would be even worse): d8892f3ff2/komorebi/src/window_manager_event.rs (L126)

I recommend opening a bug on the Firefox tracker. 🤞

@LGUG2Z commented on GitHub (Sep 5, 2023): This is indeed a bug with Firefox not sending the right signals on launch; you can see some comments in the code related to special handling for Firefox here (without which, this behaviour would be even worse): https://github.com/LGUG2Z/komorebi/blob/d8892f3ff24c3c9622dd80601706b69e79cdb6f6/komorebi/src/window_manager_event.rs#L126 I recommend opening a bug on the Firefox tracker. 🤞
adam commented 2026-01-05 14:49:13 +01:00
Author
Owner
Copy Link

@Carl-Robert commented on GitHub (Sep 7, 2023):

FYI enabling Windows titlebar on Firefox makes it work perfectly with komorebi. But yes, the fact by default it doesn't is a Firefox bug. The titlebar workaround could be written somewhere, since this is a popular application.

@Carl-Robert commented on GitHub (Sep 7, 2023): FYI enabling Windows titlebar on Firefox makes it work perfectly with komorebi. But yes, the fact by default it doesn't is a Firefox bug. The titlebar workaround could be written somewhere, since this is a popular application.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#238
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?