Dock reserves only half its height as strut, leaving an unreachable dead band above the dock (GNOME 48.7, X11, 4K, no scaling)

[dgalbraith]

Summary

On a single 3840x2160 X11 display with no scaling, the dock's tracked actor is ~146px tall, but _NET_WORKAREA is only reduced by ~73px — almost exactly half. Windows are laid out ending at y≈2013, while the published work area extends to y=2087.

The resulting ~74px band belongs to nothing: no window, no reactive Shell actor. Clicks and keyboard focus both fail there, and stale content from the window below remains painted in the strip, so it looks like part of the application is visible but unresponsive.

Disabling the extension restores input all the way to y=2159.

Environment

• Extension: Dash2Dock Animated, version 92 (latest, installed from extensions.gnome.org)
• GNOME Shell 48.7
• Debian trixie
• Session type: X11
• Display: single monitor, HDMI-0, 3840x2160+0+0 @ 119.88Hz
• GPU: NVIDIA GeForce RTX, proprietary driver 610.43.02 (OpenGL 4.6.0)
• Scaling: none — Xft.dpi: 96, org.gnome.desktop.interface scaling-factor = uint32 0, text-scaling-factor = 1.0, GDK_SCALE unset
• Reproduces with a fully default configuration (dconf reset -f /org/gnome/shell/extensions/dash2dock-lite/)

Steps to reproduce

1. Run GNOME 48.7 on X11, single 3840x2160 monitor, 100% scaling
2. Enable Dash2Dock Animated v92 with default settings
3. Open and maximize any window
4. Attempt to click in the horizontal band roughly 70px above the dock

Expected behaviour

Either the strut matches the dock's actual occupied height, or no strut is reserved and windows extend to the full screen height with the dock floating over them. In both cases every pixel is either inside a window or inside the dock.

Actual behaviour

A ~74px full-width band is inside the declared work area but contains no window. It accepts neither pointer nor keyboard input.

Measurements

Tracked actors, from Looking Glass:

61: St_Widget 3840x68.10205078125 @0,2091.89794921875 input=true
62: DashToDock 3840x146.199951171875 @0,2013.800048828125 input=true
63: St_Widget 3840x2 @0,2158 input=true

Published work area with the extension enabled:

$ xprop -root _NET_WORKAREA
_NET_WORKAREA(CARDINAL) = 0, 0, 3840, 2087, 0, 0, 3840, 2087

2160 − 2087 = 73px reserved, against a 146.2px dock actor.

Pointer sampling over a freshly maximized window, extension enabled:

y	WINDOW
2011	142606346
2067	0
2099	0
2121	0
2147	0
2159	0

Same window, extension disabled:

y	WINDOW
2158	142606346
2159	142606346

Ruled out

• Reactive-actor interception. global.stage.get_actor_at_pos(Clutter.PickMode.REACTIVE, 200, 2100) returns MetaBackgroundActor — the wallpaper, nothing above it. Setting affectsInputRegion = false on tracked actors 61/62/63 and calling _updateRegions() changes nothing.
• A phantom X window. xwininfo -root -tree shows no full-width window near the bottom edge. The only 3840x2160 entry is the normal mutter guard window.
• Framebuffer or panning mismatch. xrandr reports Screen 0: current 3840 x 2160 against an active mode of 3840x2160, offset +0+0.
• Pointer range. xdotool getmouselocation reports y up to 2159, so the pointer physically reaches the bottom row.
• User configuration. Reproduces after a full dconf reset -f. Also unaffected by autohide-dash, pressure-sense, panel-mode, and edge-distance.

Note

The ratio between the dock actor height (146.2) and the reserved strut (73) is almost exactly 2:1, which suggests a scale factor applied on one code path but not the other — though no display scaling is active on this system.