GNOME Bugzilla – Bug 326041
Revist handling of apps using obsolete spec
Last modified: 2020-11-06 20:07:14 UTC
Description: So, we previously decided that in interest of backwards compatibility that when apps (normal ones or pagers) sent a _NET_ACTIVE_WINDOW message without a timestamp that we would honor those requests. Judging by bug reports since that time, I think we have very strong reason to believe that despite what looked like solid reasoning, it was a poor decision. Rationale: Bugs: The bugs that this decision causes range from the more innocuous "why did this stupid window steal my focus -- THREE separate times during its (excessively long) startup?" (e.g. OpenOffice) to "why does my app often and quite randomly steal focus AND warp workspaces?" (which is a bug in Eclipse that Billy notified me of, told me he was powerless to fix for a long time due to their release cycle and adoption rates, and asked us to provide a workaround since apparently KWin does) to "how come my app is broken (doesn't respond to any keyboard or mouse events)?" (see bug 307875 comment 11 and note that although it is explained in terms of nonzero timestamps (which we worked around) the existence of 0 timestamps makes something like that more likely). Further, apps have had a considerable amount of time since then in which to upgrade to the newer spec. Finally, it may be worthwhile to provide encouragement to app authors to update/upgrade. (If this were the only reason to not focus apps due to obsolete requests, then it would only be worthwhile to have the change effective during the development cycle; but this definitely does serve as an extra reason to change for at least during the developmental cycle.) Planned Action: Ignore _NET_ACTIVE_WINDOW requests from applications other than pagers when they don't come with a timestamp (as a side effect, make use of the source indication field from the spec). Make sure that reverting to always-honor-obsolete-requests-from-apps is a one-line patch, just in case we find that it really is still needed before the next stable release.
Created attachment 56896 [details] [review] Deny activation requests with timestamp of 0 unless coming from a pager
So, this may sound odd but I'm going to come out against my own patch -- for now. Although I think it's the right thing to do at some point, it's going to mean uncovering a bunch of buggy apps and then requiring a lot of time to help those authors help fix them. Given that my time is going to be cut short before long, that there is plenty of other things I need to spend it on anyway, and that we're already fairly advanced into the development cycle (with some freezes starting next week), maybe we should wait off until next development cycle. However, I think the source-indication handling parts of the patch (the majority of it) is still useful.
Agreed you might want to avoid this one right before a freeze, but the patch looks fine. You could put it in with just the one line toggle to allow 0 timestamp for now.
Created attachment 57085 [details] [review] Continue unconditionally honoring timestamps of 0 for now Okay here's the version I committed. It doesn't do the timestamp of 0 change yet but makes it simple to toggle when when decide we want to do that as you suggested.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.