diff --git a/docs/changelog.md b/docs/changelog.md index 2cabcf2..ae9ad33 100644 --- a/docs/changelog.md +++ b/docs/changelog.md @@ -5,6 +5,14 @@ SPDX-License-Identifier: CC-BY-4.0 # Changelog of the Burn-My-Windows Extension +## [Burn My Windows 32](https://github.com/schneegans/Burn-My-Windows/releases/tag/v32) + +**Release Date:** TBD + +#### Bug Fixes + +* Fixed an issue which caused corrupted windows on X11 GNOME 44 under very specific circumstances. This happened only on X11 and only when the window was resized before it was actually shown. + ## [Burn My Windows 31](https://github.com/schneegans/Burn-My-Windows/releases/tag/v31) **Release Date:** 2023-05-04 diff --git a/extension.js b/extension.js index 8608fe5..2f3fc96 100644 --- a/extension.js +++ b/extension.js @@ -146,16 +146,16 @@ class Extension { // If a window is created, the transitions are set up in the async _mapWindow() of the // WindowManager: - // https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/windowManager.js#L1487 + // https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/windowManager.js#L1436 // AFAIK, overriding this method is not possible as it's called by a signal to which // it is bound via the bind() method. To tweak the async transition anyways, we // override the actors ease() method once. We do this in _shouldAnimateActor() which // is called right before the ease() in _mapWindow: - // https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/windowManager.js#L1472 + // https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/windowManager.js#L1465 // The same trick is done for the window-close animation. This is set up in a similar // fashion in the WindowManager's _destroyWindow(): - // https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/windowManager.js#L1558. + // https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/windowManager.js#L1525 // Here is _shouldAnimateActor() also called right before. So we use it again to // monkey-patch the window actor's ease() once. @@ -164,7 +164,6 @@ class Extension { // there. To enable animations in the overview, we check inside the method whether it // was called by either _mapWindow or _destroyWindow. If so, we return true. Let's see // if this breaks stuff left and right... - // https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/ui/windowManager.js#L1120 Main.wm._shouldAnimateActor = function(actor, types) { const stack = (new Error()).stack; const forClosing = stack.includes('_destroyWindow@'); @@ -184,12 +183,30 @@ class Extension { // Now intercept the next call to actor.ease(). actor.ease = function(...params) { - // Quickly restore the original behavior. Nobody noticed, I guess :D - actor.ease = orig; + // There is a really weird issue in GNOME Shell 44: A few non-GTK windows are + // resized directly after they are mapped on X11. This happens for instance + // for keepassxc after it was closed in the maximized state. As the + // _mapWindow() method is called asynchronously, the window is not yet visible + // when the resize happens. Hence, our ease-override is called for the resize + // animation instead of the window-open or window-close animation. This is not + // what we want. So we check again whether the ease() call is for the + // window-open or window-close animation. If not, we just call the original + // ease() method. See also: + // https://github.com/Schneegans/Burn-My-Windows/issues/335 + const stack = (new Error()).stack; + const forClosing = stack.includes('_destroyWindow@'); + const forOpening = stack.includes('_mapWindow@'); - // And then create the effect! - extensionThis._setupEffect(actor, forOpening, chosenEffect.effect, - chosenEffect.profile); + if (forClosing || forOpening) { + // Quickly restore the original behavior. Nobody noticed, I guess :D + actor.ease = orig; + + // And then create the effect! + extensionThis._setupEffect(actor, forOpening, chosenEffect.effect, + chosenEffect.profile); + } else { + orig.apply(this, params); + } }; return true;