[GH-ISSUE #5817] firefox: browser notifications do not appear in KDE notifications

gitea-mirror commented

2026-05-05 09:44:16 -06:00

Owner

Originally created by @mYnDstrEAm on GitHub (May 4, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5817

Description

I'm using Debian11 with KDE.

When one configures "Do not disturb" in KDE's notification settings in the plasma panel, notifications from the browser can still pop up on the screen, including on the desktop.

Other notification settings are also rendered ineffective, for example timeouts for the popups and so on. They also look different than all the other notifications (inconsistent) and are at another place of the screen (upper right instead of bottom right).

This also is a privacy and security issue because if you expect them to be hidden, they could display unwanted info to others who see your screen (locally or during presentations for example).

Described it here before here I noticed it's a firejail issue.

Steps to Reproduce

Steps to reproduce the behavior

firejail-esr with its firejail profile on Debian 11 with KDE
Go to https://cleverpush.com/en/test-notifications/
Click on "New Products" to get notifications (or send yourself an email with browser notifications enabled for mails)
(Enable do not disturb)

Expected behavior

It should display the browser notifications as KDE notifications (and depending on KDE notification settings) and they should be hidden when Do not disturb is enabled.

Actual behavior

It does display the browser notifications not as KDE notifications and they aren't hidden when Do not disturb is enabled.

Behavior without a profile

Without firejail the notifications display fine.

Additional context

Environment

Linux distribution and version: Debian 11
Firejail version: 0.9.72

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local).
The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
The profile (and redirect profile if exists) hasn't already been fixed upstream.
I have performed a short search for similar issues (to avoid opening a duplicate).
- I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Log

Output of LC_ALL=C firejail /path/to/program

output goes here

Output of LC_ALL=C firejail --debug /path/to/program

output goes here

Originally created by @mYnDstrEAm on GitHub (May 4, 2023). Original GitHub issue: https://github.com/netblue30/firejail/issues/5817  ### Description I'm using Debian11 with KDE. When one configures "Do not disturb" in KDE's notification settings in the plasma panel, notifications from the browser can still pop up on the screen, including on the desktop. Other notification settings are also rendered ineffective, for example timeouts for the popups and so on. They also look different than all the other notifications (inconsistent) and are at another place of the screen (upper right instead of bottom right). This also is a privacy and security issue because if you expect them to be hidden, they could display unwanted info to others who see your screen (locally or during presentations for example). Described it [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1785822) before here I noticed it's a firejail issue. ### Steps to Reproduce _Steps to reproduce the behavior_ 1. firejail-esr with its firejail profile on Debian 11 with KDE 2. Go to https://cleverpush.com/en/test-notifications/ 3. Click on "New Products" to get notifications (or send yourself an email with browser notifications enabled for mails) 4. (Enable do not disturb) ### Expected behavior It should display the browser notifications as KDE notifications (and depending on KDE notification settings) and they should be hidden when Do not disturb is enabled. ### Actual behavior It does display the browser notifications not as KDE notifications and they aren't hidden when Do not disturb is enabled. ### Behavior without a profile Without firejail the notifications display fine. ### Additional context ### Environment - Linux distribution and version: Debian 11 - Firejail version: 0.9.72 ### Checklist  - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - [x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). - [ ] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. - [x] I used `--profile=PROFILENAME` to set the right profile. (Only relevant for AppImages) ### Log <details> <summary>Output of <code>LC_ALL=C firejail /path/to/program</code></summary> <p> ``` output goes here ``` </p> </details> <details> <summary>Output of <code>LC_ALL=C firejail --debug /path/to/program</code></summary> <p>  ``` output goes here ``` </p> </details>

gitea-mirror

2026-05-05 09:44:16 -06:00

closed this issue
added the
duplicate
label

gitea-mirror commented

2026-05-05 09:44:20 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 4, 2023):

a2c8a5f03c/etc/profile-a-l/firefox.profile (L57-L58)

@rusty-snake commented on GitHub (May 4, 2023): https://github.com/netblue30/firejail/blob/a2c8a5f03ce4ef52c514dd3b60458474844ec4f2/etc/profile-a-l/firefox.profile#L57-L58

gitea-mirror commented

2026-05-05 09:44:21 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 4, 2023):

Duplicated of #3465 and some other I guess.

@rusty-snake commented on GitHub (May 4, 2023): Duplicated of #3465 and some other I guess.

gitea-mirror commented

2026-05-05 09:44:21 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (May 4, 2023):

a2c8a5f03c/etc/profile-a-l/firefox.profile (L57-L58)

Thanks. However, a commented-out line in some profile file is not a solution. It should be uncommented by default or be used depending on some conditions (like whether it detected that KDE is used).

At a minimum, the user needs to be made aware of this setting, for example by showing a prompt (if KDE is detected or for all users) after installation/package-upgrade like "Should notifications displays as KDE's native notifications? [yes] [no]".

@mYnDstrEAm commented on GitHub (May 4, 2023): > https://github.com/netblue30/firejail/blob/a2c8a5f03ce4ef52c514dd3b60458474844ec4f2/etc/profile-a-l/firefox.profile#L57-L58 Thanks. However, a commented-out line in some profile file is not a solution. It should be uncommented by default or be used depending on some conditions (like whether it detected that KDE is used). At a minimum, the user needs to be made aware of this setting, for example by showing a prompt (if KDE is detected or for all users) after installation/package-upgrade like "Should notifications displays as KDE's native notifications? [yes] [no]".

gitea-mirror commented

2026-05-05 09:44:22 -06:00

Author

Owner

@ghost commented on GitHub (May 4, 2023):

At a minimum, the user needs to be made aware of this setting, for example by showing a prompt (if KDE is detected or for all users) after installation/package-upgrade like "Should notifications displays as KDE's native notifications? [yes] [no]".

Implementing such desktop-aware conditionals would indeed be beneficial from a UX perspective. Probably even better when it could happen at runtime. Installing KDE (or any other DE) does not imply it is actively being used.

@ghost commented on GitHub (May 4, 2023): > At a minimum, the user needs to be made aware of this setting, for example by showing a prompt (if KDE is detected or for all users) after installation/package-upgrade like "Should notifications displays as KDE's native notifications? [yes] [no]". Implementing such `desktop-aware conditionals` would indeed be beneficial from a UX perspective. Probably even better when it could happen at `runtime`. Installing KDE (or any other DE) does not imply it is actively being used.

gitea-mirror commented

2026-05-05 09:44:23 -06:00

Author

Owner

@kmk3 commented on GitHub (May 4, 2023):

@mYnDstrEAm on May 4:

Thanks. However, a commented-out line in some profile file is not a solution.
It should be uncommented by default or be used depending on some conditions
(like whether it detected that KDE is used).

It is commented because it's apparently very unsafe, as explained in #3465.

At a minimum, the user needs to be made aware of this setting, for example by
showing a prompt (if KDE is detected or for all users) after
installation/package-upgrade like "Should notifications displays as KDE's
native notifications? [yes] [no]".

Maybe there could be a toggle for desktop notifications in firejail.config
similar to allow-tray.

But note that such a tradeoff applies to many other profiles as well, so it is
more scalable to add customizations as needed than to create and maintain
dozens or hundreds of prompts.

Also, note that everyone has a different security/convenience tradeoff
preference and the profiles cannot possibly match all of them at the same time;
users are expected to read, understand and tune the profiles to their needs.

@kmk3 commented on GitHub (May 4, 2023): @mYnDstrEAm [on May 4](https://github.com/netblue30/firejail/issues/5817#issuecomment-1534878680): > Thanks. However, a commented-out line in some profile file is not a solution. > It should be uncommented by default or be used depending on some conditions > (like whether it detected that KDE is used). It is commented because it's apparently very unsafe, as explained in #3465. > At a minimum, the user needs to be made aware of this setting, for example by > showing a prompt (if KDE is detected or for all users) after > installation/package-upgrade like "Should notifications displays as KDE's > native notifications? [yes] [no]". Maybe there could be a toggle for desktop notifications in firejail.config similar to `allow-tray`. But note that such a tradeoff applies to many other profiles as well, so it is more scalable to add customizations as needed than to create and maintain dozens or hundreds of prompts. Also, note that everyone has a different security/convenience tradeoff preference and the profiles cannot possibly match all of them at the same time; users are expected to read, understand and tune the profiles to their needs.

gitea-mirror commented

2026-05-05 09:44:23 -06:00

Author

Owner

@kmk3 commented on GitHub (May 4, 2023):

(Closing as a duplicate of #3465)

@kmk3 commented on GitHub (May 4, 2023): (Closing as a duplicate of #3465)

gitea-mirror commented

2026-05-05 09:44:24 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (May 4, 2023):

Why is this and/or the other issue closed as completed when the decision seems to be

I think the best - if technically possible - to fix this WITHOUT break security or weakening the power of sandbox & make the fix built-in & user need nothing to do from heir/his side at all. Otherwise, the fix seem to me to penetrate the sandbox & this is bad ...

...and it's not fixed? I don't think it should be closed before either:

it's fixed without decreasing security / the sandboxing (as called for in the issue's last comment) or
the problem or an alternative is identified and an issue is opened elsewhere accordingly if a change to other software is required - such as an issue at the DBUS repo or the KDE repo that is then linked from here

Also the other issue is not really a duplicate as it's more about the appearance and not about the notifications displaying according to the DE's notification settings, including being hidden when "Do not disturb" is enabled, which is a privacy and security issue. Until at least an issue is opened elsewhere I suggest reopening one of the two issues.

@mYnDstrEAm commented on GitHub (May 4, 2023): Why is this and/or the other issue closed as completed when the decision seems to be >I think the best - if technically possible - to fix this WITHOUT break security or weakening the power of sandbox & make the fix built-in & user need nothing to do from heir/his side at all. Otherwise, the fix seem to me to penetrate the sandbox & this is bad ... ...and it's not fixed? I don't think it should be closed before either: * it's fixed without decreasing security / the sandboxing (as called for in the issue's last comment) or * the problem or an alternative is identified and an issue is opened elsewhere accordingly if a change to other software is required - such as an issue at the DBUS repo or the KDE repo that is then linked from here Also the other issue is not really a duplicate as it's more about the appearance and not about the notifications displaying according to the DE's notification settings, including being hidden when "Do not disturb" is enabled, which is a privacy and security issue. Until at least an issue is opened elsewhere I suggest reopening one of the two issues.

gitea-mirror commented

2026-05-05 09:44:24 -06:00

Author

Owner

@kmk3 commented on GitHub (May 4, 2023):

@mYnDstrEAm on May 4:

Why is this and/or the other issue closed as completed when the decision
seems to be

This is not "closed as completed"; it is closed as "not planned" because the
profile is working as intended. The same applies to the other issue, which was
closed before "not planned" existed.

I think the best - if technically possible - to fix this WITHOUT break
security or weakening the power of sandbox & make the fix built-in & user
need nothing to do from heir/his side at all. Otherwise, the fix seem to me
to penetrate the sandbox & this is bad ...

...and it's not fixed? I don't think it should be closed before either:

it's fixed without decreasing security / the sandboxing (as called for in
the issue's last comment) or

Sure, how can that be done then? If there is no way to do it in firejail, then
there is nothing to be done here and the issues should be closed, as this is
documented in the profile and the same thing applies to many other profiles.

If you do find out a way, then feel free to post it in #3465.

the problem or an alternative is identified and an issue is opened
elsewhere accordingly if a change to other software is required - such as
an issue at the DBUS repo or the KDE repo that is then linked from here

Sounds like a good idea; feel free to do so.

Also the other issue is not really a duplicate as it's more about the
appearance and not about the notifications displaying according to the DE's
notification settings, including being hidden when "Do not disturb" is
enabled, which is a privacy and security issue. Until at least an issue is
opened elsewhere I suggest reopening one of the two issues.

The root cause and the workaround are the same in both issues, so they are
duplicates from the point of view of the project. I updated the labels in
#3465 as well.

If firejail/the profiles are working as intended, then the issue is closed as
"notabug".

Issues that are caused by a third-party are closed as "notourbug", since they
are usually not actionable here until the issues are fixed (and/or because it
would make more sense to fix the issues elsewhere).

If you want to propose a specific feature related to this, then see:

https://github.com/netblue30/firejail/issues/new?template=feature_request.md

@kmk3 commented on GitHub (May 4, 2023): @mYnDstrEAm [on May 4](https://github.com/netblue30/firejail/issues/5817#issuecomment-1534944707): > Why is this and/or the other issue closed as completed when the decision > seems to be This is not "closed as completed"; it is closed as "not planned" because the profile is working as intended. The same applies to the other issue, which was closed before "not planned" existed. > > I think the best - if technically possible - to fix this WITHOUT break > > security or weakening the power of sandbox & make the fix built-in & user > > need nothing to do from heir/his side at all. Otherwise, the fix seem to me > > to penetrate the sandbox & this is bad ... > > ...and it's not fixed? I don't think it should be closed before either: > > * it's fixed without decreasing security / the sandboxing (as called for in > the issue's last comment) or Sure, how can that be done then? If there is no way to do it in firejail, then there is nothing to be done here and the issues should be closed, as this is documented in the profile and the same thing applies to many other profiles. If you do find out a way, then feel free to post it in #3465. > * the problem or an alternative is identified and an issue is opened > elsewhere accordingly if a change to other software is required - such as > an issue at the DBUS repo or the KDE repo that is then linked from here Sounds like a good idea; feel free to do so. > Also the other issue is not really a duplicate as it's more about the > appearance and not about the notifications displaying according to the DE's > notification settings, including being hidden when "Do not disturb" is > enabled, which is a privacy and security issue. Until at least an issue is > opened elsewhere I suggest reopening one of the two issues. The root cause and the workaround are the same in both issues, so they are duplicates from the point of view of the project. I updated the labels in #3465 as well. If firejail/the profiles are working as intended, then the issue is closed as "notabug". Issues that are caused by a third-party are closed as "notourbug", since they are usually not actionable here until the issues are fixed (and/or because it would make more sense to fix the issues elsewhere). If you want to propose a specific feature related to this, then see: * <https://github.com/netblue30/firejail/issues/new?template=feature_request.md>

gitea-mirror commented

2026-05-05 09:44:24 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (May 12, 2023):

Reopened my issue at KDE here: https://bugs.kde.org/show_bug.cgi?id=457949
If there is a better place to ask about / propose this like at the DBUS repo, please comment where.

Is there something you know of that could be done on the side of KDE or DBUS to solve this problem such as KDE using / also using another system notification service?

However, I suggest that in this case something is done to make the user be aware of that. That's because this is a security and privacy issue if notifications still show with the default firefox profile even when you have "Do not disturb" enabled.

@mYnDstrEAm commented on GitHub (May 12, 2023): Reopened my issue at KDE here: https://bugs.kde.org/show_bug.cgi?id=457949 If there is a better place to ask about / propose this like at the DBUS repo, please comment where. Is there something you know of that could be done on the side of KDE or DBUS to solve this problem such as KDE using / also using another system notification service? However, I suggest that in this case something is done to make the user be aware of that. That's because this is a security and privacy issue if notifications still show with the default firefox profile even when you have "Do not disturb" enabled.

Rows
Columns

[GH-ISSUE #5817] firefox: browser notifications do not appear in KDE notifications #3101

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Additional context

Environment

Checklist

Log