I also experience this issue.  The links are passed to and opened in the browser, but the browser window is not brought to the front.

Same here with Wayland. With X11 the behaviour is different and FF is brought to the foreground.

Cc'ing Stefan Dirsch (xwayland maintainer): Any idea? Thx.

Don't know what you mean exactly. Maybe you can make a video of the issue?

Created attachment 870775 [details]
Stefan: Attached is a video that I hope clearly communicates the issue.

When I click the first two links (from LibreOffice Writer and Zim Wiki) the links open in Firefox, but the window is not brought to the foreground.  When I open the third link from

Ok. Understood. I can't say if this happens by intention, i.e. windows that are iconified stay iconified. But I would assume KDE wants to behave here the same on X11 and Wayland. Of course it could also be a driver issue. Which driver are you using? 'glxinfo -B' should show me.

Here is my 'glxinfo -B' output when running Wayland:

name of display: :1
display: :1  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
	Vendor: Intel (0x8086)
	Device: Mesa Intel(R) Iris(R) Graphics 5100 (HSW GT3) (0xa2e)
	Version: 23.2.1
	Accelerated: yes
	Video memory: 1536MB
	Unified memory: yes
	Preferred profile: core (0x1)
	Max core profile version: 4.6
	Max compat profile version: 4.6
	Max GLES1 profile version: 1.1
	Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Iris(R) Graphics 5100 (HSW GT3)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.2.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.2.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.2.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

To add additional clarification, this behavior is different form X11.  In X11, links from all 3 of those applications result in the Firefox window being brought to the foreground.

Created attachment 870784 [details]
glxinfo -B

There you are.

[18:38:09]macom@opensuse:~$ glxinfo -B
name of display: :1
display: :1  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) HD Graphics 520 (SKL GT2) (0x1916)
    Version: 23.2.1
    Accelerated: yes
    Video memory: 7860MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 520 (SKL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.2.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.2.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.2.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

[18:38:16]macom@opensuse:~$

(In reply to Frank Krüger from comment #9)
> Created attachment 870784 [details]
> glxinfo -B
> 
> There you are.

OpenGL renderer string: AMD Radeon Graphics (renoir, LLVM 17.0.3, DRM 3.54, 6.6.1-3.gfd0e37e-default)

Others are:

OpenGL renderer string: Mesa Intel(R) Iris(R) Graphics 5100 (HSW GT3)
OpenGL renderer string: Mesa Intel(R) HD Graphics 520 (SKL GT2)

So apparently same issue with different drivers. Radeon and Intel here.

(In reply to Stefan Dirsch from comment #11)
> (In reply to Frank Krüger from comment #9)
> > Created attachment 870784 [details]
> > glxinfo -B
> > 
> > There you are.
> 
> OpenGL renderer string: AMD Radeon Graphics (renoir, LLVM 17.0.3, DRM 3.54,
> 6.6.1-3.gfd0e37e-default)
> 
> Others are:
> 
> OpenGL renderer string: Mesa Intel(R) Iris(R) Graphics 5100 (HSW GT3)
> OpenGL renderer string: Mesa Intel(R) HD Graphics 520 (SKL GT2)
> 
> So apparently same issue with different drivers. Radeon and Intel here.

My guess is that it is a Qt 5 issue, whicht might be fixed in QT 6.5, according to https://community.kde.org/Plasma/Wayland_Showstoppers:

Apps using QDesktopServices::openUrl()/Qt.openUrlExternally don't raise existing windows in the activated app: https://codereview.qt-project.org/c/qt/qtwayland/+/321246 and https://codereview.qt-project.org/c/qt/qtbase/+/447556; fixed in Qt 6.5

It seems to be an issue with xwayland apps trying to bring a Wayland app (firefox) to the focus.  A Wayland native app (konsole) can bring Wayland firefox to the front, but Zim and LibreOffice running in xwayland cannot.  If I force firefox to run in xwayland, then clicking links in Zim and LibreOffice result in firefox being brought into focus.

(In reply to Justin Anteau from comment #13)
> If I force firefox to run in xwayland, then clicking links in Zim and
> LibreOffice result in firefox being brought into focus.

How did you force firefox? Mine is running in xwayland with the issue described here.

(In reply to Frank Krüger from comment #14)
> (In reply to Justin Anteau from comment #13)
> > If I force firefox to run in xwayland, then clicking links in Zim and
> > LibreOffice result in firefox being brought into focus.
> 
> How did you force firefox? Mine is running in xwayland with the issue
> described here.

You can set the environment variable MOZ_ENABLE_WAYLAND=1.

(In reply to Justin Anteau from comment #15)
> (In reply to Frank Krüger from comment #14)
> > (In reply to Justin Anteau from comment #13)
> > > If I force firefox to run in xwayland, then clicking links in Zim and
> > > LibreOffice result in firefox being brought into focus.
> > 
> > How did you force firefox? Mine is running in xwayland with the issue
> > described here.
> 
> You can set the environment variable MOZ_ENABLE_WAYLAND=1.

This doesn't solve the issue for me. As I have mentioned before, Firefox is already running in xwayland.

Is there any news/progress regarding this bug report to be expected?

The issue still exists with TW20240407, KDE Plasma 6.0.3 and Wayland. Is anyone else still experiencing it? Thx.

Actually, I don't see the status "in progress" here, so set it to "new" again.

(In reply to Frank Krüger from comment #18)
> The issue still exists with TW20240407, KDE Plasma 6.0.3 and Wayland. Is
> anyone else still experiencing it? Thx.

Yes, have still the same issue.

With TW20240624 and KDE Plasma 6.1 the issue is gone. Can someone else confirm this observation? Thx.

Not for me with TW20240625 and Plasma 6.1.0

(In reply to Guido Niewöhner from comment #22)
> Not for me with TW20240625 and Plasma 6.1.0

Do you have kmozillahelper installed? If so, does removing it solve the issue?

(In reply to Frank Krüger from comment #23)
> (In reply to Guido Niewöhner from comment #22)
> > Not for me with TW20240625 and Plasma 6.1.0
> 
> Do you have kmozillahelper installed? If so, does removing it solve the
> issue?

Yes, that seems to have done the trick.

Thanks a lot!!!

(In reply to Guido Niewöhner from comment #24)
> (In reply to Frank Krüger from comment #23)
> > (In reply to Guido Niewöhner from comment #22)
> > > Not for me with TW20240625 and Plasma 6.1.0
> > 
> > Do you have kmozillahelper installed? If so, does removing it solve the
> > issue?
> 
> Yes, that seems to have done the trick.
> 
> Thanks a lot!!!

Great. JFYI: There is bug #1226112 "Supersede kmozillahelper by xdg-desktop-portal integration".

(In reply to Frank Krüger from comment #25)
> (In reply to Guido Niewöhner from comment #24)
> > (In reply to Frank Krüger from comment #23)
> > > (In reply to Guido Niewöhner from comment #22)
> > > > Not for me with TW20240625 and Plasma 6.1.0
> > > 
> > > Do you have kmozillahelper installed? If so, does removing it solve the
> > > issue?
> > 
> > Yes, that seems to have done the trick.
> > 
> > Thanks a lot!!!
> 
> Great. JFYI: There is bug #1226112 "Supersede kmozillahelper by
> xdg-desktop-portal integration".

Thanks.
I have xdg-desktop-portal and xdg-desktop-portal-kde6 installed.
Dolphin is opened even without changes in about:config

(In reply to Frank Krüger from comment #18)Is
> > anyone else still experiencing it?

Yes. The link is opened, the Task Manager icon is tinted in my accent colour to show that the browser window is requesting attention, but it is not focussed or activated.

Seems like kmozillahelper is the problem, but I am using that... I guess I'll look forward to a fix.

Is this actually a suse bug? Has anyone tried to replicate this on another distro? Perhaps we might see a fix faster if it is reported upstream, if that's the right place...

(In reply to pallas wept from comment #27)
> (In reply to Frank Krüger from comment #18)Is
> > > anyone else still experiencing it?
> 
> Yes. The link is opened, the Task Manager icon is tinted in my accent colour
> to show that the browser window is requesting attention, but it is not
> focussed or activated.
> 
> Seems like kmozillahelper is the problem, but I am using that... I guess
> I'll look forward to a fix.

Removing kmozillahelper solves the issue only partially for Firefox/Thunderbird. In fact, when trying to open a link in libroffice, the link is opened but not brought to the foreground. So it seems the issue is more involved...

(In reply to pallas wept from comment #28)
> Is this actually a suse bug? Has anyone tried to replicate this on another
> distro? Perhaps we might see a fix faster if it is reported upstream, if
> that's the right place...

I have seen similar reports, e.g., for Manjaro, but I have no idea where to report this issue upstream. Any suggestions?

I hope this is the right spot for it: https://github.com/openSUSE/kmozillahelper/issues/43