Just re-assigning this to Joanie as she told me it was OK to do this the other day.  

Just targeting this one so it makes the gnome 2.22 release 

Mike, I just tried this replying to a newsletter I received.

With respect to your steps:

1. The cursor is at the bottom whether Orca is running or not.

2. Pressing Ctrl+Home moved focus to the first line in the reply.  (The line that said so and so wrote).  Visually focus did not move up there, which might have confused me when we spoke about this on the phone.  However:

3. What I started typing appeared on that first line.  (Just before so and so wrote -- so pressing Return before writing might make sense, but that's too occurs even if Orca is not running)

Therefore, I need more specific instructions and/or an offending HTML message to reply to where the problem reliably can be seen.  Thanks!

re-targeting to FUTURE.  I still need a reproducible test case in order to tackle this bug and code freeze is essentially here....  Given the elusive nature of this bug, I'm also lowering the priority and severity to Normal.

First coarse pass at GNOME 2.24 planning.

After more testing I think the following should solve this problem.  
These changes should probably be made for thunderbird only.  
Whenever something html is editable we should turn off orca's caret navigation and navigation hot keys.  According to all the messages I've tested with this will fix the issues I origionally reported.  It is important to only do this when a document is editable though because turning off orca's caret navigation makes it impossible to read messages.  
 

In Gecko.py:useStructuralNavigationModel, there is this code block that helps determine if we should use structural navigation or not:

        while obj:
            if obj.getRole() == pyatspi.ROLE_DOCUMENT_FRAME:
                # Don't use the structural navivation model if the
                # user is editing the document.
                return not obj.getState().contains(pyatspi.STATE_EDITABLE)
            elif obj.getRole() in letThemDoItEditableRoles:
                return not obj.getState().contains(pyatspi.STATE_EDITABLE)
            elif obj.getRole() in letThemDoItSelectionRoles:
                return not obj.getState().contains(pyatspi.STATE_FOCUSED)
            elif obj.getRole() == pyatspi.ROLE_COMBO_BOX:
                return False
            else:
                obj = obj.parent

Some similar check for an editable document frame might be done for Gecko.py:useCaretNavigationModel.

However, there might be something wrong in the useStructuralNavigationModel logic.  Mike - are you noticing that you have to turn off structural navigation (Insert+z) in order to work around the cursor position problem?  If so, then something might be wrong with useStructuralNavigationModel or the method isn't being called.

Created attachment 110706 [details] [review]
revision 1

I believe this solves the problem.  Pylints to a 10.  Please test.

This seems to be getting better but I can still reproduce the problem with some messages.  Perhaps it's time for me to let Joanie ssh in and take a look.  

Created attachment 110876 [details] [review]
revision 2 - new approach

Working with Mike on this rather elusive bug.... It appears that we're not always correctly getting the document frame correctly (which means our caretContext might be hosed, which in turn means that we have no idea where we really are when trying to figure out if we should be using caret navigation and structural navigation).

Mike please try this version.  Thanks

This is working much better but is still failing on bugzilla notifications.  Please try the tests we were doing earlier on any message from bugzilla.gnome.org

(In reply to comment #11)
> This is working much better but is still failing on bugzilla notifications. 
> Please try the tests we were doing earlier on any message from
> bugzilla.gnome.org
> 

Without the patch, I can reliably reproduce the bug; with the patch I cannot reproduce it.  If you're still having this issue, I guess I need more info.  Sorry.

Now I'm not able to reproduce this.  How about checking this in as it does make life better and we'll keep testing?  

Okie dokie.  Patch committed.  Moving to pending, but we can always pull it back if more issues show up.

I'm going to leave this one pending for a few more days to give it more testing.  

Mike, where are we w.r.t. this bug?  Last time you and I chatted about it (2 or three weeks ago, I believe) you mentioned that there were still instances where we were impacting the cursor position.  Is that still your experience and, if so, do you have any reproducible test cases and/or a debug.out you can provide?  Thanks!

Mike and I are meeting on the phone right now.  He indicates that he is no longer seeing this issue.  Hopefully the silent focus patch fixed the last of it.  Closing as FIXED.  We can open a new bug for cases that crop up in the future.  Thanks!