Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wayland: Graphic anomalies after windows is restored after being hidden when minimizing to tray #399

Open
Betterbird opened this issue Jan 16, 2025 · 16 comments
Labels
help wanted Extra attention is needed Upstream problems

Comments

@Betterbird
Copy link
Owner

This has been carried forward from #377 (comment) (quoting):

"Minimised (no taskbar, tray only) -> Normal" has graphic anomalies. [...] The buttons actually respond to the shadow position, not the final position, I've drawn a red rectangle where the shadow controls would be:

Image

@DeN-AlB
Copy link

DeN-AlB commented Jan 16, 2025

Thanks for opening this new issue! Looking forward to a fix. 😉

@Betterbird
Copy link
Owner Author

We're not working on it. Wayland in Mozilla is riddled with bugs. How should we debug some anomalies when unhiding a window? It's got nothing to do with (mail) application code.

The only solution we could think of would be to reproduce something similar in Firefox and report it to Mozilla. The TB folks implemented system tray support independently. They will still need to implement "minimise to tray" (https://bugzilla.mozilla.org/show_bug.cgi?id=1627479), so then they will run into the same issue.

@DeN-AlB
Copy link

DeN-AlB commented Jan 16, 2025

Ok. Then we have to wait ... Thanks anyway. 😢

@Betterbird
Copy link
Owner Author

What happens if you grab the window by its phantom title bar and move it. Does everything become good? If so, we might move the windows left or right by a pixel programmatically to see whether this workaround fixes the issue. Kludge upon kludge upon kludge 😢

@DeN-AlB
Copy link

DeN-AlB commented Jan 17, 2025

Just tried grabbing the phantom title bar. When moving, both windows were moved together. The phantom edges stay there. They don't change their size.

But it was a good idea.

I'm using Linux since 1,5 years. I was using Gnome and KDE Plasma. I always enabled Wayland. Never used X11. When using Betterbird some months ago, it worked, and it worked in Wayland. I didn't have such an issue. Was the problem introduced with a newer version of Betterbird? Strange ... 🤔

@Betterbird
Copy link
Owner Author

No it wasn't. BB 115 always ran in X11 mode, even on Wayland. We've debugged this in detail:
#377 (comment)
#377 (comment)
#377 (comment)
#377 (comment)
#377 (comment)

We had a 115 debug version that printed "wl=0" even when supposedly run under Wayland.

You can get 128 to work by running GDK_BACKEND=x11.

So repeating: 115 always ran in X11, whether Wayland was set or not. 128 runs in X11 or Wayland, and the latter malfunctions.

@DeN-AlB
Copy link

DeN-AlB commented Jan 17, 2025

Ok. Thanks for explaining again. I didn't get that from the first reading.

So GDK_BACKEND=x11 betterbird should work ... How should I implement this, to start Betterbird in X11 mode?

@Betterbird
Copy link
Owner Author

You're asking how to use Linux?

Just tried grabbing the phantom title bar. When moving, both windows were moved together. The phantom edges stay there. They don't change their size.

This is unclear. There is only one window which has some shadow artifact. That artifact stays where is was in absolute coordinates, or it moves with the window but stays fixed relative to the window that is moved, which is what "moved together" implies?

If you can't describe it, please submit a video. Or maybe the original reporter @stepo1011 can.

Seriously, a windowing system that doesn't implement gtk_widget_show() correctly, isn't really of much use:
https://searchfox.org/mozilla-central/rev/2966caf8129d1a0d6a382b5d851456169f1081f8/widget/gtk/nsWindow.cpp#6640
https://searchfox.org/mozilla-central/rev/2966caf8129d1a0d6a382b5d851456169f1081f8/widget/gtk/nsWindow.cpp#1256
Maybe some Mozilla glue code has gone wrong, but in the end it seems to come down to gtk_widget_show().

As I mentioned in the other tickets, can you not switch off all the animation hoo-hah that seems to go wrong?

@DeN-AlB
Copy link

DeN-AlB commented Jan 18, 2025

Hallo Jörg, ich antworte einfach mal in Deutsch, da ich kein perfektes Englisch spreche und schreibe und dann etwas falsch rüberkommen könnte, wie wohl hier geschehen.

You're asking how to use Linux?

Tatsächlich tue ich das. Nur weil ich Linux nutze, heißt es nicht, dass ich jeden Winkel des Betriebssystems und jeden Parameter kenne, mit dessen Hilfe ich eine Anwendung starten kann.
Ich zähle mich zwar nicht mehr zu den blutigen Anfängern, behaupte aber auch nicht, dass ich ein Linux-Profi bin. Nach 30 Jahren Windows wage ich zu behaupten, dass ich auch in Windows nicht jedes Detail kenne.
Aber seitdem ich Linux nutze, habe ich gelernt, mich selbst schlau zu machen und das würde ich diesbezüglich nun auch machen. Danke trotzdem.

This is unclear. There is only one window which has some shadow artifact. That artifact stays where is was in absolute coordinates, or it moves with the window but stays fixed relative to the window that is moved, which is what "moved together" implies?

Zuerst mal ist es schwer, diese "Phantom-Titelleiste" zu fassen zubekommen. Denn versucht man es, landet man immer auf den Buttons oben rechts, um das Fenster zu minimieren, maximieren oder zu schließen. Schafft man es doch, verschiebt man das Fenster zusammen mit dem "Phantom-Rahmen". Bedeutet, der Rahmen bleibt beim Verschieben erhalten und verschiebt sich mit.

As I mentioned in the other tickets, can you not switch off all the animation hoo-hah that seems to go wrong?

Ich habe in KDE Plasma diesbezüglich nie Einstellungen geändert. Werde mir diese aber mal genauer anschauen. Ggf. sind hier standardmäßig tatsächlich optische Anpassungen aktiviert, die ich deaktivieren kann. Und dann schaue ich, ob eine Änderung Auswirkungen auf den Fehler hat.

@Betterbird
Copy link
Owner Author

I think the GitHub language is English, for others to participate.

As for Linux: Somehow you need to set the variable in the environment before you start BB. So on the command line you just put:
GDK_BACKEND=x11 betterbird. Or you need to create a script to start BB including this. Or stick it into whichever script that runs at logon, that depends on the shell you use, with bash, it's .bash_profile (at least for me). If you're using a .desktop file, maybe it can go into there. If in doubt, ask ChatGTP.

OK, so the artifact is glued to the window. As for the KDE setting, you need to explore that. On Windows we have:
Image

I looked at the code. The window is made visible, basically using the "system call" gtk_widget_show() and then it's moved to the previous position, also using "system calls". I'll make two versions, one without moving the window at all and the second one using Mozilla calls to move the windows, you can try both to see whether it makes a difference. I'll find some time for it in the next 48 hours.

@Betterbird
Copy link
Owner Author

Try these two:
Not moving window:
http://www.betterbird.eu/downloads2/betterbird-128.6.0esr-bb20-no-move.en-US.linux-x86_64.tar.bz2
Moving window with Mozilla function:
http://www.betterbird.eu/downloads2/betterbird-128.6.0esr-bb20-moz-move.en-US.linux-x86_64.tar.bz2

Please describe what happens. I guess, with the first binary, the window will be restored to some "default" location, with the second binary, it may be moved to the original location, with or without artifacts.

@Betterbird
Copy link
Owner Author

@mfschumann, can you please try these binaries as well.

@mfschumann
Copy link
Contributor

I've tested the two binaries with MOZ_ENABLE_WAYLAND=1 set (i.e. running as native Wayland app) under Gnome. Both "no-move" and "moz-move" behave identical to the normal version (e.g. the current flatpak): The window is always restored to a location different from its original location and it shows the glitch.

@Betterbird
Copy link
Owner Author

Then I give up. The issue doesn't lie in moving the window to the original location, but rather in the gtk_widget_show() call which makes the hidden window visible again.

Can you try disabling the animation? Sorry, if you've answered this before.

@mfschumann
Copy link
Contributor

mfschumann commented Jan 18, 2025

I've disabled animations in Gnome using the "Just Perfection" Gnome Shell extension. When doing that, windows did not fly in or out anymore, but the glitch was still there.

@Betterbird
Copy link
Owner Author

Here's an experiment I want you to run in Firefox(!!):

  1. Start Firefox under Wayland
  2. Open the error console (Ctrl+Shift+J)
  3. Paste this content: let s = Services.wm.getMostRecentBrowserWindow();
  4. Paste: s.docShell.treeOwner.QueryInterface(Ci.nsIBaseWindow).visibility = false;
  5. Paste: s.docShell.treeOwner.QueryInterface(Ci.nsIBaseWindow).visibility = true;

Report what you see.

If you see artefacts for FF, report a bug at https://bugzilla.mozilla.org/home for Firefox with summary: "Graphic anomalies after restoring an invisible window with 'nsIBaseWindow.visibility' under Wayland". Paste the steps 1.-5. into the bug description.

If you don't see artifacts in Firefox, repeat the experiment with Thunderbird, then with Betterbird.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed Upstream problems
Projects
None yet
Development

No branches or pull requests

3 participants