Fix X11 input barrier in the autohide-disabled case too - #356
Open
benny-png wants to merge 1 commit into
Open
Conversation
Both the dock container and the struts actor were registered into the shell's input region. The container is sized to the whole monitor, and struts spans the full monitor width whenever autohide is disabled, so on X11 a full-width band along the dock edge swallowed clicks that should have reached the window underneath. Setting affectsInputRegion:false on the container alone is not enough when autohide is disabled, because struts is not narrowed to the dock width in that configuration and keeps covering the whole edge. Register neither actor in the input region, and track the visible parts (_background and dash) instead, so the clickable area matches what is drawn. The dash is destroyed and rebuilt by recreateDash(), so its tracking is re-established through a small helper. The 2px dwell strip stays reactive so autohide reveal is unaffected. Config is no longer referenced in this file, so its import is dropped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Jul 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on #342 and #349 (both by other authors, both open) — same root cause, extended to cover the case they don't. Relates to #317 and #305.
What the existing PRs cover, and what they miss
#342 and #349 correctly identify that the dock container is registered via
addChrome()withaffectsInputRegionleft at its defaulttrue, and that this leaves a full-width band in the X11 stage input region. Their fix —affectsInputRegion: falseon the container — is right as far as it goes.Both then rely on this reasoning:
That holds only when autohide is enabled.
strutsis narrowed to the dock's width inanimator.js:With autohide disabled that branch never runs, so
struts.widthstays atdock.width— the full monitor width — whileaddToChrome()still registers it withaffectsInputRegion: true:(
Config.PACKAGE_VERSION[0] == '4'is true for all of GNOME 40–49, so this applies on every currently supported shell.)So for anyone running with autohide off, applying #342 or #349 leaves the dead band exactly as it was — the container stops covering it, and
strutscontinues to.Symptom
Dock at the bottom, autohide disabled: a full-monitor-width band along the bottom of the screen swallows clicks. Anything beneath it is unreachable — VLC's transport controls, a status bar, the last lines of a terminal. The band is noticeably taller than the visible dock, since the container is
iconSize * 2 + iconSize * (0.6 * (1 + magnify))tall.Fix
Take both actors out of the input region, and track the parts that are actually drawn:
struts→affectsInputRegion: false. It keepsaffectsStruts, so work-area reservation is unchanged; it simply stops eating clicks. This also removes theConfig.PACKAGE_VERSIONconditional, which no longer has anything to gate.affectsInputRegion: false, as in Fix invisible click barrier when dock is hidden on X11 #342/Fix X11 input barrier when dock is hidden; increase dwell strip height #349.trackChrome()on_backgroundanddashwithaffectsInputRegion: true, so the clickable region follows the visible dock in both autohide states rather than depending onstrutsgeometry.recreateDash()destroys and rebuildsthis.dash, which would silently drop the tracking and leave the dock unclickable after any settings change, so re-tracking goes through a_trackDashInput()helper called from both places.removeFromChrome()untracks.dwellstrip is left reactive — it is what reveals the dock on autohide, and it is far too small to cause the problem.untrackChrome()is safe to call on an already-destroyed actor:LayoutManager._untrackActor()returns early when the actor isn't found, and_trackActor()connectsdestroyto it, so a rebuilt dash cleans up after itself.Confighas no remaining references indock.js, so the import is dropped.Verification
Ubuntu, GNOME Shell 46.0, X11, dock at bottom, two 1920x1080 monitors with the dock's monitor at offset
+1920+413. Tested in both autohide states:autohide disabled (the case this PR adds)
recreateDash()) leaves icons still clickable.autohide enabled (the case #342/#349 target)
Not tested: Wayland, and vertical (left/right) dock positions.
Happy to rebase onto #342 or #349 if you'd rather land one of those first and take only the
strutshalf from here — this is written againstmainso it stands alone, but I don't want to step on either author's work.