GNOME Bugzilla – Bug 512503
[testing required] Remove "object:visible-data-changed" listener from Gecko.py
Last modified: 2008-07-22 19:33:44 UTC
"object:visual-data-changed" is a high-traffic event that makes Orca slow down considerably, especially when navigating treeviews. Gecko.py uses this event to detect page tab switches. There is no ideal event to listen to for this purpose, I filed a bug about that: https://bugzilla.mozilla.org/show_bug.cgi?id=414302 In Orca's current design events are listened to globally when a script is loaded, this means that once Gecko.py starts it slows down all of Orca's functionality, even when not navigating inside of Firefox.
Created attachment 103863 [details] [review] Proposed changes This patch changes the listener to "object:state-changed:focused". The catch with this event is that it only emitted when the focus is inside the document frame, this could be OK since the "object:visual-data-changed" listener only does something if the focus is in the document.
More performance enhancements. Woo hoo! :-) Our regression tests once again need updating because FF has changed some more in the past couple of weeks. I'm going to update those tomorrow (technically, later today). Then I'll try your patch.
I tested with this patch, and the responsiveness when browsing the Firefox tree in Accerciser is indeed much better! However, I am still getting misreads when I just browse within the Firefox tree long enough. This seems to be especially true once the Accerciser tree itself starts scrolling. Also, it depends on what tab is active: As long as I stay on the at-spi Validator, I'm fine, but if I switch to API Browser, things start going crazy sooner than later.
Created attachment 105285 [details] A new test script for document tabs This script does some common stuff with tabs. Opens three different tabs, switches between them. Closes one, and then loads the identical page in two tabs and switches between them.
Interesting enough, the latest ff3 does not emit the visible-data-changed. At least not reliably. Could somebody else verify this? Just run the attached script, and look though the debug file, see if visible-data-changed is ever emitted from Minefield (gnome-panel applets do it too, so filter those out). If this is true, I'll sandwich the bad news between two positive bits: Good news: Removing the visible-data-changed listener will not cause any regression whatsoever. Bad news: Document tab changes in firefox are not handled by Orca. Good news: A patch similar to the one posted here will let Orca handle tab changes. If I start ff3 with a clean profile, like the one in our test/html directory, no visible-data-changed is emitted, but if I recover from a crash with my regular profile (ie. quit firefox with ctrl+c in the terminal, and start it again, you get a "restore" dialog), then everything seems to work, and we get the right events. I'll try to make this into a comprehensive bug report in Mozilla tomorrow.
Created attachment 105294 [details] [review] Proposed changes This calls the default.py state changed listener too, it was blocking it in the previous patch. Excuse the extra prefix (apply the patch with -p1). I started using git, hopefully I will get better at it soon.
> Interesting enough, the latest ff3 does not emit the visible-data-changed. At > least not reliably. Could somebody else verify this? I'm not seeing any. :-(
(In reply to comment #7) > I'm not seeing any. :-( > Are you not seeing the bug, or are you not seeing the visible-data-changed events? :)
Created attachment 105363 [details] debug output with Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9b4pre) Gecko/2008021601 Minefield/3.0b4pre on Solaris Express 79b I set up my ~/.orca-customizations.py to have the following contents: import orca.debug import orca.settings import re orca.debug.debugLevel = orca.debug.LEVEL_INFO orca.debug.eventDebugLevel = orca.debug.LEVEL_OFF orca.debug.eventDebugFilter = re.compile('[\S]*focus|[\S]*visible') orca.debug.debugFile = open('debug.out', 'w', 0) On my Solaris Express build 79b machine, I then ran Orca from svn trunk w/o the patch and a Firefox 3 nightly from today (Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9b4pre) Gecko/2008021601 Minefield/3.0b4pre). I then Alt+#'d, Ctrl+Tab'd, etc., and Orca spoke the tabs pretty happily. In the attached debug.out from this run, I saw both focus related events and object:visible-data-changed events being received and processed. The output is sometimes redundant between the focus and visible-data-changed events, but is also often different.
Created attachment 105364 [details] Debug.out from similar test, but with patch applied This is a debug.out when running a similar test on the same system, but with the patch applied. It seems to still keep the desired behavior (yeah!), but my testing was limited. I think you're on to something, Eitan.
I still am not getting any visible-data-changed events in my log. Could anyone else confirm this in Gutsy, or is it just my weird setup? Since I don't have a proper idea of what the status quo is, it is hard to say this patch has been tested thoroughly. If we are really having problems with this event, then maybe this patch is more necessary than we initially thought. I'm testing it with all of the firefox tests now.
Created attachment 105782 [details] [review] Proposed changes This makes sure that we only do stuff if the event.detail1 == 1 (ie. we are gaining and not losing focus).
I just noticed a side effect of this: When focus is on a link and you arrow off of that link, we announce the name of the page.
Created attachment 105789 [details] [review] Proposed changes Thanks Joanie. This fixes the problem you were mentioning. Let me know how it goes.
I just did a quick test of that particular issue. Seems to work. Thanks! Once I get my desktop stuff rebuilt, I'll run the regression tests on it. (Honest!) :-)
I seem to be hearing some extra chatter when tabbing between links with this patch. I'm hearing the page title and internal frame sometimes repeated when I wouldn't expect it. The problem is that I can't reproduce the problem all the time. A site that seems to be doing it quite a bit is www.techbargains.com. I'll keep testing and attach a debug when I can nale it down more.
I ran the regression tests. Only two little regressions, along the same lines that Mike reported, but I cannot reproduce them when I perform the same steps manually. (In other words, it seems that your patch works and that FF is occasionally being a pain. This is the norm I'm afraid, rather than the exception.) I did find one place on techbargains.com where I could reproduce the problem reliably: In the left-hand sidebar there is a section called Top System Deals. Beneath that is ads by Google. When I Tab from the last link in the system deals to the ads by Google, we seem to get a focus event for the (some) document frame. HTH.
With the exception of the above issues this patch is a nice performance improvement.
Committed this patch and the test script to trunk. I have an idea what is causing the extra verbosity that Mike and Joanie are reporting, it possibly happens when we focus in iframes, which I think google ads have. We will test this further in trunk before addressing that issue.