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

Betterbird not minimize to tray #377

Closed
stepo1011 opened this issue Dec 1, 2024 · 46 comments
Closed

Betterbird not minimize to tray #377

stepo1011 opened this issue Dec 1, 2024 · 46 comments

Comments

@stepo1011
Copy link

Hello.
after the update to 128.5.0esr-bb18 betterbird no longer minimize to tray, instead minimize to the task bar.

Also instead of the betterbird icon it shows the wayland icon, which i could fix in renaming the desktop file name to "betterbird" in the application settings (window rules)

Operating System: CachyOS Linux
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.12.1-2-cachyos (64-bit)
Graphics Platform: Wayland

@Betterbird
Copy link
Owner

How is this installed?
FlatPak, please file an issue there.
AUR? Yes, the icon issue was fixed.

Minimise to tray on Wayland: Issue #279.

@Betterbird Betterbird closed this as not planned Won't fix, can't repro, duplicate, stale Dec 1, 2024
@stepo1011
Copy link
Author

How is this installed? FlatPak, please file an issue there. AUR? Yes, the icon issue was fixed.

Minimise to tray on Wayland: Issue #279.

installed betterbird-bin from aur.

minimize to tray was working with 115.18.0-bb36

@Betterbird
Copy link
Owner

AUR got fixed this morning, better to report their issues at their repo.

The minimise to try is a bit of a mystery since there are reports that 115 worked, or didn't work, but mostly not working on Wayland. Run the test from #279 (comment) in Firefox to see that the Mozilla platform fails to deliver the necessary event.

@stepo1011
Copy link
Author

AUR got fixed this morning, better to report their issues at their repo.

The minimise to try is a bit of a mystery since there are reports that 115 worked, or didn't work, but mostly not working on Wayland. Run the test from #279 (comment) in Firefox to see that the Mozilla platform fails to deliver the necessary event.

Thanks a lot

@Betterbird
Copy link
Owner

The original report is from here:
#111 (comment)
of February 2024, so there was no 128 back then. How is it possible that it worked for you in 115?

@stepo1011
Copy link
Author

The original report is from here: #111 (comment) of February 2024, so there was no 128 back then. How is it possible that it worked for you in 115?

just restored a snapshot before update to 128.5.0esr-bb18.

115.18.0-bb36 minimize to tray and restores from tray just fine.

115.18.0-bb36 was my last installed and working version until i updated to 128.5.0esr-bb18 last Thursday

@Betterbird
Copy link
Owner

Can you run the JS we indicated in the error console to compare?

@stepo1011
Copy link
Author

Can you run the JS we indicated in the error console to compare?

will do. keep you posted

@stepo1011
Copy link
Author

Can you run the JS we indicated in the error console to compare?

There is a sizemodechange received in 115.18.0-bb36 while in 128.5.0esr-bb18 there is not

@Betterbird
Copy link
Owner

Thanks for testing. So the million-dollar question is: Why do you get the event in 115, when all the reporters of those other tickets don't? It's even described here https://bugzilla.mozilla.org/show_bug.cgi?id=1872790#c0. OK, they tried FF 121, but apparently it already didn't work in FF 115 ESR and certainly not in BB 115.

Have you got any special settings/prefs? Maybe hardware acceleration turned off? Or asking the other way around: Can you make it fail in 115 by turning some screw?

@stepo1011
Copy link
Author

Thanks for testing. So the million-dollar question is: Why do you get the event in 115, when all the reporters of those other tickets don't? It's even described here https://bugzilla.mozilla.org/show_bug.cgi?id=1872790#c0. OK, they tried FF 121, but apparently it already didn't work in FF 115 ESR and certainly not in BB 115.

Have you got any special settings/prefs? Maybe hardware acceleration turned off? Or asking the other way around: Can you make it fail in 115 by turning some screw?

most settings are default, changed basic stuff like search engine, dictionaries, chat account offline, minimizetotray and startminimized true

funny thing is i do get a sizemodechange received in 128.5 when i restore down and back to maximize.

in 115 i can change settings all i want, it minimizes to tray no matter what.

the only difference i can think of is the window class name but i suppose this has nothing to do with it.

@Betterbird
Copy link
Owner

funny thing is i do get a sizemodechange received in 128.5 when i restore down and back to maximize.

You're saying: minimise doesn't create the event, but switching from maximised to "normal window" and back does. And switching from minimised to "normal" does what?

So maybe this observation is a starting point.

Just for your info: minimise to tray works by programmatically hiding the window on the minimise event. Hiding the window also removes the "taskbar button" (in quotes, since the nomenclature varies widely, this is actually Windows-speak).

@stepo1011
Copy link
Author

funny thing is i do get a sizemodechange received in 128.5 when i restore down and back to maximize.

You're saying: minimise doesn't create the event, but switching from maximised to "normal window" and back does. And switching from minimised to "normal" does what?

nothing...no sizemodechange received

So maybe this observation is a starting point.

Just for your info: minimise to tray works by programmatically hiding the window on the minimise event. Hiding the window also removes the "taskbar button" (in quotes, since the nomenclature varies widely, this is actually Windows-speak).

if there is anything more i can do please let me know , i´m happy to help.

i guess there will be no ongoing support for 115 anymore?

so downgrading would be no option for me?

@Betterbird
Copy link
Owner

Betterbird commented Dec 1, 2024 via email

@Betterbird
Copy link
Owner

Please run this binary from the console ./betterbird -p and report the output. When minimising on a non-Wayland system (wl=0) we get:

nsWindow::OnWindowStateEvent for 0x7f1939cadb60 changed 0x82 new_window_state 0x2
	mIsShown=1, mask now 0x82
	stuff (1): wl=0 fo=128 fo=0 sm=0 min=0
	Iconified
	Tiled: 0
	stuff (2): listen=0x7f1939970328 sm=1 old-sm=0
	calling SizeModeChanged(1)
	dispatching event 0x7f194e189718

sm=1 means that we're minimising, and you can see that the event is dispatched.

Binary: www.betterbird.eu/downloads2/betterbird-128.5.0esr-bb18-resize-debug.en-US.linux-x86_64.tar.bz2

For the record, the code has many "evil" quirks, so hopefully we can work out what it going wrong:
https://searchfox.org/mozilla-esr128/rev/dd139fc5d6c46443bb6d1e779587f8244662e876/widget/gtk/nsWindow.cpp#5286-5393

As far as I can see, it's the same in 115:
https://searchfox.org/mozilla-esr115/rev/be51e64f316775dab6e3dab5795d3b2f6112199c/widget/gtk/nsWindow.cpp#5166-5272

@Betterbird
Copy link
Owner

You've got to read some of the tickets referenced in the Mozilla code:
https://gitlab.gnome.org/GNOME/gtk/-/issues/67 - Some quotes:
Wayland does not have a concept of iconified windows.
I would suggest that we rename iconified to minimized in gtk4.
There is no minimize support in either the xdg-shell or the gtk-shell protocols; surfaces can request minimization, but ... Plus, there's no state for minimization, which means we cannot set the state on configure, like we do for maximize/fullscreen.

That's all very confusing, to the layman it sounds like they dropped support for iconified/minimised "things" in Wayland, at least for GTK3.

@stepo1011
Copy link
Author

Please run this binary from the console ./betterbird -p and report the output. When minimising on a non-Wayland system (wl=0) we get:

nsWindow::OnWindowStateEvent for 0x7f1939cadb60 changed 0x82 new_window_state 0x2
	mIsShown=1, mask now 0x82
	stuff (1): wl=0 fo=128 fo=0 sm=0 min=0
	Iconified
	Tiled: 0
	stuff (2): listen=0x7f1939970328 sm=1 old-sm=0
	calling SizeModeChanged(1)
	dispatching event 0x7f194e189718

sm=1 means that we're minimising, and you can see that the event is dispatched.

Binary: www.betterbird.eu/downloads2/betterbird-128.5.0esr-bb18-resize-debug.en-US.linux-x86_64.tar.bz2

For the record, the code has many "evil" quirks, so hopefully we can work out what it going wrong: https://searchfox.org/mozilla-esr128/rev/dd139fc5d6c46443bb6d1e779587f8244662e876/widget/gtk/nsWindow.cpp#5286-5393

As far as I can see, it's the same in 115: https://searchfox.org/mozilla-esr115/rev/be51e64f316775dab6e3dab5795d3b2f6112199c/widget/gtk/nsWindow.cpp#5166-5272

i get

nsWindow::OnWindowStateEvent for 0x7496d103fb60 changed 0x80 new_window_state 0x4
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=0 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7496ee8c1670 changed 0x80 new_window_state 0x4
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::OnWindowStateEvent for 0x7496d103fb60 changed 0x80 new_window_state 0x84
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=128 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7496ee8c1670 changed 0x80 new_window_state 0x84
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::OnWindowStateEvent for 0x7496d103fb60 changed 0x80 new_window_state 0x4
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=0 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7496ee8c1670 changed 0x80 new_window_state 0x4
quick return because IS_MOZ_CONTAINER(aWidget) is true

when i minimize from maximize

i get

nsWindow::OnWindowStateEvent for 0x7496d103fb60 changed 0x80 new_window_state 0x4
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=0 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7496ee8c1670 changed 0x80 new_window_state 0x4
quick return because IS_MOZ_CONTAINER(aWidget) is true

when i restore down from maximize

@Betterbird
Copy link
Owner

Betterbird commented Dec 1, 2024

Right, it's the early return because no interesting bits changed that kills us. Stand by for a new version. Which timezone are you in?

EDIT: Struck out incorrect statement. The issue is that new_window_state 0x2 (GDK_WINDOW_STATE_ICONIFIED) is never reported. See two comments below.

@stepo1011
Copy link
Author

Right, it's the early return because no interesting bits changed that kills us. Stand by for a new version. Which timezone are you in?

Europe/Berlin

@Betterbird
Copy link
Owner

Sorry, the previous comment wasn't right. We can't fix it. There key is here:
https://searchfox.org/mozilla-esr128/rev/dd139fc5d6c46443bb6d1e779587f8244662e876/widget/gtk/nsWindow.cpp#5356
if (aEvent->new_window_state & GDK_WINDOW_STATE_ICONIFIED) {

GDK_WINDOW_STATE_ICONIFIED has a value of 2 (https://docs.gtk.org/gdk3/flags.WindowState.html) and in our logging we got that reported, see: new_window_state 0x2. You get reported new_window_state 0x4 (maximised) or new_window_state 0x84 (focused + maximised). You also see sm=2, which is Mozilla's "size mode" maximised:
https://searchfox.org/mozilla-esr128/rev/dd139fc5d6c46443bb6d1e779587f8244662e876/widget/nsIWidgetListener.h#31

So Wayland does not report "iconified/minimised". And that was my understanding. However, you claim it works in 115. I'll make you a 115 version with debug and we'll see.

@Betterbird
Copy link
Owner

@stepo1011
Copy link
Author

Try this 115 version: www.betterbird.eu/downloads2/betterbird-115.18.0-bb36-build3-resize-debug.en-US.linux-x86_64.tar.bz2

nsWindow::OnWindowStateEvent for 0x71c3ae29a060 changed 0x80 new_window_state 0x84
mIsShown=1, mask now 0x80
stuff (1): wl=0 fo=128 fo=128 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x71c398314310 changed 0x80 new_window_state 0x84
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::OnWindowStateEvent for 0x71c3ae29a060 changed 0x82 new_window_state 0x6
mIsShown=1, mask now 0x82
stuff (1): wl=0 fo=128 fo=0 sm=2 min=0
Iconified
Tiled: 0
stuff (2): listen=0x71c398336ec8 sm=1 old-sm=2
calling SizeModeChanged(1)
dispatching event 0x71c3b0f7c7c0
nsWindow::OnWindowStateEvent for 0x71c398314310 changed 0x82 new_window_state 0x6
quick return because IS_MOZ_CONTAINER(aWidget) is true
Betterbird: Detected desktop environment kde.

nsWindow::OnWindowStateEvent for 0x71c3ae29a060 changed 0x1 new_window_state 0x7
mIsShown=0, mask now 0x1
stuff (1): wl=0 fo=0 fo=0 sm=1 min=1
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x71c398314310 changed 0x1 new_window_state 0x7
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::OnWindowStateEvent for 0x71c3ae29a060 changed 0x6 new_window_state 0x1
mIsShown=0, mask now 0x2
stuff (1): wl=0 fo=0 fo=0 sm=1 min=1
Normal
Tiled: 0
stuff (2): listen=0x71c398336ec8 sm=0 old-sm=1
calling SizeModeChanged(0)
dispatching event 0x71c3b0f7c7c0
nsWindow::OnWindowStateEvent for 0x71c398314310 changed 0x2 new_window_state 0x1
quick return because IS_MOZ_CONTAINER(aWidget) is true

minimized to tray is working

@Betterbird
Copy link
Owner

Yes, it is working, as you can see new_window_state 0x7 and new_window_state 0x6, which contains the minimise bit 0x2. You also see calling SizeModeChanged(1) which is the notification for minimise.

However, you are not running Wayland! - see wl=0. So run 115 under Wayland, and it will fail.

@stepo1011
Copy link
Author

Yes, it is working, as you can see new_window_state 0x7 and new_window_state 0x6, which contains the minimise bit 0x2. You also see calling SizeModeChanged(1) which is the notification for minimise.

However, you are not running Wayland! - see wl=0. So run 115 under Wayland, and it will fail.

Screenshot_20241201_215458

How is this even possible...

Do you have any explanation?

it minimize to tray, ans as you can see i´m running in wayland mode

@Betterbird
Copy link
Owner

Betterbird commented Dec 1, 2024

It's not running Wayland. The Mozilla code to detect Wayland hasn't changed in years, and besides, the event doesn't fire when it is really running Wayland.

Start BB with GDK_BACKEND=x11 betterbird or GDK_BACKEND=wayland betterbird or MOZ_ENABLE_WAYLAND=1 betterbird, or whatever it is to compare.

This is a bug in Linux, not even the Mozilla folks will be able to implement a workaround. For BB, Linux represents 98% of the problems and 2% of the income, which translates to a total loss 👎.

@stepo1011
Copy link
Author

It's not running Wayland. The Mozilla code to detect Wayland hasn't changed in years, and besides, the event doesn't fire when it is really running Wayland.

Start BB with GDK_BACKEND=x11 betterbird or GDK_BACKEND=wayland betterbird or MOZ_ENABLE_WAYLAND=1 betterbird, or whatever it is to compare.

This is a bug in Linux, not even the Mozilla folks will be able to implement a workaround. For BB, Linux represents 98% of the problems and 2% of the income, which translates to a total loss 👎.

You are right. starting with GDK_BACKEND=x11 minimize, starting with GDK_BACKEND=wayland does not

Thank you for pointing that out.....mystery solved

@Betterbird
Copy link
Owner

More reading:
https://discourse.gnome.org/t/how-to-see-if-a-window-is-minimised-in-gtk4-on-wayland/9280
Quote: No, there is no “minimized” state in Wayland, mostly because Wayland compositors are entitled to handle what “minimized” means.
https://gitlab.freedesktop.org/wayland/wayland/-/issues/337
https://bugs.kde.org/show_bug.cgi?id=461910
keepassxreboot/keepassxc#6502
Everyone is complaining. I was looking for a hacky workaround (like checking window size/width/height) but didn't even find that.

@Betterbird
Copy link
Owner

Try this:
www.betterbird.eu/downloads2/betterbird-128.5.0esr-bb18-resize-debug2.en-US.linux-x86_64.tar.bz2

So the hack is to fire the event when this application button is clicked:
image

It won't work if you use the system's title bar and click the system's minimise button, but it should work if you hide the system title bar and use BB's instead:
image

Please submit the debug output here. Please also test no "minimising to tray" but "minimising to taskbar".

@stepo1011
Copy link
Author

Try this: www.betterbird.eu/downloads2/betterbird-128.5.0esr-bb18-resize-debug2.en-US.linux-x86_64.tar.bz2

So the hack is to fire the event when this application button is clicked: image

It won't work if you use the system's title bar and click the system's minimise button, but it should work if you hide the system title bar and use BB's instead: image

Please submit the debug output here. Please also test no "minimising to tray" but "minimising to taskbar".

minimize to tray from fullscreen works pretty nice

nsWindow::OnWindowStateEvent for 0x7968eb937660 changed 0x80 new_window_state 0x4
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=0 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7969090c1e30 changed 0x80 new_window_state 0x4
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::OnWindowStateEvent for 0x7968eb937660 changed 0x80 new_window_state 0x84
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=128 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7969090c1e30 changed 0x80 new_window_state 0x84
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::SetSizeMode - dispatch custom
calling SizeModeChanged(1)
dispatching event 0x7968fffe0f88
nsWindow::OnWindowStateEvent for 0x7968eb937660 changed 0x80 new_window_state 0x4
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=0 sm=1 min=1
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7969090c1e30 changed 0x80 new_window_state 0x4
quick return because IS_MOZ_CONTAINER(aWidget) is true
Betterbird: Detected desktop environment kde.

nsWindow::OnWindowStateEvent for 0x7968eb937660 changed 0x1 new_window_state 0x5
mIsShown=0, mask now 0x1
stuff (1): wl=1 fo=0 fo=0 sm=1 min=1
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7969090c1e30 changed 0x1 new_window_state 0x5
quick return because IS_MOZ_CONTAINER(aWidget) is true

minimize to taskbar:

nsWindow::OnWindowStateEvent for 0x7968eb937660 changed 0x80 new_window_state 0x4
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=0 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7969090c1e30 changed 0x80 new_window_state 0x4
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::OnWindowStateEvent for 0x7968eb937660 changed 0x80 new_window_state 0x84
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=128 sm=2 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7969090c1e30 changed 0x80 new_window_state 0x84
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::SetSizeMode - dispatch custom
calling SizeModeChanged(1)
dispatching event 0x7968fffe0f88
nsWindow::OnWindowStateEvent for 0x7968eb937660 changed 0x80 new_window_state 0x4
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=0 sm=1 min=1
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x7969090c1e30 changed 0x80 new_window_state 0x4
quick return because IS_MOZ_CONTAINER(aWidget) is true

minimize to tray from "window mode" also works

nsWindow::OnWindowStateEvent for 0x786e7c7cdb60 changed 0x80 new_window_state 0x15480
mIsShown=1, mask now 0x80
stuff (1): wl=1 fo=128 fo=128 sm=0 min=0
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x786e998855f0 changed 0x80 new_window_state 0x15480
quick return because IS_MOZ_CONTAINER(aWidget) is true
nsWindow::SetSizeMode - dispatch custom
calling SizeModeChanged(1)
dispatching event 0x786e90cfc108
nsWindow::OnWindowStateEvent for 0x786e7c7cdb60 changed 0x1 new_window_state 0x15481
mIsShown=0, mask now 0x1
stuff (1): wl=1 fo=0 fo=128 sm=1 min=1
early return because no interesting bits changed
nsWindow::OnWindowStateEvent for 0x786e998855f0 changed 0x1 new_window_state 0x15481
quick return because IS_MOZ_CONTAINER(aWidget) is true

but when i restore into window mode i get:

[Parent 650495, Main Thread] WARNING: gdk_window_get_position: assertion 'GDK_IS_WINDOW (window)' failed: 'glib warning', file /home/betterbird/build128/mozilla-esr128/toolkit/xre/nsSigHandlers.cpp:187

(eu.betterbird.Betterbird:650495): Gdk-CRITICAL **: 05:45:03.067: gdk_window_get_position: assertion 'GDK_IS_WINDOW (window)' failed

leaving betterbird to not respond to any inputs

@Betterbird
Copy link
Owner

I don't understand what "window mode" is meant to mean.

Getting the window position was part of our hack attempts, so here's a version without that call that wasn't useful:
www.betterbird.eu/downloads2/betterbird-128.5.0esr-bb18-resize-debug3.en-US.linux-x86_64.tar.bz2

@stepo1011
Copy link
Author

I don't understand what "window mode" is meant to mean.

Getting the window position was part of our hack attempts, so here's a version without that call that wasn't useful: www.betterbird.eu/downloads2/betterbird-128.5.0esr-bb18-resize-debug3.en-US.linux-x86_64.tar.bz2

by window mode i mean the window has any size other then maximize/fullscreen

minimize to tray and taskbar and restore from tray and taskbar works fine as long as the size of the window is maximize

startminimized true also works

any other window size freezes when restored

@Betterbird
Copy link
Owner

There seems to exist too much confusing nomenclature. So lets settle for one set of nomenclature.

  1. Minimised, which Linux calls "iconified"
  2. Maximised: window covers the entire desktop, things like the "taskbar" are still visible.
  3. Fullscreen: Window covers the entire screen (movie mode), taskbar is also gone. I don't think BB offers that.
  4. Normal: None of the above, also called "windowed" or "restored down".

So discarding "fullscreen", we have:

  1. Maximised -> Minimised (taskbar)
  2. Maximised -> Minimised (no taskbar, tray only)
  3. Normal -> Minimised (taskbar)
  4. Normal -> Minimised (no taskbar, tray only).

And there are the reverse operations from the minimise state back to maximised or normal.

  1. Minimised (taskbar) -> Maximised
  2. Minimised (no taskbar, tray only) -> Maximised
  3. Minimised (taskbar) -> Normal
  4. Minimised (no taskbar, tray only) -> Normal.

So what works and what doesn't?

I'm not sure that I've interpreted your comments correctly. What I read is that 1-3 work, also 5-6. 7 is the normal operation, that should work, too, or maybe it doesn't since in it's current state (before we applied the tweak), there was never any minimised window since the event never arrived. So I don't know how Mozilla code will react now.

So please state the number that work. Anyway, looks like we will have to setup an environment with Wayland to develop and test on.

@stepo1011
Copy link
Author

There seems to exist too much confusing nomenclature. So lets settle for one set of nomenclature.

1. Minimised, which Linux calls "iconified"

2. Maximised: window covers the entire desktop, things like the "taskbar" are still visible.

3. Fullscreen: Window covers the entire screen (movie mode), taskbar is also gone. I don't think BB offers that.

4. Normal: None of the above, also called "windowed" or "restored down".

So discarding "fullscreen", we have:

1. Maximised -> Minimised (taskbar)

works

2. Maximised -> Minimised (no taskbar, tray only)

works

3. Normal -> Minimised (taskbar)

works

4. Normal -> Minimised (no taskbar, tray only).

works

And there are the reverse operations from the minimise state back to maximised or normal.

5. Minimised (taskbar) -> Maximised

works

6. Minimised (no taskbar, tray only) -> Maximised

work

7. Minimised (taskbar) -> Normal

8. Minimised (no taskbar, tray only) -> Normal.

it works but there are some graphical glitches and the window position is a little bit south/east to where the buttons really are
the graphical glitches dissapear when i go from restore down to maximize

Screencast_20241202_182636.mp4

So what works and what doesn't?

I'm not sure that I've interpreted your comments correctly. What I read is that 1-3 work, also 5-6. 7 is the normal operation, that should work, too, or maybe it doesn't since in it's current state (before we applied the tweak), there was never any minimised window since the event never arrived. So I don't know how Mozilla code will react now.

So please state the number that work. Anyway, looks like we will have to setup an environment with Wayland to develop and test on.

@Betterbird
Copy link
Owner

Hmm, we have more confusion now. If I read the previous paragraph correctly, all 8 cases work, but restoring from minimised to normal (cases 7. and 8.) cause graphic anomalies. Wow, gotta love Linux and Wayland!!

So the little hack that we dispatch the necessary event when the minimise button is clicked, works. I don't understand why case 7. "Minimised (taskbar) -> Normal" would be any different with or without the hack, since when you restore a window to normal that was just minised to to the tray, such effects don't happen.

Lastly, saying that all cases work contradicts previous statement: "any other window size freezes when restored".

This earlier statement "leaving betterbird to not respond to any inputs" was referring to an earlier binary, but appears to be the same as the first statement we quoted which relates to the latest build.

Please clarify.

@Betterbird
Copy link
Owner

Same build as the one you had, but with the debugging output removed:
https://www.betterbird.eu/downloads/LinuxArchive/betterbird-128.5.0esr-bb18-latest-build.en-US.linux-x86_64.tar.bz2

This is the only change we made:
https://github.com/Betterbird/thunderbird-patches/blob/main/128/bugs/1872790-send-custom-event-on-minimise.patch
That only adds code reacting to a button press on the minimise button. It's not clear way that would affect restoring the window. That appears like a separate issue, but graphic anomalies are not usually the applications fault.

I've posted the same binary to Issue #374 and Issue #279 for more feedback.

In general, what is the advantage of using Wayland given that it appears to trigger a plethora of bugs in Mozilla code, see: https://bugzilla.mozilla.org/show_bug.cgi?id=635134, there are 114 open bugs linked to this meta-bug.

@stepo1011
Copy link
Author

i try to be more precise:

case 1, 2, 3, 4, 5, 6, 7, 8 works

case 8 works with graphical glitches as shown in the video. all buttons are still functional. if i click the mouse offset as shown in the video i can maximize, minimize and close the window.
if i minimize from normal and restore to normal the graphical glitches and mouse offset remain
if i maximize from normal and restore to normal the graphical glitches and the mouse offset is gone
if i maximize from normal and minimize and restore to maximize the graphical glitches and the mouse offset is gone

Screencast_20241202_202242.mp4

this footage covers all cases

@stepo1011
Copy link
Author

Same build as the one you had, but with the debugging output removed: https://www.betterbird.eu/downloads/LinuxArchive/betterbird-128.5.0esr-bb18-latest-build.en-US.linux-x86_64.tar.bz2

still mouse offset when i restore from tray to normal

[Parent 732050, Main Thread] WARNING: gdk_window_get_position: assertion 'GDK_IS_WINDOW (window)' failed: 'glib warning', file /home/betterbird/build128/mozilla-esr128/toolkit/xre/nsSigHandlers.cpp:187

(eu.betterbird.Betterbird:732050): Gdk-CRITICAL **: 20:35:41.752: gdk_window_get_position: assertion 'GDK_IS_WINDOW (window)' failed

@Betterbird
Copy link
Owner

Thanks for the video. So all cases work, and only case 8: "Minimised (no taskbar, tray only) -> Normal" has graphic anomalies. Have you seen the shadow in your video? 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

BB code doesn't call gdk_window_get_position, but Mozilla code does:
https://searchfox.org/mozilla-esr128/search?q=gdk_window_get_position&path=&case=false&regexp=false
This call looks suspicious:
https://searchfox.org/mozilla-esr128/rev/dd139fc5d6c46443bb6d1e779587f8244662e876/widget/gtk/nsWindow.cpp#7029

So case 8. is the case where BB makes the window visible again before restoring it. And that causes the anomaly. Does the anomaly go away when moving the window, so it's redrawn?

@stepo1011
Copy link
Author

stepo1011 commented Dec 2, 2024

So case 8. is the case where BB makes the window visible again before restoring it. And that causes the anomaly. Does the anomaly go away when moving the window, so it's redrawn?

no, it does not go away when moving the window

EDITED to fix quote.

@Betterbird
Copy link
Owner

#279 (comment) states "works just fine". We're not denying the issue, however, there are so many variations in Linux, so a graphic glitch is not a surprise.

That said, here's a version that suppresses the faulty call, if we covered the code in question:
www.betterbird.eu/downloads2/betterbird-128.5.0esr-bb18-latest-build-debug-glitch.en-US.linux-x86_64.tar.bz2

Please run in the console and report the output.

@stepo1011
Copy link
Author

console output is:

nsWindow::UpdateOpaqueRegionInternal: calling EnsureGdkWindow
nsWindow::UpdateOpaqueRegionInternal: calling gdk_window_get_position

would it be possible to only allow to restore from tray to maximize?

then there would not be graphical glitches even if i restore down from maximize state afterwards

@Betterbird
Copy link
Owner

Thanks for testing. According to the console output, all is working as designed. The GDK error is not issued any more?
WARNING: gdk_window_get_position: assertion 'GDK_IS_WINDOW (window)' failed: 'glib warning'
And it still doesn't redraw properly? How about when you disable all the fancy window restore transparency transitions? Under Windows it's called "Animate windows when minimizing and maximising".

would it be possible to only allow to restore from tray to maximize?

That's not really desired since it would take away more than 50% of the use cases, I assume that most people will use a "normal" non-maximised view. We will ship this now-repaired niche feature in the next release and see how many people report errors. As I wrote, the user in the other ticket stated "works just fine".

@Betterbird
Copy link
Owner

Build updated:
https://www.betterbird.eu/downloads/LinuxArchive/betterbird-128.5.0esr-bb18-latest-build3.en-US.linux-x86_64.tar.bz2

We're not going to post further updates, just use the latest "latest".

@mfschumann
Copy link
Contributor

image

I can reproduce this behavior in the flatpak with BB 128.5.2esr-bb19 running on GNOME 47 as a native Wayland app (MOZ_ENABLE_WAYLAND = 1). When I maximize and then restore the window after the glitch has surfaced, the normal behavior is restored.

@DeN-AlB
Copy link

DeN-AlB commented Jan 16, 2025

I'm using EndeavourOS with KDE Plasma 6 and Wayland. Just wanted to come back to Betterbird and installed 128.6.0esr-bb20 from AUR.

I also got this issue. I'm not using a maximized window on my 34" monitor. After minimizing to tray and reopen Betterbird from there, I can see the same behavior shown in the video in #377 (comment).

I looked for this issue here and am a bit surprised that this issue is closed already ... Is there any fix for this behavior? Or are you on a fix for this? It would be more than great to get this fixed.

@Betterbird
Copy link
Owner

This ticket was closed since this main issue was fixed in Issue #279. We've added Issue #399 for the graphic anomalies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants