Proposed as a Blocker for 38-final by Fedora user eischmann using the blocker tracking app because:

 The intensity of stealing the focus is so high that it basically prevents you from using other apps on the same workspace.

I am unable to reproduce on my laptop. I have tried with Gimp and Chromium, but I can easily switch between windows withou any problems with focus. The same holds true for laptop only mode, or with external monitors, the single apps being placed on one desktop or multiple desktops.

Laptop is Lenovo P1 4th gen, running 6.2.1-300.fc38.x86_64 with gnome-shell-44~beta-2.fc38.x86_64.

*** Bug 2175151 has been marked as a duplicate of this bug. ***

We seem to have a confirmation or a similar issue in bug 2175151.

Also see here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-489f1e935f#comment-2920318
https://gitlab.gnome.org/GNOME/mutter/-/commit/a68b8e95954772cd6f5d676a803e01c13e48c83f#note_1683082
https://gitlab.gnome.org/GNOME/mutter/-/issues/2635

The upstream issue suggests this isn't so much about the app 'stealing' the focus as the app *losing* it? Like Lukas I cannot reproduce this (I've been using F38 for months and have zero issues like this), but that may be because I'm not running any Java/Swing apps...

I was using 'git gui' (X11 app with tcl/tk) and focus handling was also messed up,
but I wasn't able to pin down the exactly problem. I can't reproduce the issue now.
Anyway, I'll report if I have more info, but if it's the same issue, it's not related
to Java/Swing.

I have two systems here with a fresh Fedora 37 Workstation install from yesterday upgraded to Fedora 38. Here's the 100% reproduce procedure for two related failures.

Scenario 1: XWayland -> Launch Wayland app
==========================================
1. Login to GNOME.
2. Run any Xwayland app. glxgears or chromium both work.
3. Super+gnome-terminal launch
4. FAIL: You see gnome-terminal but the cursor is hollow instead of solid indicating it lacks input focus. Clicking within the terminal doesn't fix keyboard input focus. Clicking on UI elements in that wayland app does work.
5. FAIL: Immediately after gnome-terminal had launched try alt-tab. gnome-terminal is missing as a valid alt-tab window for quite a while so it doesn't work. Wait long enough and it appears. Then alt-tab to the Xwayland app then back to the wayland app fixes input focus for the latter.

Scenario 2: XWayland -> Super+Click to Wayland app
==================================================
1. Login to GNOME.
2. Run any wayland app (e.g. gnome-terminal is good choice because the hollow cursor is a visible indicator that window doesn't have input focus)
3. Run any Xwayland app (e.g. chromium defaults to X11 unless you change it in about:flags)
4. Alt-tab to the wayland app. This works no problem.
5. Alt-tab back to the Xwayland app.
6. FAIL: Super+Click to switch to the wayland app. gnome-terminal shows the hollow cursor indicating it doesn't have input focus. Typing does nothing. Clicking fails to switch input focus to the window.
7. Alt-tab to the Xwayland app then back to the wayland app fixes input focus.

Notes
=====
* halfline had a hunch this was a stuck modifier. Tried removing ibus-typing-booster and upgrading xorg-x11-server-Xwayland to F39 version, no change of behavior. The way how keyboard input fails to do anything entirely suggests this isn't a stuck modifier.

see https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878

I haven't been following along on this issue, but I did a scratch build with Carlos's fixes here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=98277581

if anyone wants to try it.

Ray: that MR is listed as addressing https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5932 , which is reported as being specific to GNOME-on-X11.

What https://gitlab.gnome.org/GNOME/mutter/-/issues/2635 (the upstream issue originally linked here) actually says is "Globally active X11 windows, which usually means any Java/Swing windows, like IntelliJ for example, don't receive input focus anymore after some of the recent grab/focus related changes." That is, Java/Swing apps aren't the *only* affected apps, just a *common* type of affected app. BUt "Globally active X11 windows" isn't "all X11 windows", is it? I don't know what "globally active" *means* exactly, it might be useful to have a definition. Presumably Chromium and glxgears are "globally active"? What would *not* be "globally active"?

I confirmed Ray's scratch build solved the problem for me! It fixed both of the scenarios I wrote above in comment 7. 

I don't know about "globally active" but the following apps all triggered the input focus problem when using Super to switch to a wayland app.
chromium, glxgears, gparted, hexchat

afaict, "globally active" means "window that explicitly calls XSetInputFocus itself."

Anyway, to be clear (now, that is. tbf, I didn't mention it before),
one of the patches I added to the scratch build has this commit message:

From faa003812c10ab14bc69d6add078ff10528dc78b Mon Sep 17 00:00:00 2001
Subject: [PATCH 1/3] x11: Avoid updating focus on wayland compositor
...
An example of this breaking can be reproduced with a Spotify and
Firefox window, moving the focus from the first to the second by
going to the GNOME Shell overview in between, and clicking the
Firefox window from there. The Firefox window will be raised, but
refuse to take focus.
...

It's one that was already merged upstream.

(well more likely, I guess, "globally active" means app has input focus in Xwayland and mutter)

There's +4 for Beta FE in https://pagure.io/fedora-qa/blocker-review/issue/1057 , so listing as accepted FE.

I was able to reproduce this with glxgears, and yeah, it's pretty wacky. For me it also hung around after I quit glxgears, which is...fun.

I agree with you Adam, I've the impression it's not happening every time (here with Thunderbird), and when it happens a reboot or playing with TTY switchings can be required to fix it.
Very annoying when it's happening.

okay since warren confirmed the scratch build worked, I'll just build that directly.

i started the build here: Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=98329439


I've gotta make a run to the airport, now, though. if someone else wants to run fedpkg update...otherwise will do when i get back in a couple of hours.

FEDORA-2023-b05331d2bc has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b05331d2bc

FEDORA-2023-b05331d2bc has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b05331d2bc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

The latest update with backported focus fixes works for me and I no longer experience this bug.

Discussed in ticket: https://pagure.io/fedora-qa/blocker-review/issue/1057

The decision to classify this bug as an RejectedBlocker (Beta) was made:

"This doesn't affect any pre-installed applications and so doesn't violate any Beta Release Criteria."

FEDORA-2023-b05331d2bc has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

I run Fedora 38 and have been since before the beta came out. From the beginning I have been experiencing focus issues. The pattern is:

After login:

- open an application (gnome terminal works, but so does Chrome)
- see application get focus (cursor looks normal, typing works)
- open a second window for the same application or open any other application
- expect the focus to be on the newly opened application/window
- type anything and discover the focus is still on the previous window
- open any new application (even after closing all previously opened windows) and see they do not receive focus

I am running the latest updates of F38 with default Gnome desktop / Wayland.

The bug is maddening. Expecting to be typing in the Chrome address bar but being inside an obscured terminal is frightening enough. Experiencing the same when you expect to be in new local terminal window while still typing inside an obscured server side terminal session is pure horror!

I actually expected this problem to be fixed very soon because of the severity. Now that F38 has been released the bug is still there so I decided to report.

Cheers,

Silvio

Hi Silvio! Sorry about that. Can you file a new report? This specific bug was reproduced by multiple people (see above) and reported definitely fixed by the update (also see above), so whatever you're seeing, it's not exactly this bug.

I wasn't aware that anyone was still having problems along these lines; if such a report had been flagged as a potential blocker bug it would've been reviewed as one prior to F38's release, but none was.