Skip to content

(Bug) : Dock isn't dodging windows that are tiled to the right side of screen. #2413

Closed

Description

@jakegithub24

Specs :

  • Ubuntu 24.04.02 LTS
  • 6.14.04-24-generic
  • GNOME 46.0
  • Mutter
  • 1920x1080p resolution

Issue description :

I am facing this weird issue since last 6 months. I have installed this "Dash-to-dock" gnome extension as usual. It is working perfectly fine except this one issue. I use default window tiling present in Ubuntu. I prefer dock setting to intelligent autohide and dodge windows (Only focused application's windows) mode. It works good, but with one specific issue.

Whenever I try to tile any application window to the right side of the desktop/screen, the dock behaves weird. It hovers over the application window instead of hiding itself.

I have searched for solution many times, but I was not able to find one. I would really appreciate to hear on this. Thanks.

Image Image Image Image

Activity

  1. changed the title [-]Bug: Dock isn't dodging windows that are tiled to the right side of screen.[/-] [+](Bug) : Dock isn't dodging windows that are tiled to the right side of screen.[/+] on Jul 28, 2025
  2. vanvugt commented on Jul 29, 2025

    @vanvugt
    Collaborator

    This may relate to the fact the window isn't moving so much as jumping when tiled. Maybe the dock isn't getting the right events to know about it.

    Also, does ubuntu-dock have the same bug?

  3. PixelcrafterEXE commented on Aug 28, 2025

    @PixelcrafterEXE
    Contributor

    Ubuntu-dock has the same problem. When scaled far enough beyond the center-line the window is doged. It looks like the position to check is miscalculated somewhere. It hides only when something is within a bounding box with the size of the dock that starts at the left edge (not the center) of the screen.

  4. nneto commented on Sep 15, 2025

    @nneto

    I'm experiencing this. I have an ultrawide monitor. When I snap a window to the left, the dock hides, when I press Super+RightArrow and move to the right, it appears. When I expand some amount of the window (it's more than half of the dock) then it hides again.

    Image Image Image Image
  5. barstown commented on Dec 2, 2025

    @barstown

    Same experience for me. User above, nneto, shows exactly the behavior I've been getting for months. It also happens on my Framework laptop, which obviously is not an Ultrawide so I don't think it related to that necessarily.

    I've found a [very] temporary fix, but haven't been able to pinpoint what makes the issue return, or when, but it's usually minutes. If I right-click on the app menu on the dock and open the extension settings, and then click anywhere in it, and then go back to my app on the right side of the screen the auto-hide behavior works as expected for a while. Sometimes I can close the settings after that and have it work for a bit, other times it works better if I just leave that window open in the background.

    • Fedora Silverblue/Bluefin 43, previously 42.
    • 6.17.1-300
    • GNOME 49
    • Wayland
    • 3440x1440, 2880x1920
  6. howl commented on Dec 13, 2025

    @howl

    Intelligent hide is taking into account the dock as it is placed in the left of the screen instead of centred. I observed this in my use case and looking at your screenshots it seems to confirm that's the problem.

  7. bamtests commented on Jan 16, 2026

    @bamtests

    Came to create this bug but since it is already here I also came across another potential piece of it that could help the dev debug.

    When two windows of the same type are open (i.e. two terminal windows or two nautilus windows) and the window on the right window is in focus, the dock does not improperly unhide itself. When the two windows are different (i.e. terminal and nautilus are open side by side) and the right window is in focus, then the dock improperly unhides itself.

  8. jakegithub24 commented on Feb 12, 2026

    @jakegithub24
    Author

    Thank you @3v1n0 for fixing this bug. It is gonna make GNOME more better.

  9. ionutbortis commented on Feb 13, 2026

    @ionutbortis

    The fix for this caused a regression, see #2501

  10. reopened this on Mar 5, 2026
  11. added 2 commits that reference this issue on Jul 25, 2026
    43f315c
    b971925
  12. added a commit that references this issue on Sep 2, 2026
    b7d7786
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions