Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003771Doomseeker[All Projects] Bugpublic2020-03-22 08:572022-09-10 15:30
ReporterWubTheCaptain 
Assigned ToZalewa 
PrioritynoneSeveritytweakReproducibilitysometimes
StatusresolvedResolutioninvalid 
PlatformOSDebian GNU/LinuxOS Versionbullseye/sid
Product Version1.3.1 
Target VersionFixed in Version1.4.0 
Summary0003771: "Put populated servers on top" has regressed to require UI interaction for focus on startup
DescriptionAs far as I remember, Doomseeker has always had this quirky behavior where the "put populated servers on top" option for server filtering requires focus on the UI window (server browser) to refresh the server browser view (to sort by populated servers). This is most noticeable if Doomseeker is allowed to update the servers in background, while another window (e.g. a game) is in focus.

The behavior described earlier isn't an issue and is considerably normal behavior, because mouse cursor focus on the window would immediately put populated servers on top.

A regression somewhere has caused to require UI interaction on startup, e.g. a mouse cursor click, to update the server browser view and put populate servers on top. But only under obscure conditions, such as starting Doomseeker from dmenu instead of a shell/terminal emulator. Mouse wheel scrolling in the server browser doesn't count as focus. This "require UI focus on startup" didn't use to be reproducible this way few months ago on my system.

This is reproducible with a new configuration, so it seems not an issue with my configuration.
Steps To Reproduce
  1. Sort by lowest ping. Clear any additional sorting. (The default new configuration will get you far.)
  2. Because of another bug, the server filtering checkbox "put populated servers on top" shouldn't matter. Still, for the sake of reproduction let's assume it's enabled (because it is enabled in the default configuration).
  3. Close Doomseeker.
  4. Start dmenu (default keybinding in i3-wm: $mod + D, aka Mod4 + D, aka Meta key + D) and run Doomseeker.
  5. Notice servers are being populated to the server browser (with Internet connection), but the populated servers are not at the top. If not, reattempt few times.
  6. Click anywhere or gain window focus some other way, then notice the populated servers jump to top. The most clear indicator of this happening is the "Server name" textbox in server filter gaining focus, and you can start typing.


Repeat from a shell/terminal emulator and the issue can't be reproduced.

The "filtering enabled" option in server filter does not need to be checked, it's unrelated and has no effect on reproduction. (It filters by "max. ping" alright on startup, without need for focus, while filtering is enabled.)
Additional InformationQt 5.12.5.
Attached Filespng file icon issue-3771.png [^] (662,654 bytes) 2020-03-22 09:27

- Relationships

-  Notes
User avatar (0021228)
WubTheCaptain (reporter)
2020-03-22 09:27
edited on: 2020-03-22 09:28

 issue-3771.png is a screenshot from startup, without gaining focus.

To get this screenshot, I had to use delay:
maim -u --delay=30 | xclip -selection clipboard -t image/png

I then cropped the image in an image editor.
User avatar (0021229)
WubTheCaptain (reporter)
2020-03-22 09:33
edited on: 2020-03-22 09:34

 issue-3771.png also happens with "put populated servers on top" disabled, because of issue 0003772 they are treated as enabled, so as I said in the steps to reproduce, it shouldn't matter.
User avatar (0021430)
Zalewa (developer)
2020-06-08 12:11
edited on: 2020-06-08 15:06

 Server sorting is turned off when Qt tells us that the main window is not active. We check this property:'https://doc.qt.io/qt-5/qwidget.html#isActiveWindow-prop [^]'

So far in all cases when the program was launched, the OS would give it the focus and this property would return true. dmenu launch doesn't seem to give focus to Doomseeker's main window and this causes the described problem. This effect can also be triggered manually: simply launch Doomseeker through "normal" means and then quickly click away so that the window loses focus.

I'm not certain if this is something we should attempt at fixing. If this is the way dmenu launches the app, it may be either a dmenu bug or an intended dmenu behavior.

As a workaround, it would technically be possible to forcibly steal the focus in MainWindow::postInitAppStartup(), but this actually interferes with the OS behavior and may cause some difficult to predict side-effects that may not be desireable.

Alternatively, we could remove this isActiveWindow() check and always sort the servers, but this is risky as the check was added for "performance cooperation" purpose. Sorting the server list is an expensive task and on 2010 PCs if you played the game and Doomseeker refreshed the servers in the background, you could actually feel the FPS drop. It's 10 years later now and with all the Ryzens around we could reconsider if this performance drop is still an issue, but I can say upfront that my stance here is cautious and that this behavior should not be changed.

Perhaps you could add a quick debug line to MainWindow::postInitAppStartup() and check what it says?

    qDebug() << "is active window:" << isActiveWindow();

If it says "false", then the sorting is disabled as intended and something is simply causing the window to not receive focus upon being launched.
User avatar (0021455)
WubTheCaptain (reporter)
2020-06-09 10:11
edited on: 2020-06-09 10:13
Quote from Zalewa
If it says "false", then the sorting is disabled as intended and something is simply causing the window to not receive focus upon being launched.

It says "false" at every opportunity, even if it works as intended.
Something with i3 window manager is weird. If I have a window already opened in a workspace, opening Doomseeker (either from a terminal or dmenu) will gain focus. If there's no window open, Doomseeker won't get focus and then sorting won't happen without a click.
Because of above conditions, testing this makes it difficult too to get stdout/stderr output. I tried sleep 2; ./doomseeker but looks like switching workspaces to a workspace with no windows (to reproduce the issue of workspaces with no windows not gaining focus) in that time period also gives focus to Doomseeker.
User avatar (0021457)
Zalewa (developer)
2020-06-09 13:14
Quote from "Wub"
It says "false" at every opportunity, even if it works as intended.

That's also possible. The window may be "inactive" at the moment of the check and then becomes active some time later.
User avatar (0022386)
Zalewa (developer)
2022-09-10 15:29
edited on: 2022-09-10 15:30
Quote from WubTheCaptain
Because of another bug, the server filtering checkbox "put populated servers on top" shouldn't matter.

This is an actual bug but I don't see a dedicated ticket for it. Fixed it anyway:'https://bitbucket.org/Doomseeker/doomseeker/commits/b89dc70f0186465f5b46a8eb9f1ee9b89eb62367 [^]'

As for the rest of your report I fail to see anything that would indicate an incorrect behavior. The program won't sort the servers when its window is out of focus (inactive), regardless if you are able to see the window and scroll the server list within it. This is by design.

We could discuss if scrolling the list should trigger the sorting. My opinion is that the UX is screwed either way:

  • we trigger sort on scroll: you scroll the list and it shifts everything around, where did the servers you were just looking at go?

  • we keep it as it is: you click the program and it shifts everything around, where did the servers you were just looking at go?

  • we sort even if program is out of focus: choppy choppy system CPU usage spikes.


So, let's not screw around with this.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2020-03-22 08:57 WubTheCaptain New Issue
2020-03-22 09:27 WubTheCaptain File Added: issue-3771.png
2020-03-22 09:27 WubTheCaptain Note Added: 0021228
2020-03-22 09:28 WubTheCaptain Note Edited: 0021228 View Revisions
2020-03-22 09:33 WubTheCaptain Note Added: 0021229
2020-03-22 09:34 WubTheCaptain Note Edited: 0021229 View Revisions
2020-06-08 12:11 Zalewa Note Added: 0021430
2020-06-08 12:13 Zalewa Note Edited: 0021430 View Revisions
2020-06-08 13:56 WubTheCaptain Status new => feedback
2020-06-08 13:58 Zalewa Note Edited: 0021430 View Revisions
2020-06-08 15:06 Zalewa Note Edited: 0021430 View Revisions
2020-06-09 10:11 WubTheCaptain Note Added: 0021455
2020-06-09 10:11 WubTheCaptain Status feedback => new
2020-06-09 10:11 WubTheCaptain Note Edited: 0021455 View Revisions
2020-06-09 10:13 WubTheCaptain Note Edited: 0021455 View Revisions
2020-06-09 13:14 Zalewa Note Added: 0021457
2022-09-10 15:29 Zalewa Note Added: 0022386
2022-09-10 15:29 Zalewa Status new => resolved
2022-09-10 15:29 Zalewa Fixed in Version => 1.4.0
2022-09-10 15:29 Zalewa Resolution open => invalid
2022-09-10 15:29 Zalewa Assigned To => Zalewa
2022-09-10 15:30 Zalewa Note Edited: 0022386 View Revisions




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker