Comment 56 for bug 1765261

Lots of people have reproduced this so far, I don't think it's plausible to claim that the bug doesn't exist at this point. Yes, everyone is testing with the latest gnome-shell and mutter, in fact we think 3.28.1 actually *introduced* this bug. Multiple GNOME devs have already reproduced this and are discussing how to fix it, e.g. in this log from #fedora-desktop:

<garnacho> https://gitlab.gnome.org/GNOME/mutter/merge_requests/97 is for the password thing btw, root cause pending, but that's enough to fix it
<halfline> garnacho: nice
<halfline> hmm
<halfline> so that code got added here it seems: https://bugzilla.gnome.org/show_bug.cgi?id=725102
<halfline> and in that bug it says this: "switching the keymap
<halfline> should be done at a time when no key is currently pressed down, but let's leave that task to higher level code"
<garnacho> yeah, quite fishy that it changes while typing stuff, it's clearly not due to the focus change
<halfline> it's the same keymap again ?
<garnacho> in essence yes
<garnacho> maybe some explicit keymap change to cater for per-window IM -> clutter focus changes?
<garnacho> I guess that mention in the code is there for the situations where you shuffle modifier keys around
<garnacho> but hardly stands true with <super>space :/
<garnacho> s/in the code/in the bug/
<halfline> well your patch makes sense to me on the surface. i wish rtcm was here
<halfline> i wonder if it's from InputSourceManager's _keyboardOptionsChanged or from activateInputSource
<halfline> i guess if activating the input source is async and it happens on focus in that might explain it
* halfline tries adding some logs
<garnacho> halfline: not sure it's simply that. I've been trying with a polkit dialog, and took my time before typing
<garnacho> it's somehow sent around the same time shift is pressed
<garnacho> but yeah, ideally the keymap shouldn't even change :)
<halfline1> i was working on adding some backtrace dumpping to InputSource activate but had to run to a meeting