Closed freakboy3742 closed 1 month ago
rmartin16
commented
1 month ago Experimentally, the issue is none of the widgets have focus...as opposed to the "wrong" widget having focus. I'm not sure, though, what the underlying mechanism causing this could be. It seems to be something systemic given that the tests for focus always fail together...
rmartin16
commented
1 month ago Testing in #2873 confirms that what I'm seeing locally is also happening in CI. It seems like something is disabling focus altogether....or preventing grab_focus() from working...
In some additional experimentation, I added an asyncio.sleep() when a focus test failed. This allowed me to manually interact with the app to assign focus to the TextBox; once I did this, the remaining focus tests would pass.
rmartin16
commented
1 month ago Thinking about this a bit more....I tried a few other things.
Testing in #2891 reinforces my belief that something is "breaking" GTK such that grab_focus() stops working.
If you look at the focus tests that fail, they're always the same: it's the focus tests for Widgets whose names come alphabetically after the letters sl. This is potentially important because pytest runs tests alphabetically (at least here). If you consider the inverse set of Widgets, such as Activity Indicator, Button, etc., their focus tests never just randomly fail. If we follow this logic, the bisection leads to the Selection Widget; once the tests for Selection run, the ability to focus a widget ostensibly stops working.
Therefore, something about the tests for Selection seem to be causing this behavior. And finally, when I remove test_selection.py:test_selection_change from the test suite, I can no longer recreate the issue locally. Drilling down just a little bit further....if I allow more and more of test_selection_change to run, the issue reappears once probe.select_item() runs.
freakboy3742
commented
1 month ago If you look at the focus tests that fail, they're always the same: it's the focus tests for Widgets whose names come alphabetically after the letters
sl.
I had the same thought - it's not all focus tests, just the ones after selection. I went looking for a culprit, but not being able to reproduce made it a difficult wumpus to hunt.
Therefore, something about the tests for Selection seem to be causing this behavior. And finally, when I remove
test_selection.py:test_selection_changefrom the test suite, I can no longer recreate the issue locally.
That's very interesting...
Drilling down just a little bit further....if I allow more and more of
test_selection_changeto run, the issue reappears onceprobe.select_item()runs.
Here's a theory - select_item() is calling native.popup(), which will be, at a technical level, creating a new window. Is it possible that something has changed in Wayland (or GTK...) which results in the actual app window losing focus to this new window, but then not giving focus back to the app window when the popup disappears, resulting in widgets in the app window being unable to gain focus at all? Do we need to either add a self.widget.window.native.present() (or similar) to ensure that the window is the focus widget after the popup?
rmartin16
commented
1 month ago Tried a few more things and ultimately, no matter what I try to get focus back on the testbed app, it doesn't work.
So, then I started experimenting directly in Fedora 40 which has a native Wayland environment...and the testing runs fine. Then I tried running the tests using the mutter provided by Fedora 40 and the tests also run fine. Fedora 40 and Ubuntu 24.04 both provide mutter 46.2 while Ubuntu 22.04 is back on mutter 42.9.
I think if we just get on to a newer version of mutter, these tests will stop failing.
Describe the bug
We've started seeing an intermittent failure in the Linux Wayland Testbed suite.
For example, this PR took 6 attempts before it passed; other PRs pass first time; others on a second attempt.
Steps to reproduce
Run the linux-wayland testbed test on any PR.
There's no obvious pattern to the failures.
Expected behavior
Linux Wayland testbed should pass reliably.
Screenshots
No response
Environment
Logs
Additional context
No response