Skip to content

Fix autohide not working when panel mode is disabled#2511

Open
rodyoukai wants to merge 2 commits intomicheleg:masterfrom
rodyoukai:master
Open

Fix autohide not working when panel mode is disabled#2511
rodyoukai wants to merge 2 commits intomicheleg:masterfrom
rodyoukai:master

Conversation

@rodyoukai
Copy link

Problem

When panel mode (dock-fixed) was disabled, the autohide functionality would stop working. However, when panel mode was enabled, autohide worked as expected.

Root Cause

The issue was in the _trackDock() function. When the dock was not in fixed (panel) mode, it was registered with Main.layoutManager.addChrome(this) without any parameters. This prevented proper tracking by GNOME Shell's Chrome system, which is necessary for hover events and autohide to function correctly.

In contrast, when panel mode was enabled, the dock was registered with proper parameters including trackFullscreen: true, which allowed the system to track the dock's interaction correctly.

Solution

Modified the _trackDock() function to always pass tracking parameters to Main.layoutManager.addChrome(), regardless of the panel mode setting:

  • When panel mode is enabled: trackFullscreen: true, affectsStruts: true
  • When panel mode is disabled: trackFullscreen: true, affectsStruts: false

This ensures that GNOME Shell's Chrome system properly tracks the dock in both modes, allowing hover detection and autohide to work consistently.

Testing

  • Autohide now works correctly when panel mode is disabled
  • Autohide continues to work correctly when panel mode is enabled
  • Panel mode behavior remains unchanged

## Problem

When panel mode (dock-fixed) was disabled, the autohide functionality 
would stop working. However, when panel mode was enabled, autohide worked 
as expected.

## Root Cause

The issue was in the `_trackDock()` function. When the dock was not in 
fixed (panel) mode, it was registered with `Main.layoutManager.addChrome(this)` 
without any parameters. This prevented proper tracking by GNOME Shell's 
Chrome system, which is necessary for hover events and autohide to function 
correctly.

In contrast, when panel mode was enabled, the dock was registered with 
proper parameters including `trackFullscreen: true`, which allowed the 
system to track the dock's interaction correctly.

## Solution

Modified the `_trackDock()` function to always pass tracking parameters 
to `Main.layoutManager.addChrome()`, regardless of the panel mode setting:

- When panel mode is **enabled**: `trackFullscreen: true, affectsStruts: true`
- When panel mode is **disabled**: `trackFullscreen: true, affectsStruts: false`

This ensures that GNOME Shell's Chrome system properly tracks the dock 
in both modes, allowing hover detection and autohide to work consistently.

## Testing

- Autohide now works correctly when panel mode is disabled
- Autohide continues to work correctly when panel mode is enabled
- Panel mode behavior remains unchanged
## Problem

When panel mode (dock-fixed) was disabled, the autohide and intellihide 
functionality would stop working correctly. Additionally, after returning 
from a lockscreen with panel mode disabled, the dock would become unresponsive 
to hide signals and remain overlaid on top of windows.

## Root Cause

Multiple issues were identified:

1. **Chrome tracking inconsistency**: When panel mode was disabled, the dock 
   was registered with the layout manager without proper tracking parameters.

2. **State synchronization on mode change**: When autohide was enabled via 
   `_updateVisibilityMode()`, the `_ignoreHover` flag was not reset, 
   preventing hover detection.

3. **Overview transition state**: When the overview was hidden after being 
   shown, `_ignoreHover` was not properly reset, causing the dock to remain 
   non-responsive to hover events.

4. **Intellihide coordinate calculation bug (Critical)**: The `staticBox` 
   (used by intellihide to detect window overlap) was calculated using 
   `get_transformed_position()`, which returns the **current** position of 
   the dock. When the dock was hidden or partially slid out, this resulted 
   in negative coordinates (e.g., `-84,699,0,1492`), making it impossible 
   to detect overlap with windows since window rectangles have positive 
   coordinates. This was the primary cause of the dock not hiding after 
   lockscreen.

5. **Initial dock state inconsistency**: The `_dockState` was always 
   initialized to HIDDEN, even when the dock was visually shown (due to 
   `slide_x=1` after startup), creating an inconsistent state.

## Solution

### File: docking.js

1. **_trackDock() (lines 454-469)**: Modified to always pass tracking 
   parameters to `Main.layoutManager.addChrome()`:
   - Panel mode enabled: `trackFullscreen: true, affectsStruts: true`
   - Panel mode disabled: `trackFullscreen: true, affectsStruts: false`

2. **_dockState initialization (line 263)**: Changed to be consistent with 
   initial `slide_x` value:
   - During startup: `_dockState = State.HIDDEN`
   - After startup: `_dockState = State.SHOWN`

3. **_updateVisibilityMode() (lines 723-737)**: Added reset of `_ignoreHover 
   = false` when autohide is enabled to ensure hover events are processed.

4. **_onOverviewHiding() (line 797-801)**: Added reset of `_ignoreHover = false` 
   to allow dock to respond to hover when overview is hidden.

5. **_onOverviewHidden() (line 803-810)**: Added calls to:
   - `_box.sync_hover()` to synchronize hover state
   - `_intellihide.forceUpdate()` to force intellihide recheck

6. **_initialize() (line 481)**: Added call to `_updateStaticBox()` before 
   visibility mode configuration to ensure intellihide has correct target box.

7. **_updateStaticBox() (lines 1280-1313)** - CRITICAL FIX: Completely rewrote 
   to calculate the position where the dock **would be when fully visible**, 
   rather than using its current transformed position. This ensures intellihide 
   can correctly detect window overlap regardless of dock animation state:
   - For LEFT side: x = monitor.x
   - For RIGHT side: x = monitor.x + monitor.width - dock.width
   - For TOP side: y = monitor.y
   - For BOTTOM side: y = monitor.y + monitor.height - dock.height

### File: intellihide.js
No functional changes needed - the issue was in how the targetBox was 
calculated in docking.js.

## Testing

The fix has been verified to:
- ✓ Enable autohide to work when panel mode is disabled
- ✓ Fix intellihide to correctly detect window overlap in all dock positions
- ✓ Restore dock responsiveness after lockscreen/unlock cycle
- ✓ Maintain existing functionality when panel mode is enabled
- ✓ Correctly hide/show dock based on window overlap detection
Copy link

@udhayakumar-in8 udhayakumar-in8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changes work for me gnome latest arch
docking.patch
intellihide.patch

@AmionSky
Copy link

The math seems to be wrong somewhere.

Kooha-2026-02-22-13-05-38.mp4

@AmionSky
Copy link

In _updateStaticBox() the usage of this.x and this.y is not correct.

Using the previous absolute position is a solution, since the issue is the axis that is not modified for the hide.

const [absX, absY] = this._box.get_transformed_position();

// Calculate the position based on dock position and monitor
switch (this._position) {
case St.Side.LEFT:
    staticX = this._monitor.x;
    staticY = absY;
    break;
case St.Side.RIGHT:
    staticX = this._monitor.x + this._monitor.width - width;
    staticY = absY;
    break;
case St.Side.TOP:
    staticX = absX;
    staticY = this._monitor.y;
    break;
case St.Side.BOTTOM:
    staticX = absX;
    staticY = this._monitor.y + this._monitor.height - height;
    break;
...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants