GNOME Bugzilla – Bug 433951
Making changes in the Orca Preferences dialog causes loss of script state
Last modified: 2008-07-22 19:27:40 UTC
Steps to reproduce: 1. Launch Firefox, be sure Orca is controlling the caret, and navigate to some text. 2. Press Orca_Modifier+Space for the Orca Preferences dialog 3. Press the OK button Expected results: Focus would return to the location within the document chosen in step 1. Actual results: Focus is returned to the document frame only. Reloading the settings is blowing away the caretContext. This issue will become a bit more significant with the implementation of the app-unique settings feature (see bug #433146) because the user is more likely to enter that dialog while browsing a page to change settings.
During the team meeting today it was observed that this issue also occurs if you move focus to another window and back again. I was not able to reproduce that. (I tried by opening and reading email in Evolution and typing commands in gnome-terminal). So far, for me, Orca is keeping track of my present location as long as I don't reload my settings.
As part of my work on bug 437753, I've added some setter/getter methods for the caret context. As a side effect of those methods (patch not even provided yet), this problem seems to have gone away.
(In reply to comment #2) > As part of my work on bug 437753, I've added some setter/getter methods for the > caret context. As a side effect of those methods (patch not even provided > yet), this problem seems to have gone away. > The patch for bug 437753 (http://bugzilla.gnome.org/attachment.cgi?id=89111&action=view) seems to have fixed this problem. So, I'm marking this one as [pending].
Oh...you have to make *changes* to the preferences dialog. D'Oh! The problem is this: orca.loadUserSettings() calls 'deactivate' and then 'activate' on the current presentation manager. 'deactivate' on the focus_tracking_presenter deletes all known scripts, along with any state they were keeping. In the original case for this bug, the Gecko script is maintaining state about where the caret context is for each page tab. I suspect we run into other losses of state from other scripts (e.g., the last 'n' messages in GAIM). As a possible solution, we might try adding {get,set}AppState to script.py. The getter would return an object that could be passed to the setter, and these would be used to set/restore state. The definition of the object could be anything -- it would effectively be opaque to everything except the actual script object that implements the {get,set}AppState methods. Hooking this all together might be a bit troublesome, but one idea is this: Add {save,restore}AppStates methods to focus_tracking_presenter.py. (and presentation_manager.py for that matter). As part of the 'save' method, for each script the focus_tracking_presenter knew about, it would save the Accessible for the application associated with the script along with the results of the call to getAppState on that script. The return would be a list of [Accessible, state] pairs. As part of the 'restore', for each item in the list obtained from the 'save', the focus_tracking_presenter would instantiate a new script for the app and set its app state. It might work. See also bug 423440, which might benefit from the {get,set}AppState methods.
Created attachment 89498 [details] [review] Patch to implement {get,set}AppState and focus_tracking_presenter mods This patch seems to solve the problem. In looking at the scripts, it seems as though state based upon user action (i.e., unrecoverable state by looking at the app alone) was being kept in the following scripts: Gecko.py: caret context per document frame StarOffice.py: dynamic row and column headers gaim.py: chat history Can anyone think of anything other scripts where just activating the application would not result in proper state being restored?
I've just done some testing with both firefox and calc and orca now seems to be saving the state as I would expect.
Thanks! Closing as FIXED. This was a good bug. :-)