@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
Launch Pluma and write several lines of text
Launch the attached accessibility event listener, focused.py.txt, in a terminal (after removing the ".txt" extension Github insisted upon).
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
@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
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:createBUT it does not firewindow:activate. I suspect firingwindow:activatewhen it appears, and thenwindow:deactivateon it +window:activateon 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