Fix invisible click barrier when dock is hidden on X11

[Johnathan94]

Fixes #317

Symptom

With autohide enabled on X11, clicks in the bottom band of the screen (roughly the dock's height, full monitor width) never reach the application window underneath while the dock is hidden — e.g. the VS Code status bar or a terminal's last lines become unclickable.

Root cause

The dock container (dashtodockContainer) is a chrome actor sized to the full monitor width and the dock's height, and it keeps that size when the dock slides out — only the inner dash is translated off-screen and struts is hidden. Because the container is registered via Main.layoutManager.addChrome() with affectsInputRegion left at its default (true), its whole rect stays in the shell's X11 stage input region permanently. Clicks landing there are delivered to the shell stage (where nothing reactive remains once the dash slides away) instead of the window below.

Wayland ignores the stage input region, which is why this only reproduces on X11.

Fix

Register the container with affectsInputRegion: false (the line was already present, commented out). Input for the visible dock is already carried by the struts actor (which is explicitly input-region-tracked and hidden together with the dock), and the 2px dwell strip still reveals the dock at the screen edge.

Verification

On Ubuntu 24.04, GNOME Shell 46, X11, extension v92, dock at bottom, autohide + dodge enabled:

• Before: synthetic clicks (xdotool) into an xev window placed in the bottom zone were swallowed — 0 ButtonPress events received for any click within ~190px of the bottom edge; clicks above that boundary passed. The boundary matches the container height (iconSize*2 + iconSize*0.6*(1+magnify)).
• After: the same clicks at the same coordinates all arrive (2/2 ButtonPress). The dock still reveals via the edge dwell strip, icons stay clickable, and hiding/dodging behaves as before.

[benny-png]

Heads up on one edge case, since I hit this same bug and landed on your diagnosis independently — the container/affectsInputRegion analysis here matches what I found.

The one gap: this fix relies on struts carrying the input region for the visible dock, which is true when autohide is enabled, because animator.js narrows it there:

if (dock.extension.autohide_dash) {
  dock.struts.x = dock._background.x + dock._monitor.x;
  dock.struts.width = dock._background.width;
}

With autohide disabled that branch never runs, struts.width stays at dock.width (full monitor width), and addToChrome() still registers it with affectsInputRegion: true. So for that configuration the dead band survives this change — the container stops covering it and struts keeps covering it.

I've opened #356 with the struts half plus trackChrome() on the visible actors, verified in both autohide states. It's written against main rather than on top of this, so it stands alone — but I'd rather not step on your work, and I'm happy to close mine in favour of you extending this one if you'd prefer. Entirely up to you and the maintainer.