Created attachment 140855 [details] [review]
proof of concept/starting off point

I played around with this while bugzilla was down today. As I indicated in the description, this is just something to begin a discussion.

FWIW, it seems to do a decent job of minimizing the Thunderbird issue raised on the Orca list today. It's customizable (via settings.py). And it's off by default. The patch is, I think (and hope), pretty straightforward....

Anyhoo.... Thoughts?

Created attachment 140858 [details]
debug.out taken during Thunderbird test with current Orca

By the way, here is a debug.out taken while looking at the Thunderbird flooding problem. The steps taken were:

1. Generate a text file with one number per line beginning at 1 and ending with 250. Copy its text contents to the clipboard.

2. Create a new message in Thunderbird and give focus to the body of the message.

3. Launch Orca in a terminal window, Alt Tab to the new message window, press Control V.

4. As Orca spoke, press Control until Orca finally stopped announcing the inserted text. Then press Control Home to get to the top of the message body.

5. Press Orca Q to quit.

This debug.out (and the one I'm about to attach) start with the press of Control V. Note the number of times Control was pressed (and note that I started whacking on it long before the debug.out would suggest). Also notice how much was spoken and how much we processed before I finally got to the top and quit (6066 lines worth of debug output).

Created attachment 140860 [details]
debug.out taken during Thunderbird test with flood detection enabled

Same test, but I had enabled the use of flood detection in settings.py. Far fewer presses of Control. Orca was more responsive. Only 737 lines of debug.out because we identified a flood and ignored a lot of garbage events.

Ugh.  This is a tough problem.  My first reaction to this is a question of "Is it important to detect the last event in an event flood (I think it might be 'yes')?  If so, how do we do so?"

Already thought of that. Should be easy enough to store. We could even get fancy and summarize things (x characters inserted). This was just an initial "stop the hang" attempt. I figured the bigger the patch, the less likely it would be to be looked at. :-)

Review of attachment 140855 [details] [review]:

I took another look at this today -- it seems relatively safe and something we can check in and experiment with.  I'm not sure how the flood checking context is cleared, though -- is that just implicitly done via the eventFloodDelta?

For this portion, are we in any danger when encountering fast typists who might have the CapsLock or NumLock keys locked and/or they use the Shift key while typing?

+        # Protect fast typists who set too large a delta.
+        #
+        if isinstance(orca_state.lastInputEvent, input_event.KeyboardEvent):
+            if event.type.startswith("object:text-changed:insert") \
+               and orca_state.lastInputEvent.modifiers == 0:
+                return False

It might be nice to store the flood values as some sort of orca_state.floodContext tuple so we know they are all related:

orca_state.floodContext = {e.type, time.time(), orca_state.lastObjectEventApp}

I'm curious also if the patch has any impact on the Nautilus issue we've been seeing?

I'll be resuming work on this soon.

Comment on attachment 140855 [details] [review]
proof of concept/starting off point

I'm obsoleting this. I think I've got a better idea.

Created attachment 162825 [details] [review]
New approach

This patch:

1. stores a dictionary for each script containing the most recent event of any given type along with the time of that event.

2. Implements a new script method, skipObjectEvent() in script.py which scripts can override as need be. By default, we try to eliminate typing, arrowing, and focus related events which are no longer relevant.

For me, this solves the bug José reported on the Orca list about his timesheet (the problem being our playing catch-up from a bunch of object:text-changed:insert events).

It also seems to solve bug 602300, make us more performant when navigating or scrolling quickly (not counting in Gecko content), and is half of the work needed for bug 529730.

It probably is broken seven ways to sunday also. :-) It's a first crack, but a cleaner more targeted one.

(In reply to comment #9)
> Created an attachment (id=162825) [details] [review]
> New approach
> 
> This patch:
> 
> 1. stores a dictionary for each script containing the most recent event of any
> given type along with the time of that event.
> 
> 2. Implements a new script method, skipObjectEvent() in script.py which scripts
> can override as need be. By default, we try to eliminate typing, arrowing, and
> focus related events which are no longer relevant.
> 
> For me, this solves the bug José reported on the Orca list about his timesheet

Yes, I can confirm that I can fill my time sheet much much much much faster.

So far, I regression tested in OOo Calc, OOo Writer, Gedit, and Nautilus list views.  I have not had any crashes.  For the most part, Orca seemed pretty fast in most of these areas before so I'm not sure I have seen any real measured performance boost here yet.  However, I spent some time in a fairly large spreadsheet in Calc and in the past after some time in there, things would slow down while jumping between cells and enterring data.  I could not reproduce that degradation this morning Actually, I don't know if it is my imagination here or what but in Firefox 3.5.9 while filling this bug report, the responsiveness seems better than usual and I thought the Gecko family wasn't going to exhibit this boost yet.  Also at the top of the page where the row of links often causes much sluggishness, things seemed to be snappier here too.  Dunno how much of this might be power of suggestion or truth but it is looking good so far.

When I open a large list in Nautilus, it still take a very long time to become available toOrca; not sure if this orca building the list or if Nautilus is the culperate here.  Reading the list is fine after it is built.

Thanks Steve.

In terms of Gecko, any time we're allowing normal/native Gecko events to do their thing (e.g. when you Tab amongst focusable elements or Arrow when Gecko is controlling the caret), you should see an improvement if you are navigating quickly. However, with Orca caret navigation we typically do not get caret-moved events out of Gecko. Thus that sort of arrowing will need to be handled separately.

As for Nautilus, bug 577098 and especially Li's commentary. It's out of our hands.

Based on the above feedback, and the fact that it passes the regression tests, and Michael's feedback this morning on the Orca-list, I've gone ahead and committed this to master:
http://git.gnome.org/browse/orca/commit/?id=b31d0d8c6f452941ebb49e18e3ff0f91ea96f136

Changing the status to ASSIGNED rather the RESOLVED/FIXED so that users can give it some more testing love.

Several weeks have passed and no issues have come up related to the fix committed for this bug. Therefore, I'm closing this one out.