Whenever Firefox played videos or - actually more relevant - I watched the shared screen of a colleague, after some time the screenlock would start. This is especially annoying, since I have to enter my password to unlock again.
In my status way waybar there is an idle inhibit switch which I could then use to prevent the lock from activating. That this switch worked led to the conclusion that there is something with Firefox that prevented this from working. Behind the scenes, there are two components that have mixed responsibility when it comes to locking / suspending / sleeping - responsibilities which overlap, and are not completely clear in the end.
Some people have written applications that listen for DBus events targeting the idle-inhibit interface and transfer that setting into the wayland flag that actually controls it. However, after some research I was able to find a proper solution that does not require an extra application. Instead, it fixes a bad behaviour of a participating component by overriding the configuration.
The solution is from Reddit and suggests changing the interface bindings in ~/.config/xdg-desktop-portal/sway-portals.conf:
[preferred]
# Use xdg-desktop-portal-gtk for every portal interface...
default=gtk
# ... except for the ScreenCast, Screenshot and Secret
org.freedesktop.impl.portal.ScreenCast=wlr
org.freedesktop.impl.portal.Screenshot=wlr
# ignore inhibit bc gtk portal always returns as success,
# despite sway/the wlr portal not having an implementation,
# stopping firefox from using wayland idle-inhibit
org.freedesktop.impl.portal.Inhibit=none
