GNOME Bugzilla – Bug 527229
Cache is not invalidated across all paperweights
Last modified: 2019-03-27 20:11:22 UTC
When retrieving cachable property the lookup order for finding the cached property is: 1. Look for property cache slot on paperweight, if that fails... 2. Look up property cache in global cache using accessible's hash, if that fails... 3. Create new property cache, put in paperweight's slot, and in global cache using accessible's hash as key. When a cache-invalidating event is received, we simply erase the hash-keyed entry in the global cache dictionary. Since we only remove the entry from the global cache, paperweights laying around with the old _PropertyCache instance will still return invalid properties. Since step 1 above succeeds. Besides the global cache, the properties need to be wiped from the paperweights themselves.
Created attachment 108956 [details] [review] Proposed patch This patch gives _PropertyCache a new method, wipe(). In this manner we could simply wipe a property cache instance and clear any stored values. This will be persisted across all references to that property cache. In this fashion we could be certain that the cache is persisted to all paperweights.
After using this for a couple of weeks, I deem it worthy for trunk :)
This seems to have introduced a regression in the Orca tests. Not sure why... bash-3.2$ ./runone.sh ../keystrokes/gtk-demo/role_dialog.py gtk-demo 0 starting test application gtk-demo ... Test 1 of 2 FAILED: ../keystrokes/gtk-demo/role_dialog.py:Dialog automatic reading DIFFERENCES FOUND: - BRAILLE LINE: 'gtk-demo Application Window Expander $l' ? --------------------- + BRAILLE LINE: 'Window Expander $l' - VISIBLE: 'Expander $l', cursor=9 ? ^ + VISIBLE: 'Window Expander $l', cursor=16 ? +++++++ ^^ - BRAILLE LINE: 'gtk-demo Application Window $l' + BRAILLE LINE: 'Window $l' - VISIBLE: 'gtk-demo Application Window $l', cursor=29 ? --------------------- ^^ + VISIBLE: 'Window $l', cursor=8 ? ^ - BRAILLE LINE: 'gtk-demo Application Window $l' + BRAILLE LINE: 'Window $l' - VISIBLE: 'gtk-demo Application Window $l', cursor=29 ? --------------------- ^^ + VISIBLE: 'Window $l', cursor=8 ? ^ BRAILLE LINE: 'gtk-demo Application GTK+ Code Demos Frame TabList Widget (double click for demo) Page ScrollPane TreeTable Widget (double click for demo) ColumnHeader Expander TREE LEVEL 1' VISIBLE: 'Expander TREE LEVEL 1', cursor=1 BRAILLE LINE: 'gtk-demo Application GtkExpander Dialog' VISIBLE: 'GtkExpander Dialog', cursor=1 BRAILLE LINE: 'gtk-demo Application GtkExpander Dialog & y Details ToggleButton' VISIBLE: '& y Details ToggleButton', cursor=1 - SPEECH OUTPUT: 'Widget (double click for demo) page' SPEECH OUTPUT: 'Widget (double click for demo) column header' SPEECH OUTPUT: 'Expander' SPEECH OUTPUT: 'tree level 1' SPEECH OUTPUT: 'GtkExpander Expander demo. Click on the triangle for details.' SPEECH OUTPUT: '' SPEECH OUTPUT: 'Details toggle button not pressed' [FAILURE WAS UNEXPECTED] Test 2 of 2 SUCCEEDED: ../keystrokes/gtk-demo/role_dialog.py:Dialog Where Am I SUMMARY: 1 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 2 for ../keystrokes/gtk-demo/role_dialog.py
I don't think this is a regression. Try setting settings.cacheValues to False in Orca, you will notice that the regression test above shows similar output.
(In reply to comment #4) > I don't think this is a regression. Try setting settings.cacheValues to False > in Orca, you will notice that the regression test above shows similar output. > The reason I think it might be associated with this bug is that I had the following observation when tracking down the regression: if one runs the regression test before the patch was applied, the differences don't happen. But, if one runs the test after the patch was applied, and that's the *only* change made to the system, the differences do happen. Are you able to reproduce this?
(In reply to comment #5) > The reason I think it might be associated with this bug is that I had the > following observation when tracking down the regression: if one runs the > regression test before the patch was applied, the differences don't happen. > But, if one runs the test after the patch was applied, and that's the *only* > change made to the system, the differences do happen. Are you able to > reproduce this? > I will represent the results in a table, my verbal communication skills are shutting down for some reason: A = pre-patch orca output. B = post-patch orca output. Patch Caching enabled Caching disabled ----------------------------------------------------- Pre-patch A B Patched B B This leads me to believe that the output we are getting today from Orca (before the patch), as good and correct as it may be, is a result of flawed caching.
(In reply to comment #6) > This leads me to believe that the output we are getting today from Orca (before > the patch), as good and correct as it may be, is a result of flawed caching. > The flawed caching being the pre-patch state.
> This leads me to believe that the output we are getting today from Orca (before > the patch), as good and correct as it may be, is a result of flawed caching. Agreed. I updated the Orca tests and will re-close this. Thanks!