Accessible window for line-number popup (Ctrl+I) lacks active state causing Orca to ignore it

[joanmarie]

@cwendling: Could you please take a look at this when you get a chance? (In this case we're already getting object:state-changed:focused, but the window claims to be inactive.) Thanks in advance!

Steps to reproduce the behaviour

1. Launch Pluma and write several lines of text
2. Launch the attached accessibility event listener, focused.py.txt, in a terminal (after removing the ".txt" extension Github insisted upon).
3. Press Ctrl+I to enter the line number popup

Expected behaviour

The listener would print out that the top-level object associated with the newly-focused text input had the active state.

Actual behaviour

The listener would print out that the top-level object associated with the newly-focused text input lacks the active state.

Notes

• This issue does not appear in Gedit, though Gedit doesn't appear to be putting the line-number popup in a dedicated window.

• The top-level object associated with the newly-focused text input fires window:create BUT it does not fire window:activate. I suspect firing window:activate when it appears, and then window:deactivate on it + window:activate on the document frame will fix this issue.

• Because of this bug, Orca from its main branch does not present the newly-focused text input. Earlier versions of Orca, which listened for the deprecated focus: event -- and updated focus without checking the window was active -- did. However events coming from a non-active window can be fired and shouldn't be presented by Orca. Therefore I (Orca maintainer) think the fix belongs in Pluma rather than worked around in Orca.

Environment

This is an upstream bug that I'm filing on behalf of an Orca user. I'm not sure what distro he happens to use, though he is using MATE. I'm using Fedora 40 with gnome-shell and the issue is (also) reproducible in my environment. My pluma version is 1.28.0