Open Bug 1881434 Opened 4 months ago Updated 2 months ago

[X11] Firefox built-in notifications give incorrect window manager hints

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 123
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: 5rgz6ni02, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files)

screenshot with one notification
413.71 KB, image/png
Details
xwininfo fragment with 1 notification open
742 bytes, text/plain
Details
screenshot with two notifications
401.74 KB, image/png
Details
xwininfo fragment with 2 notifications open
1.07 KB, text/plain
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0

Steps to reproduce:

  1. Use system-native notifications (no notification daemon reachable)
  2. Use a tiling window manager (i3)
  3. Receive a notification. (Can be tested e.g. on https://www.bennish.net/web-notifications.html)

Actual results:

The notification is shown in a new full-size window, which receives focus

Expected results:

The notification should have been shown in a small popup window not receiving focus

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Native notifications first broke in Firefox 122, causing screen corruption. This was reported as https://bugzilla.mozilla.org/show_bug.cgi?id=1876923

In Firefox 123 the corruption is gone, but notifications appear as full-size windows.

Keywords: regression
Regressed by: 1876923
Priority: -- → P3

Can you create a screenshot of the big notification window?
Thanks.

Flags: needinfo?(5rgz6ni02)

Thanks for your attention!

I moved a browser window into its own workspace and visited https://www.bennish.net/web-notifications.html

  • ff1.png shows the workspace with 1 notification open
  • xw1.txt shows the (hopefully) relevant parts of xwininfo -root -tree with 1 notification open
  • ff1.png shows the workspace with 2 notifications open
  • xw2.txt shows the (hopefully) relevant parts of xwininfo -root -tree with 2 notifications open
Flags: needinfo?(5rgz6ni02)

Thanks. Can you try to use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool

I'm interested in both breakages - when it was broken from working to non-working (it may be around Firefox 122) and from non-working to working maximized (should be around 123?)
Thanks.

Flags: needinfo?(5rgz6ni02)

needinfo acknowledged. Hadn't had time yet to try the bisect tool.

Firefox 124 has arrived. Still the same problem as in 123.

Bisecting the problem that Firefox notifications appear as full windows lead to:

34:26.51 INFO: No more integration revisions, bisection finished.
34:26.51 INFO: Last good revision: 9201220ea63a92570a01e7ccc7f28ab479a79aa5
34:26.51 INFO: First bad revision: 6a4793cef01af8c5b2a856bf004e69796d40764d
34:26.51 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9201220ea63a92570a01e7ccc7f28ab479a79aa5&tochange=6a4793cef01af8c5b2a856bf004e69796d40764d

At that point mozregression seems to hang forever, not sure what is missing / how it would have continued.

But https://hg.mozilla.org/mozilla-central/rev/6a4793cef01af8c5b2a856bf004e69796d40764d looks certainly related to the problem.

It refers to https://bugzilla.mozilla.org/show_bug.cgi?id=1869796 where you had asked:

We use this notification as a fallback is libnotify is missing (which is not expected - I have no idea why someone removes it?).

Well, I don't remove it, but I run my Firefox in a sandbox for better isolation from the rest of my machine. So it cannot access libnotify. I could probably punch a hole to give it access. But Firefox has its own implementation of notifications which have worked flawlessly before, so I have not seen a reason to punch a hole.

In version 122 I had randomly corrupted rendering of built-in notifications, similar to what has been reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1876923. Now under mozregression I did not really see that. I did not spend too much time trying to reproduce it.

I'll clear the needinfo flag. If you want me to dig deeper, please put it back.

Flags: needinfo?(5rgz6ni02)

In version 122 I had randomly corrupted rendering of built-in notifications, similar to what has been reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1876923. Now under mozregression I did not really see that. I did not spend too much time trying to reproduce it.

Not 100% true. Now I saw it again with 122. But it's not reproducible every time.

Now I think I learned how to reproduce the corrupted rendering: I need to switch between windows of different color while the notification is displayed on top of them.

Bisecting when the corruption disappeared lead to

22:47.74 INFO: Last good revision: d75adfaf9dd069655754ef9e0d6510bf16f506a0
22:47.74 INFO: First bad revision: 7f3e10bdd2af504b2affd3847c27a4ec3b8ca8a2

("good" really means corrupted, "bad" means no longer corrupted)

So if I interpret this right now (I am getting tired...) there are 3 phases:

  1. Before https://hg.mozilla.org/mozilla-central/rev/7f3e10bdd2af504b2affd3847c27a4ec3b8ca8a2: Corrupted notifications (Did not bisect when that problem started)
  2. From https://hg.mozilla.org/mozilla-central/rev/7f3e10bdd2af504b2affd3847c27a4ec3b8ca8a2 to before https://hg.mozilla.org/mozilla-central/rev/6a4793cef01af8c5b2a856bf004e69796d40764d: Works correctly.
  3. From: https://hg.mozilla.org/mozilla-central/rev/6a4793cef01af8c5b2a856bf004e69796d40764d: Full size notifications

I did more bisecting to find out when the notification corruption was introduced (between 121 and 122)

29:01.48 INFO: No more integration revisions, bisection finished.
29:01.48 INFO: Last good revision: 5f6fad561a65b0f9103350cccffd4fec374b214c
29:01.48 INFO: First bad revision: 2c0e51ad033428fa026ec754cccd91c9ae4f2a26

The first bad revision is only an valgrind ignorelist. But there are several of its parents that seem clearly related (my understanding is not good enough to even guess which one).

So to extend my list from yesterday

  1. Before https://hg.mozilla.org/mozilla-central/rev/64a25a56cdf15e08fc65889bdd9a9bc02bdf90ae: no problem (released as 121)
  2. After https://hg.mozilla.org/mozilla-central/rev/b1c214141e4b3336efe46bd18a4df8381b7d924d (could also be a bit earlier) until before https://hg.mozilla.org/mozilla-central/rev/7f3e10bdd2af504b2affd3847c27a4ec3b8ca8a2: Corrupted notifications (released as 122)
  3. From https://hg.mozilla.org/mozilla-central/rev/7f3e10bdd2af504b2affd3847c27a4ec3b8ca8a2 to before https://hg.mozilla.org/mozilla-central/rev/6a4793cef01af8c5b2a856bf004e69796d40764d: Works correctly. (Copied from yesterday, not retested) (fell between 122 and 123)
  4. From: https://hg.mozilla.org/mozilla-central/rev/6a4793cef01af8c5b2a856bf004e69796d40764d: Full size notifications (Copied from yesterday, not retested) (released as 123 and 124)

We use this notification as a fallback is libnotify is missing (which is not expected - I have no idea why someone removes it?).

Well, I don't remove it, but I run my Firefox in a sandbox for better isolation from the rest of my machine.

To avoid any misunderstanding: While I use a sandbox in daily usage and noticed the problem there, the problem is fully reproducible without it.
I did all bisecting without a sandbox, I just toggle alerts.useSystemBackend under about:config.

Now I captured the window properties using xprop. Maybe that helps to understand what has changed.

I use the same numbering is in the grandparent comment.

  1. Originally it was window type utility
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x1c00001
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
WM_WINDOW_ROLE(STRING) = "alert"
XdndAware(ATOM) = BITMAP
_NET_WM_OPAQUE_REGION(CARDINAL) = 
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 29360297, 29360298
_NET_WM_USER_TIME(CARDINAL) = 1042002632
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1c000a8
WM_CLIENT_LEADER(WINDOW): window id # 0x1c00001
_NET_WM_PID(CARDINAL) = 957473
WM_LOCALE_NAME(STRING) = "en_GB.UTF-8"
WM_CLIENT_MACHINE(STRING) = "uwe-x1c7"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		program specified minimum size: 0 by 0
		program specified maximum size: 16384 by 16384
		program specified base size: 0 by 0
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Alert", "firefox-nightly"
WM_ICON_NAME(STRING) = 
_NET_WM_ICON_NAME(UTF8_STRING) = 
WM_NAME(STRING) = 
_NET_WM_NAME(UTF8_STRING) =
  1. I don't see any significant changes during the corruption phase
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x1c00001
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
WM_WINDOW_ROLE(STRING) = "alert"
XdndAware(ATOM) = BITMAP
_NET_WM_OPAQUE_REGION(CARDINAL) = 
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 29360282, 29360283
_NET_WM_USER_TIME(CARDINAL) = 1042270636
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1c00099
WM_CLIENT_LEADER(WINDOW): window id # 0x1c00001
_NET_WM_PID(CARDINAL) = 958264
WM_LOCALE_NAME(STRING) = "en_GB.UTF-8"
WM_CLIENT_MACHINE(STRING) = "uwe-x1c7"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		program specified minimum size: 0 by 0
		program specified maximum size: 16384 by 16384
		program specified base size: 0 by 0
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Alert", "firefox-nightly"
WM_ICON_NAME(STRING) = 
_NET_WM_ICON_NAME(UTF8_STRING) = 
WM_NAME(STRING) = 
_NET_WM_NAME(UTF8_STRING) =
  1. In the unreleased phase where it seemed to work again it was a window type dialog. My window manager i3 noted that it should be floating window so it appeared correctly. Because I have not really used that version there could be problems I did not notice in my quick testing during bisecting.
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_STATE(ATOM) = 
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
I3_FLOATING_WINDOW(CARDINAL) = 1
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x1c000e1
		bitmap id # of mask for icon: 0x1c000e7
		window id # of group leader: 0x1c00001
_GTK_THEME_VARIANT(UTF8_STRING) = 
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
WM_WINDOW_ROLE(STRING) = "alert"
XdndAware(ATOM) = BITMAP
_NET_WM_ICON(CARDINAL) = 	Icon (128 x 128):
	Icon (32 x 32):
	Icon (48 x 48):
	Icon (16 x 16):
(icons redacted)
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 29360351, 29360352
_NET_WM_USER_TIME(CARDINAL) = 1045848880
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1c000de
WM_CLIENT_LEADER(WINDOW): window id # 0x1c00001
_NET_WM_PID(CARDINAL) = 962910
WM_LOCALE_NAME(STRING) = "en_GB.UTF-8"
WM_CLIENT_MACHINE(STRING) = "uwe-x1c7"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		program specified minimum size: 0 by 0
		program specified maximum size: 16384 by 16384
		program specified base size: 0 by 0
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Alert", "firefox-nightly"
WM_ICON_NAME(STRING) = 
_NET_WM_ICON_NAME(UTF8_STRING) = 
WM_NAME(STRING) = 
_NET_WM_NAME(UTF8_STRING) =
  1. With the big windows it is a type notification as coded in https://hg.mozilla.org/mozilla-central/rev/6a4793cef01af8c5b2a856bf004e69796d40764d, but i3 does not understand how to present that.
_NET_WM_DESKTOP(CARDINAL) = 4
_NET_WM_STATE(ATOM) = 
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x1c00001
_GTK_THEME_VARIANT(UTF8_STRING) = 
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
WM_WINDOW_ROLE(STRING) = "alert"
XdndAware(ATOM) = BITMAP
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NOTIFICATION
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 29360471, 29360472
_NET_WM_USER_TIME(CARDINAL) = 1046772495
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1c00156
WM_CLIENT_LEADER(WINDOW): window id # 0x1c00001
_NET_WM_PID(CARDINAL) = 963459
WM_LOCALE_NAME(STRING) = "en_GB.UTF-8"
WM_CLIENT_MACHINE(STRING) = "uwe-x1c7"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		program specified minimum size: 0 by 0
		program specified maximum size: 16384 by 16384
		program specified base size: 0 by 0
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Alert", "firefox-nightly"
WM_ICON_NAME(STRING) = 
_NET_WM_ICON_NAME(UTF8_STRING) = 
WM_NAME(STRING) = 
_NET_WM_NAME(UTF8_STRING) =

In summary:

  • Originally it was of type utility and worked
  • Then it changed to dialog and seemed to work at least at a first glimpse
  • In releases 123 and 124 it is a notification and my windows manager cannot handle correctly
Regressed by: 1869796
No longer regressed by: 1876923
See Also: → 1876923, 1864382
See Also: → 1870512, 1869891

Linked all bugs mentioned in the change sets and one potential duplicate as "See also". The last one that causes the big windows as "Regressed by".

:emilio, since you are the author of the regressor, bug 1869796, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(emilio)

In releases 123 and 124 it is a notification and my windows manager cannot handle correctly

I mean, I guess we can go back to utility, but notification seems like the right role for... notifications? Can you check with your WM maintainers?

Note that there's also a further related change in bug 1882033. Does nightly work?

Flags: needinfo?(emilio) → needinfo?(5rgz6ni02)

Tested mozregression --launch 2024-03-22. Still big windows for built-in notifications.

I don't know what is the the difference between utility and notification. I agree notification sounds better, but we should find the documentation or source (of what?).

Using notification alone does not seem to be the root cause that it is broken now. If I use the notification system of my desktop xprop shows

_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		Initial state is Normal State.
		window id # of group leader: 0x1a00001
_GTK_THEME_VARIANT(UTF8_STRING) = 
XdndAware(ATOM) = BITMAP
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NOTIFICATION
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 27263049, 27263050
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1a00048
WM_CLIENT_LEADER(WINDOW): window id # 0x1a00001
_NET_WM_PID(CARDINAL) = 660522
WM_LOCALE_NAME(STRING) = "en_GB.UTF-8"
WM_CLIENT_MACHINE(STRING) = "uwe-x1c7"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		program specified minimum size: 614 by 168
		program specified maximum size: 614 by 168
		program specified base size: 0 by 0
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "xfce4-notifyd", "Xfce4-notifyd"
WM_ICON_NAME(STRING) = "xfce4-notifyd"
_NET_WM_ICON_NAME(UTF8_STRING) = "xfce4-notifyd"
WM_NAME(STRING) = "xfce4-notifyd"
_NET_WM_NAME(UTF8_STRING) = "xfce4-notifyd"

So xfce4-notifyd uses window type notification and gets displayed correctly. It must be some other property/setting that causes the problem.

I can see that xfce4-notifyd seems to specify an exact size (at least I conclude so from min size equal to max size). Whether that's the only / best way to do it I have no clue. Could also be unnecessary, when it was type utility or dialog it still worked correctly without such size limits.

i3 works with many programs and has worked with Firefox before. So I would not immediately suspect a window manager bug. But of course everything is possible in software...

Clearing needinfo, please set it again if you want me to test something else.

Flags: needinfo?(5rgz6ni02)

Can you check with your WM maintainers?

I feared i3 might be no longer very active because the world is moving to Wayland (in a tight race with IPv6...). But I was wrong, they seem to have pretty active channels. Let's see whether I get answers there. I'll keep you posted.

I agree notification sounds better, but we should find the documentation or source (of what?).

This seems applicable: https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html

At a first glimpse I don't see what is wrong. However, it sounds like _NET_WM_STATE_ABOVE might be useful. The xprop listings above show that xfce-notifyd uses it, but Firefox never has. So at least with type utility that was not mandatory to get the right behavior. No idea whether that could be different for type notification.

Can you check with your WM maintainers?

No explanation found with those active on IRC. Trying their forum.

Can you check with your WM maintainers?

No explanation found with those active on IRC. Trying their forum.

A work-around by explicit WM configuration has been mentioned. But I'd maintain not every user should have to do that. No clarity yet whether the problem is on WM side or Firefox side.

Yeah, I agree. If there's a reason why utility is a more appropriate hint than notification, or something else to fix on our side, I'm happy to write or review a patch. Btw this probably doesn't come up as often because we try to use libnotify by default, so on most WMs that code isn't even exercised

this probably doesn't come up as often

I agree, many users would use libnotify, even i3 users. But as long as Firefox has a native implementation it should also work without the user being an expert in window managers.

Let's hope for a more thorough explanation by the WM maintainers.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: