Created attachment 81400 [details] [review]
patch to speak the full contents of the edit field in auto-complete

Turns out this is true in the standard Open dialog boxes as well.

The attached seems to work.

Hey Joanie, after testing this a bit I quite like it.  thanks much!  If no one finds any side effects I'd like to see this committed.  As a side note to the team, this is also the way autocompletes should behave in firefox and thunderbird.  The fact that it repeats the completed information as more characters are typed is OK in fact it is the expected behavior so that a fast typist doesn't miss the fact that they don't need to continue entering characters.  

I just noticed that this fix also takes care of autocomplete w.r.t. email addresses in Evolution (assuming, as Mike indicated, there are no side effects).

OK -- the main idea behind the patch is to modify the text-inserted handler to see if there are any text selections.  If so, then the inserted text was obviously the result of an autocomplete action.  

The only cases where I think this might fail involve mouse actions.  For example, in gnome-terminal, select some text using the mouse (you cannot select it with the keyboard, yet, though the vte folks seem interested in providing this).  Now type away quickly.  You'll see that the text remains selected.  

Two other examples are gedit and oowriter.  Type some text in a gedit/oowriter window.  Select some text using the keyboard or mouse.  Now, right click in the gedit/oowriter window on some text that is not selected.  The selected text remains selected and it is also copied to the position where you clicked.

Can you please test the patch to see if Orca's behavior remains consistent for these two cases?  Given that the wasAutoComplete logic only modifies behavior if the last input event was a keyboard event, I suspect the gedit/oowriter stuff should be consistent.  But...the gnome-terminal stuff might be different.

If it is consistent, I say it probably is OK to check in the patch (THANKS!).  In addition, if it is consistent, but broken, can you also file bugs for the broken behavior? 

Regarding gnome-terminal, I gave that a try and nothing unusual got echoed.  However, gnome-terminal.py has its own onTextInserted and only goes to the default if we're not in a terminal:

        [...]
        # We only do special things for terminals.
        #
        if event.source.role != rolenames.ROLE_TERMINAL:
            default.Script.onTextInserted(self, event)
            return
        [...]

So, for good measure, I modified gnome-terminal.py to always use default.py's onTextInserted.  While that doesn't result in good access to the terminal window's content, it doesn't result in the highlighted text being echoed either.  So I think we're ok on that front.

As for the other two examples.   The behavior remains consistent, but it may be because I'm mouse-challenged. :-/   If I type some text in gedit, select it either with the keyboard or the mouse, and then right-click on some text that is not selected, I get a context menu for the selected text (and can choose, for instance, to cut it, copy it, etc.)   Similarly, if I try it in OOo Writer, the text that was selected becomes unselected.  Is there some mouse gesture I should be using to accomplish the test you're describing?  (Sorry for being dense)

> So, for good measure, I modified gnome-terminal.py to always use default.py's
> onTextInserted.  While that doesn't result in good access to the terminal
> window's content, it doesn't result in the highlighted text being echoed
> either.  So I think we're ok on that front.

Yeah!  Thanks!

> As for the other two examples.   The behavior remains consistent, but it may be
> because I'm mouse-challenged. :-/   If I type some text in gedit, select it
> either with the keyboard or the mouse, and then right-click on some text that
> is not selected, I get a context menu for the selected text (and can choose,
> for instance, to cut it, copy it, etc.)   Similarly, if I try it in OOo Writer,
> the text that was selected becomes unselected.  Is there some mouse gesture I
> should be using to accomplish the test you're describing?  (Sorry for being
> dense)

My mouse is whacked.  Try middle-click.

Huh.  Didn't know middle-click did that.   While I'm not sure how much use I'll have for it personally, that is certainly good to know.  Thanks!!

Now that I know how my mouse works.... ;-)  The answer for both Gedit and OOo Writer is that the behavior is the same with and without the patch:  The selected text is not re-echoed as a result of the object:text-changed:insert event -- neither is the text that gets inserted as a result of the mouse action.   Not sure if we want to file a separate bug for that or not.

> Now that I know how my mouse works.... ;-)  The answer for both Gedit and OOo
> Writer is that the behavior is the same with and without the patch:  

Great!  Thanks for checking things out.  I say go ahead and commit it!  :-)

> selected text is not re-echoed as a result of the object:text-changed:insert
> event -- neither is the text that gets inserted as a result of the mouse
> action.   Not sure if we want to file a separate bug for that or not.

A separate bug probably would be good.  One of our target user groups is (or will be) magnification+speech users, of which we'll have mouse users.

The fix might be as simple as adding and else clause that says "so...the last event wasn't a keyboard event, eh?  Well...if it was a mouse button 2 event, then speak the inserted text."  Or something like that.

Patch committed.  Thanks for the review!

Regarding the other issue, please see bug #402192.

Okay to close this one?

(In reply to comment #9)
> Patch committed.  Thanks for the review!
> 
> Regarding the other issue, please see bug #402192.
> 
> Okay to close this one?
> 

Please feel free to close and watch your points ranking rise.  :-)

Thanks also for logging the other bug!  You're good.